Download slides - network systems lab @ sfu

Opportunities and Challenges of
Peer-to-Peer Internet Video Broadcast
J. Liu, S. G. Rao, B. Li and H. Zhang
Presented by: Yan Ding
Proc. of The IEEE, 2008
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
2/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. 85-110, May 1990.
– 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
3/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.
4/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
5/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.
6/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
7/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.
8/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
9/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)
10/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
11/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 datadriven overlay network for live media streaming”, in Proc. INFOCOM’05,
Miami, FL, USA, March 2005.
12/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
13/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
14/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
15/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
16/16