Multicast on Peer-to-Peer live media streaming

Multicast on Peer-to-Peer live media streaming

Đại học Công Nghệ - Đại học Quốc gia Hà Nội

CÔNG TRÌNH DỰ THI GIẢI THƯỞNG “SINH VIÊN NGHIÊN CỨU KHOA HỌC”

NĂM 2012

Tên công trình: Multicast on Peer-to-Peer live media streaming

Họ và tên sinh viên: Nguyễn Quang Đức Nam, Nữ: Nam

Người hướng dẫn: PhD Nguyễn Đại Thọ

Trường Đại học Công nghệ CỘNG HÒA XÃ HỘI CHỦ NGHĨA VIỆT NAM Khoa Khoa học máy tính Độc lập – Tự do – Hạnh phúc

Hà Nội, ngày 22 tháng 03 năm 2012

Kính gửi: Hội đồng xét Giải thưởng “Sinh viên Nghiên cứu Khoa học”,

Trường Đại học Công nghệ

Tên tôi (chúng tôi) là: Nguyễn Quang Đức Sinh ngày: 15/12/1990

Số điện thoại (cố định, di động): 01698 198 119

Địa chỉ E-mail: ducnq_53@vnu.edu.vn

Sinh viên chịu trách nhiệm và có đóng góp chính cho công trình: (nếu trách nhiệm và đóng góp như nhau phải ghi rõ và cam đoan điều này)

Tôi (chúng tôi) làm đơn này kính đề nghị Ban Chỉ đạo cho tôi (chúng tôi) được gửi công trình nghiên cứu khoa học để tham dự Giải thưởng “Sinh viên Nghiên cứu Khoa học” năm 2012

Tên đề tài:

Multicast in Peer-to-Peer live media streaming

Tôi (chúng tôi) xin cam đoan đây là công trình do chính tôi (chúng tôi) thực hiện dưới sự hướng dẫn của PhD Nguyễn Đại Thọ, và không phải là khóa luận tốt nghiệp Nếu sai, tôi (chúng tôi) xin chịu mọi trách nhiệm trước nhà trường.

(Ký và ghi rõ họ tên) (Ký và ghi rõ họ tên)

Abstraction - The research represents a peer-to-peer system called iGridMedia run

over pull-based streaming protocol Using pull-based protocol provide the nearly optimal in terms of peer upload capacity utilization and system throughput even without intelligent scheduling and bandwidth measurement However, this nearly maximum upload capacity’s given with a cost, the tradeoff between control overhead and delay, the system will have, large delay or large control overhead That’s how pull-push hybrid protocol is presented, basically in pull-push hybrid protocol allow nodes not only pull packets from neighbors but also automatically push packets to its neighbors By simulation and real-world experiment has proved that pull-push hybrid protocol provide smaller delay and much smaller control overhead than pull-based protocol at once In this research, we try several ways to construct a not-random topology for the system to lower the average delay.

I Introduction:

Media streaming in internet right now is separated into two forms: the client-server form and the peer-to-peer form Client-server has been developed first, and become more popular by the time countries infrastructure for internet is still available But with the policy of saving resources throughout the world, people is heading to new technologies that require less resource and still provide good quality of service

To achieve that goal, peer-to-peer network is developed, unlike client-server network only use the bandwidth of server, peer-to-peer network utilize the bandwidth use age of all member in the network Several peer-to-peer media streaming systems have been provided, such as Pplive, Zattoo, Chainsaw, DONet/CoolStreaming, PRIME… most of them developed based on traditional tree- based protocol To ultilize all band width capacity in P2P streaming, a strategy is provided to construct multiple heigh-2 trees within a fully connected graph, which can be only apply to small group since each node has to establish connections with all other nodes certainly resulting in a huge overhead

In this research, we will based on the peer-to-peer system iGridMedia developed by Prof Meng Zhang from Tsinghua University, Beijing, China iGridMedia has more advantage the other systems to be used because not only it show good result in the simulation, or the PlantNet lab experiment, but also it has been tested in real life in CCTV broadcasting the Gala Evening for Spring Festival

2005 through the Internet, with over 500,000 users all around the world enjoyed it Only 200 nodes directly connected with the server, and require a 300 Kbps encoding rate server.

II Peer to Peer network & Peer to Peer media streaming system:

1 Peer to Peer network:

P2P network is created when two or more PCs are connected and share resources without going through a separate server computer A P2P network can be

