Application layer multicast routing

1. Application layer multicast routing

2. What Is Multicast? Key: Unicast transfer Broadcast transfer Multicast transfer • Unicast • One-to-one • Destination – unique receiver host address • Broadcast • One-to-all • Destination – address of network • Multicast • One-to-many • Multicast group must be identified • Destination – address of group

3. Multicast application examples • Financial services • Delivery of news, stock quotes, financial indices, etc • Remote conferencing/e-learning • Streaming audio and video to many participants (clients, students) • Interactive communication between participants • Data distribution

4. Routers with multicast support IP Multicast Gatech Stanford CMU Berkeley • Highly efficient bandwidth usage • Key Architectural Decision: Add support for multicast in IP layer

5. So what is the big issue … 15 years since proposal, but no wide area IP multicast deployment • Scalability (with number of groups) -- Routers maintain per-group state -- Require every group to dynamically obtain a globally unique address from the multicast address space • IP Multicast: best-effort multi-point delivery service -- Providing higher level features such as reliability, congestion control, flow control, and security has shown to be more difficult than in the unicast case • Other issues -- Change in infrastructure -- DOS attacks -- Network management, billing etc. -- works across space, not across time Can we achieve efficient multi-point delivery without IP-layer support?

6. Application layer multicast Stan1 Gatech Stanford Stan2 CMU Berk1 Berkeley Berk2 Overlay Tree Stan1 Gatech Stan2 CMU Berk1 Berk2

7. Pros and Cons • Scalability • Routers do not maintain per-group state • End systems do, but they participate in very few groups • No need for globally consistent naming, allows application specific naming • Easier to deploy • No infrastructural support • Potentially simplifies support for higher level functionality • Leverage computation and storage of end systems • Leverage solutions for unicast congestion, error and flow control • Efficiency concerns • redundant traffic on physical links • increase in latency due to end-systems

8. Open questions! What are the performance implications of using an overlay? How do end systems with limited topological information cooperate to construct good overlay structures? What metric should the optimization be based on? End-to-end overlay vs. proxy-based overlay? Does high bandwidth data dissemination require special attention? A lot of work has been done to tackle these questions, for eg. Narada, Yoid, Scattercast, ALMI, Overcast, ROMA, NICE, Bullet, Selectcast, Scribe .…

9. Offering bandwidth-intensive content on demand - primarily video content - necessary to maintain full fidelity Long-running content availability for multiple clients - data distribution system for businesses Bandwidth bottlenecks develop as multiple requests are made Overcast : Motivation Key: Line thickness indicates desired bandwidth usage by sending entity

10. What is Overcast? • An application level multicasting system • Provides scalable and reliable single-source multicast • Goals • Overlay structured to maximize bandwidth • Utilize network topology efficiently - limit repeated usage of physical links • No change to existing routers - easy deployment • Draws upon work in content distribution, caching, and server replication

11. Key insight and contribution’s • Add storage to the network fabric for reliability and scalability - use disk-space to time shift multicast distribution - trade-off between disk-space and bandwidth • Contribution’s • a simple protocol for forming efficient and scalable distribution trees that dynamically adapt to changes • a protocol for maintaining global status at the root of the changing distribution tree

12. System structure The overlay comprises of : • A central source (may be replicated for fault tolerance) • A no of overcast nodes (standard PCs with lot’s of storage) - organized into a distribution tree rooted at the source - bandwidth efficient trees • Final Consumers – members of the multicast group - allows unmodified HTTP clients to join The business model involves a content provider who installs these nodes (proxies) in the fabric and the overlay acts as a data distribution system for businesses

13. R 1 R R R 1 2 2 1 2 Bandwidth Efficient Overlay Trees 1 100 Mb/s 10 Mb/s 100 Mb/s 2

14. How Does Overcast Build Bandwidth Efficient Trees? • Goal – maximize bandwidth to root for all nodes • Places a new node as far away from root as possible without sacrificing bandwidth • Additional details • Bandwidth: measured by timing a 10KB download • Hystersis: nodes with bandwidth within 10% of each other considered equal • in case of a tie, choose the closest parent as determined by traceroute • Won’t the results of this algorithm change over time?

