LightBlog
Contact at mumbai.academics@gmail.com or 8097636691/9323040215
Responsive Ads Here

Thursday, 22 February 2018

Live Streaming with Receiver-based Peer-division Multiplexing(2011)

ABSTRACT:            
v  In this paper we describe the network architecture of Zattoo, one of the largest production live streaming providers in Europe at the time of writing, and present a large-scale measurement study of Zattoo using data collected by the provider.
v  Peer-Division Multiplexing to minimize per-packet processing time of a stream, the Zattoo protocol sets up a virtual circuit with multiple fan outs at each peer.
v  Peer joins a TV channel it establishes a peer-division multiplexing (PDM) scheme amongst a set of neighboring peers, by building a virtual circuit to each of the neighboring peers.
v  We represent a peer as a packet buffer, called the MDC, fed by sub-streams incoming from the PDM constructed as described in a local media player if one is running.
v  As packets from each sub-stream arrive at the peer, they are stored in the MDC for reassembly to reconstruct the full stream.
v  Portions of the stream that have been reconstructed are then played back to the user. In addition to providing a reassembly area, the MDC also allows a peer to absorb some variabilities in available network bandwidth and network delay.
PROJECT PURPOSE:
There is an emerging market for IPTV. Numerous commercial systems now offer services over the Internet that is similar to traditional over-the-air, cable, or satellite TV. Live television, time-shifted programming, and content on demand are all presently available over the Internet. Increased broadband speed, growth of broadband subscription base, and improved video compression technologies have contributed to the emergence of these IPTV services.
PROJECT SCOPE: 
The application buffer receives data as it trickles in and informs the user upon the completion of download. The user can then start playing back the file for viewing in the case of a video file. Bit torrent and variants are example of delay-tolerant file download systems. Video playback starts as soon as the application assesses it has sufficient data buffered that, given the estimated download rate and the playback rate, it will not deplete the buffer before the end of file. If this assessment is wrong, the application would have to either pause playback or rebuffed, or slow down playback. While users would like playback to start as soon as possible, the application has some degree of freedom in trading off playback start time against estimated network capacity. Most video on demand systems are examples of delay-sensitive progressive download application.
PRODUCT FEATURES:
Zattoo peer-to-peer live streaming system was a free to use network serving over 3 million registered users in eight European countries at the time of study, with a maximum of over 60,000 concurrent users on a single channel. The system delivers live streams using a receiver-based, peer division multiplexing scheme. We presented a receiver-based, peer-division multiplexing engine to deliver live streaming content on a peer-to peer network. The same engine can be used to transparently build a hybrid P2P/CDN delivery network by adding Repeater nodes to the network. By analyzing large amount of usage data collected on the network during one of the largest viewing event in Europe, we have shown that the resulting network can scale to a large number of users and can take good advantage of available uplink bandwidth at peers.
INTRODUCTION:
Peer-to-peer systems for live streaming have been introduced in recent years. The behavior of these popular systems has been extensively studied in several measurement papers. Due to the proprietary nature of these commercial systems, however, these studies have to rely on a “black-box” approach, where packet traces are collected from a single or a limited number of measurement points, to infer various properties of traffic on the control and data planes. Although such studies are useful to compare different systems from end-user’s perspective, it is difficult to intuitively understand the observed properties without fully reverse-engineering the underlying systems.
Numerous commercial systems now offer services over the Internet that is similar to traditional over-the-air, cable, or satellite TV. Live television, time-shifted programming, and content-on demand are all presently available over the Internet. Increased broadband speed, growth of broadband subscription base, and improved video compression technologies have   contributed to the emergence of these IPTV services.
We draw a distinction between three uses of peer-to-peer (P2P) networks: delay tolerant file download of archival material, delay sensitive progressive download (or streaming) of archival material, and real-time live streaming. In the first case, the completion of download is elastic, depending on available bandwidth in the P2P network. The application buffer receives data as it trickles in and informs the user upon the completion of download. The user can then start playing back the file for viewing in the case of a video file. Bittorrent and variants are example of delay-tolerant file download systems.
In the second case, video playback starts as soon as the application assesses it has sufficient data buffered that, given the estimated download rate and the playback rate, it will not deplete the buffer before the end of file. If this assessment is wrong, the application would have to either pause playback and rebuffer, or slow down playback. While users would like playback to start as soon as possible, the application has some degree of freedom in trading off playback start time against estimated network capacity. Most video-on demand systems are examples of delay-sensitive progressive download application.
The third case, real-time live streaming has the most stringent delay requirement. While progressive download may tolerate initial buffering of tens of seconds or even minutes, live streaming generally cannot tolerate more than a few seconds of buffering. Taking into account the delay introduced by signal ingest and encoding, and network transmission and propagation, the live streaming system can introduce only a few seconds of buffering time end-to-end and still be considered “live”. The Zattoo peer-to-peer live streaming system was a free to- use network serving over 3 million registered users in eight European countries at the time of study, with a maximum of over 60,000 concurrent users on a single channel. The system delivers live streams using a receiver-based, peer division multiplexing scheme.
PROBLEM DEFINITION:
Sub streams of the TV channel; it initiates another SEARCH round, sending SEARCH messages to peers newly learned from the previous round. The joining peer gives up if it cannot obtain the full stream after two SEARCH rounds. To help the joining peer synchronize the sub-streams it receives from multiple peers, each existing peer also indicates for each sub-stream the latest sequence number it has received for that sub- stream, and the existence of any quality problem. The joining peer can then choose sub-streams with good quality that are closely synchronized.
EXISTING SYSTEM:
v  In media streaming, the Internet’s intrinsic heterogeneity continues a challenging problem. End users may have different edge bandwidth for data receiving or forwarding, especially in large-scale streaming with hundreds of thousands of users.
v  Description coding rates have straightforward impact to the delivery performance. If a description has a high coding rate, some network paths may not have enough bandwidth to support its delivery.
v  The loss rate of the description will be high. On the other hand, if descriptions have low coding rates, the number of descriptions and accordingly the coding cost will be high.
LIMITATIONS OF EXISTING SYSTEM:
Quality feedback from multiple peers, a peer first determines if the identified sub-streams are arriving in low quality. If so, the low quality of service may not be caused by limit on its own available uplink bandwidth; in which case, it ignores the low quality feedbacks otherwise, the peer decrements its estimate of available uplink bandwidth. If the new estimate is below the bandwidth needed to support existing number of virtual circuits, the peer closes a virtual circuit. To reduce the instability introduced into the network, a peer closes first the virtual circuit carrying the smallest number of sub-streams.
PROPOSED SYSTEM:
v  We represent a peer as a packet buffer, called the MDC, fed by sub-streams incoming from the PDM constructed as described in a local media player if one is running.
v  As packets from each sub-stream arrive at the peer, they are stored in the MDC for reassembly to reconstruct the full stream.
v  Portions of the stream that have been reconstructed are then played back to the user. In addition to providing a reassembly area, the MDC also allows a peer to absorb some variability’s in available network bandwidth and network delay.
v  We use retransmission to let a peer recover from transient network congestion. A peer sends out a retransmission request when the distance between the repair pointer and the input pointer has reached a threshold of R packet slots, usually spanning multiple segments.
v  A retransmission request consists of an R- bit packet mask, with each bit representing a packet, and the sequence number of the packet corresponding to the first bit. Marked bits in the packet mask indicate that the corresponding packets need to be retransmitted.
ADVANTAGES OF PROPOSED SYSTEM:
We have shown that the resulting network can scale to a large number of users and can take good advantage of available uplink bandwidth at peers. We have also shown that error-correcting code and packet retransmission can help improve network stability by isolating packet losses and preventing transient congestion from resulting in PDM reconfigurations. We have further shown that the PDM and adaptive PDM schemes presented have small enough overhead to make our system competitive to digital satellite TV in terms of channel switch time, stream synchronization.
MODULES DESCRIPTION:
ZATTOO PEER-TO-PEER SYSTEM:
Zattoo peer-to-peer live streaming system was a free to use network serving over 3 million registered users in eight European countries at the time of study, with a maximum of over 60,000 concurrent users on a single channel. The system delivers live streams using a receiver-based, peer division multiplexing scheme as described in to ensure real-time performance when peer uplink capacity is below requirement, Zattoo subsidizes the network’s bandwidth requirement The Zattoo system rebroadcasts live TV, captured from satellites, onto the Internet. The system carries each TV channel on a separate peer-to-peer delivery network and is not limited in the number of TV channels it can carry. Although a peer can freely switch from one TV channel to another, and thereby departing and joining different peer-to-peer networks, it can only join one peer-to-peer network at any one time. We henceforth limit our description of the Zattoo delivery network as it pertains to carrying one TV channel on the Zattoo network.
LIVE DATA STREAMING:
Zattoo live streaming protocol as a receiver-based, peer division multiplexing protocol the details of peer-division multiplexing is described in a while the details of how a peer manages sub-stream forwarding and stream reconstruction is described in receiver-based peer division multiplexing has also been used by the latest version of Cool Streaming peer-to-peer protocol though it differs from Zattoo in its stream management. As packets from each sub-stream arrive at the peer, they are stored in the IOB for reassembly to reconstruct the full stream. Portions of the stream that have been reconstructed are then played back to the user. In addition to providing a reassembly area, the IOB also allows a peer to absorb some variability’s in available network.
PEER-DIVISION MULTIPLEXING (PDM):
PDM per-packet processing time of a stream, the Zattoo protocol sets up a virtual circuit with multiple fan outs at each peer. When a peer joins a TV channel, it establishes a peer-division multiplexing (PDM) scheme amongst a set of neighboring peers, by building a virtual circuit to each of the neighboring peers. Baring departure or performance degradation of a neighbor peer, the virtual circuits are maintained until the joining peer switches to another TV channel. With the virtual circuits set up, each packet is forwarded without further per-packet handshaking between peers. We describe the PDM boot strapping mechanism in this section and the adaptive PDM mechanism to handle peer departure and performance technique.
THE PDM ESTABLISHMENT PROCESS CONSISTS OF TWO PHASES:
1.        SEARCH PHASE
2.        JOIN PHASE.
SEARCH PHASE: To obtain a list of potential neighbors, a joining peer sends out a SEARCH message to a random subset of the existing peers returned by the Rendezvous Server. The SEARCH message contains the sub-stream indices for which this joining peer is looking for peering relationships. The sub stream indices are usually represented as a bitmask of n bits, where n is the number of sub-streams defined for the TV channel. In the beginning, the joining peer will be looking for peering relationships for all sub-streams and have all the bits in the bitmask turned on. In response to a SEARCH message, an existing peer replies with the number of sub-streams it can forward. From the returning SEARCH replies, the joining peer constructs a set of potential neighbors that covers the full set of sub-streams comprising the live stream of the TV channel.
The joining peer continues to wait for SEARCH replies until the set of potential neighbors contains at least a minimum number of peers, or until all SEARCH replies have been received. With each SEARCH reply, the existing peer also returns a random subset of its known peers. If a joining peer cannot form a set of potential neighbors that covers the entire sub streams of the TV channel, it initiates another SEARCH round, sending SEARCH messages to peers newly learned from the previous round. The joining peer gives up if it cannot obtain the full stream after two SEARCH rounds. To help the joining peer synchronize the sub-streams it receives from multiple peers, each existing peer also indicates for each sub-stream the latest sequence number it has received for that sub-stream, and the existence of any quality problem. The joining peer can then choose sub-streams with good quality that are closely synchronized.
JOIN PHASE: Once the set of potential neighbors is established, the joining peer sends JOIN requests to each potential neighbor. The JOIN request lists the sub-streams for which the joining peer would like to construct virtual circuit with the potential neighbor. If a joining peer has l potential neighbors, each willing to forward it the full stream of a TV channel, it would typically choose to have each forward only 1/l-th of the stream, to spread out the load amongst the peers and to speed up error recovery, as described in selecting which of the potential neighbors to peer with, the joining peer gives highest preference to topologically close-by peers, even if these peers have less capacity or carry lower quality sub-streams. The “topological” location of a peer is defined to be its subnet number, autonomous system (AS) number, and country code, in that order of precedence. A joining peer obtains its own topological location from the Zattoo Authentication Server as part of its authentication process. The list of peers returned by both the Rendezvous Server and potential neighbors all come attached with topological locations. A topology-aware overlay not only allows us to be “ISP-friendly,” by minimizing inter-domain traffic and thus save on transit bandwidth cost, but also helps reduce the number of physical links and metro hops traversed in the overlay network, potentially resulting in enhanced user perceived stream quality.
HARDWARE AND SOFTWARE REQUIREMENTS:
HARDWARE REQUIREMENTS:
•         System                        :           Pentium IV 2.4 GHz.
•         Hard Disk                   :           40 GB.
•         Floppy Drive   :           1.44 Mb.
•         Monitor           :           15 VGA Colour.
•         Mouse             :           Logitech.
•         Ram                 :           512 Mb.
SOFTWARE REQUIREMENTS:
•         Operating system        :  Windows XP.
•         Coding Language       :  JDK 1.6
•         Tools                           : Eclipse 3.3 

No comments:

Post a Comment