Opportunities and Challenges of Peer-to-Peer Internet Video Broadcast J. Liu, S. G. Rao, B. Li and H. Zhang Proc. of The IEEE, 2008 Presented by: Yan Ding

2/16 Outline  Introduction  Architectural choices –Router-based: IP Multicast –Non router-based: Overlay networks (CDNs, P2P)  Peer-to-Peer Video Broadcast –Tree-based Construction (ESM) –Data-driven randomized Construction (CoolStreaming)  Challenges –Technical issues and deployment challenges  Conclusion

3/16 Introduction  Internet Video Broadcast/Multicast –Real-time performance requirements: higher bandwidth and lower latency –More challenging than file download, voice over IP –Can use IP Multicast or Overlay networks  IP Multicast –S. Deering and D. Cheriton, “Multicast routing in datagram internetworks and extended LANs”, ACM Transaction on Computer Systems, vo. 8, no. 2, pp , May –Scalability concern, slow deployment, cannot support for higher level functionality  Peer-to-Peer Multicast –Cost-effective and easy to deploy –Has potential to scale: peer severs as both server and client –Tree-based and Data-driven approaches

4/16 Architectural choice — Router-based IP Multicast  Network-layer solution –Routers responsible for multicasting Group membership: remember group members for each multicast session Multicast routing: route data to members –Efficient bandwidth usage network topology is best-known in network layer Figures are from Chu et al. “A case for end system multicast”,in Proc. ACM SIGMETRICS’00, June 2000.

5/16 IP Multicast  Requires per-group state in routers –Maintenance produces high complexity, especially in core routers –Scalability concern –Violate end-to-end design principle: ‘ stateless ’  Slow deployment –Changes at infrastructural level –IP multicast is often disabled in routers  Difficult to support higher layer functionality –E.g., Error, flow control and congestion control

6/16 Architectural choice — Non Router-based Overlay Network  Application-layer solution –Multicast functionality in end systems –End system participate in multicast via an overlay structure –Overlay consists of application-layer links –Application-layer link is a logical link consisting of one or more links in underlying network Figures are from Chu et al. “A case for end system multicast”,in Proc. ACM SIGMETRICS’00, June 2000.

7/16 Overlay Network  Performance penalties –Produce redundant traffic on physical link: multiple overlay edges use the same physical link –Increase latency: communication involves other end systems  Fast deployment –Unicast IP service: all packets are transmitted as unicast packets –Requires end system to perform additional processing  Enable higher layer functionality –Leverage unicast solutions –Exploit application-specific intelligence  Used by both CDNs and pure P2P systems

8/16 P2P Multicast  Tree-based –Peers organized into trees for delivering data –Parent-child relationships –Push-based –Maintain and repair tree when nodes join, leave or fail –Failure of higher nodes disrupt many users –Uplink bandwidth not utilized at leaves Data can be divided and disseminated along multiple trees –Example: End System Multicast (ESM) Y.-H. Chu, S. G.Rao, and H. Zhang, “ A case for end system multicast ”,in Proc. ACM SIGMETRICS ’ 00, June 2000.

9/16 End System Multicast (ESM)  Main idea –Construct a good overlay structure (mesh) –Construct spanning trees of the mesh, each rooted at the corresponding source  Good overlay structure –Path quality: between any pair of members is comparable to that of the unicast path between them (e.g. delay, bandwidth) –Overhead control: each member has a limited number of neighbors  Construct spanning trees –Use standard routing algorithms to construct per-source (reverse) shortest path spanning trees for data delivery

10/16 ESM (1/2)  Maintain information –A list of members in the group (randomly chosen) –Path from source to itself  Update information –Changes due to dynamics (node join, leave or fail) –Periodically exchange with its neighbors  Dynamics –Member join Contact the source and get a few active members Request to be neighbors and select one as parent (parent selection) –Member leave or fail Notify its neighbors before leaving No refresh message received: member fail (need parent re-selection)

11/16 ESM (2/2)  Parent selection –When to select: node (say, A) newly join or current parent leave, fail or performs poorly –Who to select: neighbors that have low delay or haven’t been probed –How to select: Degree-saturated or not Descendant or not Performance (throughput, delay)  Failure of higher nodes disrupt many users and uplink bandwidth not utilized at leaves Each sub-stream delivered via one overlay tree Robust to the failure of an ancestor and utilize bandwidth of all nodes Need specialized coding algorithm on receiver

12/16 P2P Multicast  Data-driven –Use availability of data rather than explicit structure to guide data flow –Pull-based Avoid redundancy –Periodically exchange data availability with random partners and retrieve new data Robust to node failures –Real time constraints Scheduling problem –Example: CoolStreaming X. Zhang, J. Liu, B. Li and T.-S. P. Yum, “ DONet/CoolStreaming: A data- driven overlay network for live media streaming ”, in Proc. INFOCOM ’ 05, Miami, FL, USA, March 2005.

13/16 CoolStreaming  Membership Manager –Maintain information A list of members in the group –Update information Periodically generate membership message Distribute it using Scalable Gossip Membership Protocol (SGAM)  Partnership Manager –Partners are members that have expected data segments –Exchange Buffer Map (BM) with partners –Buffer Map contains information of availability of segment  Scheduling –Determine which segment should be abtained from which partner –Get segment from partner and provide availble segment to partner

14/16 Challenges (1/2)  Tree-based vs. Data-driven –Tree-based: face instability and bandwidth under-utilization –Data-driven: suffer latency-overhead tradeoff –Hybrid: identification and position set of stable overlay nodes  Incentives and fairness –Free riders exist in p2p system –Need incentive mechanism for real-time requirements

15/16 Challenges (2/2)  Support heterogeneous receivers –Scalable Coding, Multiple Descriptive Coding (MDC) –Low efficiency, bandwidth penalty, need powerful receiver  Coding at peers? –Network coding improve througput –Tradeoff between coding efficiency and startup delay  Deployment –Interests conflicts between network and service providers –Internet triumphs on development of new service –Service providers relay on dedicated networks

16/16 Conclusion  Introduce two Internet achitectural choices to support Video broadcasting –IP Multicast: implement in network layer (router) –Overlay: implement in application layer (end system)  Reviews the state-of-the-art of P2P technologies and examine two broad approaches –Tree-based: construct trees to deliver data –Data-driven: use availability info to guide data flow  Discuss technical challengings and deployment issues