15. R R 1 2 3 The node addition algorithm 5 10 10 3 8 1 7 5 2 Physical network substrate Overcast distribution tree

16. But …. • What is the 10 Kb download measuring? • TCP begins with a ‘slow start’ • Download is over by the time it switches to AIMD • Does not give a measure of long-term TCP throughput • Where is the bottleneck bandwidth? • Nodes on the edges -- access links (leads to linear trees) • Nodes in the core - fat pipes (a 10 Kbps download does not give the bandwidth) - bottleneck due to congestion, which can vary on a short time scale • May have been more relevant at the time of the work …. • The impact of the child nodes on the bandwidth ….

17. Dynamic Topology • A node periodically reevaluates its position in the tree by measuring the bandwidth been itself and • its parent (baseline) • its grandparent • all its siblings • Node can relocate to become • child of a sibling • sibling of a parent • Inherently tolerant of non-root failures • if the parent dies, a node moves up the ancestry tree

18. R R R 1 2 2 1 Interactions Between Node Adding And Dynamic Topology 10 20 1 15 2 Physical network substrate Overcast distribution tree Round 1 Overcast distribution tree Round 2

19. But …. • What happens when bandwidth keeps fluctuating? • 10% hysterisis gap is ineffective given the way the bandwidth is measured • Smart choice of bandwidth’s for the network edges in the generated graph. • No evaluation in case of bandwidth flux • Even if the system does converge, the convergence time is limited by the probes to siblings and ancestors

20. State tracking – the Up/Down protocol • An efficient mechanism is needed to exchange information between nodes • must scale sublinearly in terms of network usage • may scale linearly in terms of storage • Assumes information either • changes slowly (E.g., Health status of nodes) • can be combined efficiently from multiple children into a single description (E.g., Totals from subtrees) • Each node maintains state about all nodes in its subtree

21. Management of information with the Up/Down protocol • Each node periodically contacts its parent • Parents assume a child (and all descendants) has died if the child fails to contact within some interval • During contact, a node reports to its parent • Death certificates • Birth certificates • Extra information • Information propagated from children • Sequence numbers used to prevent race conditions

22. 1.2.2 1.2.2.1 Scaling sublinearly in terms of network usage 1 • A node (and descendants) relocates under a sibling • The sibling must learn about all the node’s descendants • Birth certificates • The sibling passes this information to the (original node’s) parent • The parent recognizes no changes and halts further propagation No change observed. Propagation halted. 1.1 1.2 1.3 Birth certificates for 1.2.2, 1.2.2.1 1.2.1 1.2.3

23. The client side – how to join a multicast group • Clients join a multicast group through a typical HTTP GET request • Root determines where to connect the client to the multicast tree using • Pathname of URL (multicast group being joined) • Status of Overcast nodes • Location of client* • Root selects “best” server and redirects the client to that server

24. R1 R2 R3 1 3 2 4 5 6 Client joins Key: Content query (multicast join) Query redirect Content delivery

25. Evaluation • Based on simulations with GT-ITM • Five 600-node graphs • 3 transit domains (backbone) • 8 stub networks per domain • 25 nodes per stub • Assigned Bandwidth • 45Mbps, 1.5Mbps, 100Mbps • T3, T1, Fast Ethernet • One node supports 20 clients • (MPEG-1 video)

26. Bandwidth utilization • Backbone • Adds transit nodes first • Random • All nodes chosen randomly • Fraction = Overcast bandwidth/Optimal bandwidth • At full participation – distribution trees are different

27. Discussion (cont.) • Is a tree structure effective for high bandwidth data dissemination? • Kostic et. al. differ! • Bullet achieves this by distributing data in a disjoint manner to strategic points - the nodes organize as a mesh • For good performance, the content provider will have to manually choose strategically placed nodes in the core which are anyway connected by big fat pipes – so what is the relevance of the provided automation? • What are the reliability semantics? - what if a node is down while a transmission completes – how does the log help, does the node receive the file, does the root know of this? - when is data removed from the storage? • Not suitable for live streams - although the authors were never aiming for this!