an ad hoc connection (a couple of computers connected via a Universal Serial Bus to transfer files) A P2P network also can be a permanent infrastructure that links a half-dozen computers in a small office over copper wires Or a P2P network can be a network on a much grander scale in which special protocols and applications set up direct relationships among users over the Internet.

The initial use of P2P networks in business followed the deployment in the early 1980s of free-standing PCs In contrast to the minimainframes of the day, such

as the VS system from Wang Laboratories Inc., Which served up word processing and other applications to dumb terminals from a central computer and stored files

on a central hard drive, the then-new PCs had self-contained hard drives and

built-in CPUs The smart boxes also had onboard applications, which meant they could be deployed to desktops and be useful without an umbilical cord linking them to a mainframe.

Many workers felt liberated by having dedicated PCs on their desktops But soon they needed a way to share files and printers The obvious solution was to save files to a floppy disk and carry the disk to the intended recipient or send it by interoffice mail.

In effect, every connected PC is at once a server and a client There's no special network operating system residing on a robust machine that supports special server-side applications like directory services (specialized databases that control who has access to what).

In a P2P environment, access rights are governed by setting sharing permissions on individual machines.

For example, if User A's PC is connected to a printer that User B wants to access, User A must set his machine to allow (share) access to the printer Similarly,

if User B wants to have access to a folder or file, or even a complete hard drive, on User A's PC, User A must enable file sharing on his PC Access to folders and printers

on an office P2P network can be further controlled by assigning passwords to those resources.

2 Peer to Peer Media streaming system:

The major difference between a general peer system and a peer media streaming system lies in the data sharing mode among peers: the former uses the ‘open-after-downloading’ mode, while the latter uses the ‘play- while-downloading’ mode More specifically, in apeer-to-peer media streaming system, a subset of peers own a certain media file, and they stream the media file to requesting peers On the other hand, the requesting peers playback and store the media data during the streaming session, and they become supplying peers of the media file after the streaming session.

peer-to-Four characteristics of a peer-to-peer media streaming system, the first three are shared by all peer-to-peer systems, while the last one is unique in peer-to-peer media streaming systems:

• First, a peer-to-peer media streaming system is self-growing With requesting peers to become supplying peers, the system’s total capacity will be amplified: the more number of peers it serves, the larger the capacity it will have.

• Second, a peer-to-peer media streaming system is server-less A peer is not supposed to exhibit server-like behavior, such as opening a large number of simultaneous network connections This may in practice be very harmful to other hosts sharing the same network (such as a campus network) Therefore, the power of a peer-to-peer streaming system should lie in the large number of participating peers, rather than in the high capacity of certain individual peers.

• Third, peers in a peer-to-peer media streaming system are heterogeneous

in their bandwidth availability and particularly, in their out-bound bandwidth availability This heterogeneity may be due to the different access networks (such as Ethernet, xDSL, cable modem, and ISDN) that connect peers to the backbone; or due to the asymmetric in-bound/out- bound bandwidth of a peer The asymmetry in turn, is either due to the access network technology (such as in the case of ADSL), or due to the asymmetric willingness of a peer: it is more willing to spend high in- bound bandwidth to receive the peer-to-peer streaming service, than to offer the same amount of out-bound bandwidth to provide the peer-to- peer streaming service.

• Finally, in a peer-to-peer media streaming session, the peer/requesting-peer relation is typically multiple-to-one, instead of one- to-one as in the general peer-to-peer system This is due to the real-time nature of media streaming and the peers’ heterogeneity in their out-

supplying-bound bandwidth offers Suppose the outsupplying-bound bandwidth offered by each supplying peer is lower than the original recording/playback rate of the media data 1 In order to provide real-time streaming to the requesting peer, it is necessary to involve multiple supplying peers in one peer-to-peer streaming session, whose bandwidth offers add up to the original media data rate As shown in Figure 1(b), each supplying peer will transmit a subset of the media data; while the requesting peer will collect and synchronize the data for real-time playback.

II The iGridMedia:

1 Pull-based protocol:

The core of the iGridMedia system is the pull-based protocol apply over an unstructured overlay network We use that unstructured overlay to accommodate the high churn rate in live streaming application A well-known rendezvous point (RP) is deployed to assist the construction of the overlay As a startup, a participating node first contacts the RP to get a list of part of the nodes already in the overlay, called a login process when the local clock of the new node should be synchronized with RP Then the participating node will randomly select some nodes

in this list as its neighbors By the time, the participating node has selected its new neighbors, it sends messages to those neighbors to notice them for the new connection If a neighbor of a node quits or fails, the node selects a new neighbor from its member table So that an unstructured overlay is built.

