Buffer Analysis of Live P2P Media Streaming Approaches Atif Nazir BSc ’07, LUMS

P2P Approaches in Media Streaming: Background  Advent of services such as IPTV and news broadcasting on the Internet has mandated growth of peer-to-peer networks for streaming of live media transmissions  This is because of the infeasibility of implementing IP Multicast due to practical issues such as lack of incentive for ISPs to install multicast-capable routers and to carry multicast traffic  P2P overlays work by establishing unicast tunnels across cooperative participating users (peers or overlay nodes). These nodes are then used to simulate multicasting by relaying data among them.  Formation of P2P overlays for streaming poses challenges including scalability and issues in resilience, as well quality of service for subscribing peers.

P2P Approaches in Media Streaming: Tree-based vs. Mesh-based  A number of proposals aim to deal with challenges posed by P2P streaming of live media:  Mesh-based: Coolstreaming [1], Promise, GNUStream  Each peer can accept media data from multiple parents as well as provide services to multiple children (both parent and child are relative terms, there actually is no long-term master-slave relationship except with seeding servers)  Pros: high resource utilization, fast discovery of fresh peers in a single mesh due to gossiping  Cons: quality of service cannot be guaranteed due to gossiping among peers, large buffer space needed to reduce impact of autonomy of peers (in a dynamic environment)  Tree-based: AnySee [2], NICE, ZigZag  Each peer communicates only with one parent (per overlay) and provides service to a number of children such that a “tree” topology is always maintained (in an overlay).  Pros: closely resembles original IP multicast ideas, low management overhead, (expected to have) low buffer size requirement  Cons: highly vulnerable to disruption under dynamic environments, low resource utilization  We propose a buffer-based comparison of AnySee and Coolstreaming while proposing and evaluating a minor change to AnySee (Modified-AnySee)

P2P Approaches in Media Streaming: Coolstreaming vs. AnySee  Coolstreaming:  Relies on arbitrary pairing of nodes for relaying data in an overlay diagram: node A is the seed node. This is done through random “gossip” among overlay nodes.  AnySee:  Relies firstly on formation of tree-based overlays (black links) and then participation of peers in multiple tree-based overlays (orange links) (example: node G with C,S2)

Proposed Modification to AnySee: Modified-AnySee  AnySee forms its tree-based overlays on the basis of advertised delays in information reception, with the source (seed) having a delay of 0ms.  An example tree-based delay topology with advertised delays:  Given node-node delays in the overlay network, it is possible for inner nodes in the tree to communicate with other inner nodes (for example node G with A) such that a backup path within an overlay is established in addition to links with other (secondary) overlays. This is expected to add to the stability of data rates and stream continuity already provided by AnySee, however a quantitative analysis of such an approach must be done to analyze the extent of its impact on performance of the original AnySee approach.

Proposed Analysis of Coolstreaming, AnySee and Modified-AnySee  Furthermore, “Satisfactory” service under Coolstreaming and AnySee requires buffering of media streams to cater for variability in data rates and streaming quality. The required buffering for:  AnySee: 40seconds, due to inter-overlay communication among peers and high stream stability (stable data rates)  Coolstreaming: 120seconds, due to intra-overlay peering and lower stream stability  Modified-AnySee: buffer requirement unknown, but expected to be less than Coolstreaming but more than AnySee.  However, a quantitative analysis of the impact of variation in buffer sizes for AnySee and Coolstreaming is lacking.  Questions that are as yet unanswered:  How does the performance of AnySee compare to Modified-AnySee in terms of playback continuity in stable (peers stay once they join) and dynamic (peers have full autonomy to join or leave whenever they wish) conditions?  What is the required buffer size for “satisfactory” playback under Modified-AnySee? Is it better than AnySee? Is it worse than Coolstreaming?  What is the impact of decreasing buffer size on playback continuity and startup delay for Coolstreaming, AnySee and Modified-AnySee under stable and dynamic conditions?

References [1] X. Zhang, J. Liu, B. Li, and T. P. Yum, "DONET: A Data-Driven Overlay Network for Efficient Live Media Streaming", in Proceedings of IEEE INFOCOM, [2] X. Liao, H. Jin, Y. Liu, L. M. Ni, D. Deng, “AnySee: Peer-to-Peer Live Streaming”, in Proceeding of IEEE INFOCOM, 2006.