28. Discussion (cont.) • What about NAT’s - how can any overcast node be inside a NAT? • In case of a tie in bandwidth measure, why not use latency instead of hop count – leads to a shortest widest kind of selection • Where does the root get the location of client from, when doing server selection? • Simply coupled TCP connections not the best way to realize the bandwidth potential of the topology - May be a problem in case of heterogeneous receivers - ROMA uses loosely coupled connections with fast forward error correction • Seems more like a contribution to smarter content distribution systems than to application level multicasting • Bit Torrent does the same thing!

29. Enabling Conferencing Applications on the Internet using an Overlay Multicast Architecture

30. Past Work • Self-organizing protocols • Yoid (ACIRI), Narada (CMU), Scattercast (Berkeley), Overcast (CISCO), Bayeux (Berkeley), … • Construct overlay trees in distributed fashion • Self-improve with more network information • Performance results showed promise, but… • Evaluation conducted in simulation • Did not consider impact of network dynamics on overlay performance

31. Focus of This Paper • Can End System Multicast support real-world applications on the Internet? • Study in context of conferencing applications • Show performance acceptable even in a dynamic and heterogeneous Internet environment • First detailed Internet evaluation to show the feasibility of End System Multicast

32. Enhancements of Overlay Design • Two new issues addressed • Dynamically adapt to changes in network conditions • Optimize overlays for multiple metrics • Latency and bandwidth • Study in the context of the Narada protocol (Sigmetrics 2000) • Techniques presented apply to all self-organizing protocols

33. Optimize Overlays for Dual Metrics Source rate 2 Mbps 60ms, 2Mbps • Prioritize bandwidth over latency • Break tie with shorter latency Receiver X Source 30ms, 1Mbps

34. smoothed estimate discretized estimate Adapt to Dynamic Metrics • Adapt overlay trees to changes in network condition • Monitor bandwidth and latency of overlay links • Link measurements can be noisy • Aggressive adaptation may cause overlay instability transient: do not react persistent:react • Capture the long term performance of a link • Exponential smoothing, Metric discretization raw estimate bandwidth time

35. Evaluation overview • Compare performance of their scheme with • -- Benchmark (IP Multicast) • -- Other overlay schemes that consider fewer network metrics

36. Three Scenarios Considered Primary Set 1.2 Mbps Primary Set 1.2 Mbps Primary Set 2.4 Mbps Extended Set 2.4 Mbps • Does ESM work in different scenarios? • How do different schemes perform under various scenarios? (lower)  “stress” to overlay schemes  (higher)

37. Internet pathology BW, Primary Set, 1.2 Mbps Naïve scheme performs poorly even in a less “stressful” scenario RTT results show similar trend

38. Scenarios Considered Primary Set 1.2 Mbps Primary Set 2.4 Mbps Extended Set 2.4 Mbps • Does an overlay approach continue to work under a more “stressful” scenario? • Is it sufficient to consider just a single metric? • Bandwidth-Only,Latency-Only (lower)  “stress” to overlay schemes  (higher)

39. no strong correlation between latency and bandwidth BW, Extended Set, 2.4 Mbps Optimizing only for latency has poor bandwidth performance

40. Bandwidth-Only cannot avoidpoor latency links or long path length RTT, Extended Set, 2.4Mbps Optimizing only for bandwidth has poor latency performance

41. Discussion • Does a source rate of 2.4 Mbps represent a realistic setting! • Issues not addressed • Scalability - how to lower network costs for large sized groups - how to make the tree building algorithm more scalable • Extremely dynamic environments - how to achieve shorter time scale adaptation - trade-off between overlay stability and the detection time • Optimizing for 2 dynamic metrics • Optimizing for both bandwidth and latency may be tricky; the discretization and hysterisis combined with the probe latency may affect the granularity of adjustment

42. Discussion (cont) • Is end-system multicast suitable for real time applications? • Does provide distribution across time • But for applications with timing constraints, it may not be such a good idea! • These are some of the most well connected machined on the Internet! • Is the internet a good place for such measurements and comparisons? • The authors do a decent job of making the analysis fair and objective

43. On a general note …. • What is the impact of such overlays on the other traffic? • The usefulness of the overlay concept • Will they be a success iff nobody uses them? • Interaction between multiple independent overlays • What is the motivation for their deployment? • Users come in and go out ! • Cheating by end hosts • All the ALM’s provide a best effort service! • are they comparable? • which one provides the best best-effort service