Multicast Overlays

1. Multicast Overlays CSE 581: Internet Technology (Winter 2002) Instructor: Prof. Wu Chang Feng Presenter: Charles ‘Buck’ Krasic CSE 581 – Multicast Overlays Charles ‘Buck’ Krasic

2. Papers Covered • An Architecture for Internet Content Distribution as an Internet Infrastructure. Yatin Cahwathe, Steve McCanne, Eric Brewer (UCB). Feb ‘2000, Unpublished. • The Inktomi Overlay Solution for Streaming Media Broadcasts. Inktomi Corporation. (Brewer: Co-founder & Chief Scientist, McCanne: CTO). WWW whitepaper. • Overcast: Reliable Multicasting with an Overlay Network. John Jannotti, David K. Gifford, Kirk L. Johnson, M. Frans Kaashoek, James W. O’Toole, Jr (Cisco). OSDI ‘2000 • A Case for End System Multicast. Yang-hua Chu, Sanjay G. Rao, and Hui Zhang (CMU). ACM SIGMETRICS 2000. • + Enabling Conferencing Applications on the Internet using an Overlay Multicast Architecture, Yang-hua Chu, Sanjay G. Rao, Srinivasan Seshan and Hui Zhang (CMU). SIGCOMM 2001 CSE 581 – Multicast Overlays Charles ‘Buck’ Krasic

3. The Problem • Can the Internet today support large-scale Internet broadcasting?  NO • Traditional unicast model does not scale • IP Multicast is not the right solution “Madonna’s London gig broadcast live on the Internet… But as she burst into her first song on Tuesday night, many fans were still queueing up outside the virtual venue, struggling to connect to the live feed.” —CNN News (Nov 29, 2000) CSE 581 – Multicast Overlays Charles ‘Buck’ Krasic

4. The Problem • Traditional unicast model does not scale • Millions of clients server and network meltdown CSE 581 – Multicast Overlays Charles ‘Buck’ Krasic

5. Traditional solution: IP Multicast • Global broadcast distribution primitive • Source sends single stream • Routers split stream towards all clients • IP Multicast to the rescue CSE 581 – Multicast Overlays Charles ‘Buck’ Krasic

6. Concerns with IP Multicast • Scalability with number of groups • Routers maintain per-group state • Analogous to per-flow state for QoS guarantees • Aggregation of multicast addresses is complicated • Supporting higher level functionality is difficult • IP Multicast: best-effort multi-point delivery service • End systems responsible for handling higher level functionality • Reliability and congestion control for IP Multicast complicated • Inter-domain routing is hard. • No management of flat address space. • Deployment is difficult and slow • ISP’s reluctant to turn on IP Multicast CSE 581 – Multicast Overlays Charles ‘Buck’ Krasic

7. Multicast Proxies Application-aware computation Unicast connections Locally scoped multicast groups Alternative: Multicast Overlay Overlay network provides multicast service above substrate (IP) Application-level multicast Application-specific customization CSE 581 – Multicast Overlays Charles ‘Buck’ Krasic

8. Stan1 CMU Stan2 Berk2 Gatech Berk1 CMU Stan2 Stan1 Berk2 Gatech Berk1 Overlay Architecture • Maintain a complete overlay graph (COG) of all group members • Links correspond to unicast paths • Link costs maintained by polling Step 0 • “Mesh”: Subset of complete graph may have cycles and includes all group members • Members have low degrees (makes mesh a subset of COG) • Shortest path delay between any pair of members along mesh is small Step 1 CSE 581 – Multicast Overlays Charles ‘Buck’ Krasic

9. Stan1 Stan2 CMU Berk1 Gatech Berk2 Overlay Architecture (2) • Source rooted shortest delay spanning trees of mesh • Constructed using well known routing algorithms • Members have low degrees • Small delay from source to receivers Step 2 CSE 581 – Multicast Overlays Charles ‘Buck’ Krasic

10. Multicast Proxy Discovery • Bootstrap using list of well-known rendezvous proxies • Gossip-style discovery • Pick random proxy Xj; send it our membership list • Xj merges this into its own list • Xj responds with part of its own list • Gradually all proxies discover each other Summary: well-known rendezvous + gossip to disseminate session membership CSE 581 – Multicast Overlays Charles ‘Buck’ Krasic

11. Mesh Construction and Optimization • Set up connections with up to k other proxies • k = degree restriction • Periodically probe a random proxy, Xj • Measure unicast distance to Xj • Use local optimization algorithm to determine suitability for picking as a neighbor • If Xj has better route towards source than a current neighbor, then replace that neighbor with Xj Summary: Local optimization based on unicast distances to choose mesh neighbors CSE 581 – Multicast Overlays Charles ‘Buck’ Krasic