After the unstructured overlay network is built, the video streaming is packetized into fixed-length packets called streaming packets marked by sequence number Periodically, each node sends its neighbors the buffer map packets which contain what streaming packets it has in the buffer According to that buffer map packets each node will schedule to request packets from its neighbors periodically All packets that used to control the protocol is called control packet, including buffer map packets, request packets and packets for overlay construction.

The pulling method is at each period the request packets sent called request interval, the node asks its neighbors for all the absent packets in the current request window The request window slides forward with the head is the latest packets with the maximum sequence number the node has known according to the buffer maps from its neighbor The buffer size is longer than the request window size If a packet does not arrived at node on time (after playback deadline) it will no longer be requested If multiple neighbors have the same packet, the packet will be assign to one of the neighbors according to the scheduling method For the term a packet does not arrive after its request has been sent, it can be request again by setting the request interval much smaller than the request window By that, the packet will be request again if it not arrive after some space of time called waiting timeout.

Key point of Pull-based protocol is using the unreliable transmission for streaming packet (UDP for specific) Because, if we use TCP, we set the sending buffer of TCP socket to a relatively small value, and once the sending rate is beyond the bandwidth, the TCP sending buffer will get overflow and the packet is dropped.

By using UDP, we can use relative small timeout to conclude whether a packet is

dropped or not In our pull-based protocol, once a node receives a request from one neighbor, it will deliver all the requested packets within a constant bit rate exactly

in time of one request interval If the sending rate exceeds the upload capacity or end-to-end bandwidth, the overloaded packets will be dropped directly and never be retransmitted until a new request is sent by that neighbor again We calculate the waiting time out for a requested packet is the sum of route trip time, request interval, and an additional waiting time to further prevent duplicated requests for a packet.

• Simulation result:

To evaluate the effort of pull-based protocol on peer-to-peer media streaming system, we use a simulation developed by PhD Meng Zhang, the p2pstrmsim simulation The simulation is implemented in C++ to conduct a series of simulations

in this section In p2pstrmsim, all streaming and control packets and node buffers are carefully simulated A latency matrix is used to simulate the real-world node-to- node delay The average end-to-end delay is 79ms The default number of node is

10000 We map each node pair in our simulation to each pair in the latency matrix

The default raw streaming rate (not include 40-byte/packet header overhead) is set to 300kbps We assume all the control messages can be reliably delivered (not the streaming packets) Default number of neighbor for each node is

20 and the default request window size is 20 seconds.

Default upload capacity for source node is 2Mbps The peer upload and download capacity is divided into 3 different kind of DSL nodes Their upload capacities are 1Mbps, 384Kbps, and 128 Kbps, their download capacities are 3Mbps, 1.5Mbps, 768Kbps.

This figure shows the average deliverable rate, average upload rate, average upload capacity depends on the capacity supply ratio We can see that with the overall capacity supply ratio only 1.3 times of the raw streaming rate (300Kbps), pull-based protocol can provide really high upload capacity And when the capacity supply ratio is under 1.15 times of the raw streaming rate, we can see that the upload rate is very close to the upload capacity, that shows the capacity is almost fully utilized.

This figure show the average delivery ratio under different capacity supply ratio and request interval, we can see that when the request interval is too short (under 400 msec) the average delivery ratio is not optimized cause the small request interval lead to a huge number of control overhead traffic which takes the bandwidth of streaming packets Beside the higher capacity supply ratio provide better delivery ratio (still a small number with only 1.3 times of raw streaming rate) The best delivery ratio provided with request interval around 600 to 800 and the capacity supply ratio is about 1.2 to 1.3 times of raw streaming rate

This figure shows the average delivery ratio with the impact of request interval and request window size (capacity supply ratio is set to 1.2).While, the request window size is small, the average delivery ratio drop low And if the request window size is larger (around 16 to 20 sec) with request interval under 1000 msec, the average delivery ratio can nearly reach 1.

Those simulations have shown that pull-based protocol can provide a nearly optimize utility of upload capacity with a very limited require to the capacity supply ratio.

2 Pull-push Hybrid Protocol

Now that pull-based protocol has finished at nearly optimizing the upload capacity use age But in pull-based protocol, there is a big tradeoff between the control packet overhead and average playback delay If we want lower delay, we have to scarify the quality of media, otherwise, if we want better quality, we have to accept the larger delay That’s how pull-push hybrid protocol is presented In pull-