12. Application-level Routing • Variant of distance vector routing • shortest path routing protocol • routing table entries only for source proxies • to detect loops, store entire path in routing table • Build distribution trees from routing tables • source-rooted trees • reverse shortest path • forward data using reverse path forwarding Summary: Shortest path routing to build source-rooted trees CSE 581 – Multicast Overlays Charles ‘Buck’ Krasic

13. Scattercast Evaluation • Simulate the Gossamer control protocol • 1000 node topology, approx. 4000 edges • Constructed using gt-itm topology generator • Measure: • Average latency compared to multicast: • Cost Ratio = (avg latency with Gossamer) (avg latency with multicast) • Time to construct stable overlay: • Time for changes in overlay structure to stop • Packet duplication overhead • Number of physical Internet links with multiple copies of same packet CSE 581 – Multicast Overlays Charles ‘Buck’ Krasic

14. Variation of Cost Ratio with Session Size Cost ratio remains low (< 1.9) even as session size increases CSE 581 – Multicast Overlays Charles ‘Buck’ Krasic

15. Time to Stability Most mesh changes occur early on in the protocol CSE 581 – Multicast Overlays Charles ‘Buck’ Krasic

16. Packet Duplication Overhead Most heavily loaded link for Gossamer: 14 copies Most heavily loaded link for unicast: 99 copies Load on physical links is lower for Gossamer than for vanilla unicast CSE 581 – Multicast Overlays Charles ‘Buck’ Krasic

17. Contributions • Overlay Architecture • Lower-level constructs a routing mesh, shared across multicast sessions • Mesh is a subset of complete virtual graph • Mesh is constructed through gossiping • Nodes continuously arrive and leave the mesh • Use dynamic optimization to improve mesh efficiency • Must correct for path failures, esp. partitions • Each multicast session tree constructed above mesh CSE 581 – Multicast Overlays Charles ‘Buck’ Krasic

18. Contributions (continued) • Evaluations of Overlay Approach • Mostly simulation based • Metrics • Efficiency of chosen paths • Cost ratio, Relative Delay Penalty(RDP), Link stress, Normalized Resource Usage • Mesh convergence times • Time for gossiping to stabilize CSE 581 – Multicast Overlays Charles ‘Buck’ Krasic

19. Advantages of Approach • Localize hard multicast problems • Bandwidth allocation, congestion control, loss recovery are tractable • Simplify network layer via intelligent infrastructure • No inter-domain multicast routing required • Impose access restrictions within overlay proxies • Leverage well-understood wide-area unicast protocols and naming schemes • Incorporate app-specific semantics within proxies to address heterogeneity • App-specific reliability and data scheduling • On-the-fly content and bandwidth adaptation CSE 581 – Multicast Overlays Charles ‘Buck’ Krasic

20. Disadvantages • Topology of Overlay trees only approximate • Link stress: number of times a packet crosses a given physical link • For IP Multicast: 1 • Overlay > 1 • Overlays represent are a trade-off relative to pure unicast or native IP multicast • Relative to IPM, overlays gain benefits in exchange for: • Lower overall bandwidth efficiency • Higher end-to-end latency CSE 581 – Multicast Overlays Charles ‘Buck’ Krasic

21. Scattercast and Narada • Topology discovery through learning/gossiping • 2 levels: multicast tree over unicast mesh • Scattercast mech uses directed edges: • Simplifies mesh optimization (eliminates add/remove race). • More robust against unplanned partition • Narada emphasizes low-latency more • Narada target application is video conferencing • Scattercast chose shared whiteboard and internet radio broadcast • Scattercast group seems to moving toward application specific enhancements CSE 581 – Multicast Overlays Charles ‘Buck’ Krasic

22. Overcast • Overcast: direct tree construction • Doesn’t share information across sessions • Prone to partitions? • Less scaleable? • Emphasizes deployment • Protocols do everything in the upstream direction to ensure compatibility with NAT and web proxies • Everything done with http • Overcast also emphasizes role of persistent storage • Target application is efficient download of large production quality MPEG video files CSE 581 – Multicast Overlays Charles ‘Buck’ Krasic

23. Inktomi • Mostly static approach • Overlay topology decided based on operator policy • Limited automatic adaptation when substrate topology changes • Emphasizes explicit network management tools more • Tools for the broadcast war room • Vaporware? • Where are the broadcasts? CSE 581 – Multicast Overlays Charles ‘Buck’ Krasic

24. Further Work and Improvements • CMU SIGCOMM ’01 • Use better metrics during mesh construction/optimization (bandwidth and latency) • Evaluate on real internet • Effects of Policy routing? • Improve scalability? • Would like all metrics to have sub-linear relationship to group size • Still linear: • Time for mesh to converge • Bandwidth and latency penalties • Application specific processing • Congestion control, content adaptation CSE 581 – Multicast Overlays Charles ‘Buck’ Krasic