Application Layer Multicast Swati Agarwal What Is Multicast

Application Layer Multicast - Swati Agarwal

What Is Multicast? Key: Unicast transfer • Unicast Broadcast transfer Multicast transfer – 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 Few slides are based on slides originally developed by (1) L. Armstrong, Univ of Delaware, (2) Rao - www. ibr. cs. tubs. de/events/netgames 2002/presentations/rao. pdf

Example Applications • • Video / Audio broadcast (one sender) Conferencing (many senders) Real time news distribution Data distribution

IP Multicast Gatech Stanford CMU Berkeley Routers with multicast support • Invented by S. Deering • Senders transmit IP datagrams to the group identified by a class D IP address • Efficient bandwidth utilization

Key concerns with IP Multicast • Deployment is difficult – Requires support from routers • Scalability – Routers maintain per-group state • Difficult to support higher level functionality – Reliability, congestion control

Application layer multicast Gatech Stanford Stan 1 Stan 2 CMU Berk 1 Berkeley Overlay Tree Gatech Berk 2 Stan 1 Stan 2 CMU Berk 1 Berk 2

Benefits • Scalability – Routers do not maintain per group state • Easy to deploy – No change to network infrastructure • Simplifies support for higher level functionality – Can utilize existing solutions for unicast congestion control

A few concerns. . • Performance penalty – Redundant traffic on physical links – Increase in latency • Constructing efficient overlays – Application needs differ • Adapting to changes – Network dynamics – Group membership – members can join and leave

Enabling Conferencing Applications on the Internet using an Overlay Multicast Architecture -Y. Chu, S. Rao, S. Seshan and H. Zhang

End System Multicast • Prior work show promising performance results – Studies based on simulations, static metrics, controlled environments • Can End System Multicast support applications with demanding performance requirements on Internet? – Study in context of conferencing applications

End System Multicast • Characteristics of the target applications – Small number of users – Require high bandwidth – Latency sensitive • Need for self-organizing protocols to adapt to dynamic latency and bandwidth metrics • Study in context of Narada Protocol – Techniques apply to all self-organizing protocols

Optimizing overlays for dual metrics • Prioritize bandwidth over latency – Member picks highest bandwidth path to every other member – If multiple paths with same bandwidth, pick the lowest latency path among those • Use exponential smoothing, discrete bandwidth levels to deal with instability due to dynamic metrics

Experimental Results stable Dip due to congestion

Comparison of schemes • Primary Set – 1. 2 Mbps • Primary Set – 2. 4 Mbps • Extended Set – 2. 4 Mbps • Primary Set contains well connected nodes • Extended Set – more heterogeneous environment

Bandwidth – primary set, 1. 2 Mbps

Bandwidth – extended set, 2. 4 Mbps

RTT – extended set, 2. 4 Mbps

Results - summarized • Enable optimized construction of efficient overlays • Random overlays perform poorly • Overlays adapting to static metrics perform poorly – Fail to react to network congestion • Both bandwidth and latency metrics need to be considered

Conclusion • Good performance for conferencing applications with stringent bandwidth and latency demands • Issues – Scalability - large groups – Adapting to highly dynamic environments

Overcast: Reliable Multicast • Provide scalable and reliable single-source multicast • Motivated by problems faced by content providers – Distribution of bandwidth intensive content on demand – Long-running content to many clients • Goals – Overlay structured to maximize bandwidth – Utilize network topology efficiently

Contributions • Storage at nodes for reliability and scalability • Simple protocol forming efficient and scalable distribution trees that dynamically adapts to changes • Protocol allowing clients to join the group quickly

Components • Root : central source (may be replicated) • Node : internal overcast nodes with permanent storage – Organized into distribution tree • Client : final consumers (HTTP clients) R Root Node Client

1 10 0 M b/ s Bandwidth Efficient Overlay Trees 10 Mb/s R 0 10 s b/ M 2 “…three ways of organizing the root and the nodes into a distribution tree. ” 1 R R 2 1 2 R 2 1

Building Bandwidth Efficient Tree • Goal – maximize bandwidth to root for all nodes • Places a new node as far away from root as possible without sacrificing bandwidth • Nodes equally good if measured bandwidth within 10% – Select closest node as determined by traceroute

The node addition algorithm R R 5 10 1 10 3 8 1 2 7 5 2 3 Overcast distribution tree

Dynamic Topology • Overcast’s optimization metric will change over time • A node periodically reevaluates its position in the tree by measuring the bandwidth between 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 – On dead parent a node can move up the ancestry tree

Interactions Between Node Adding And Dynamic Topology R R 10 20 1 R 2 2 1 15 1 2 Overcast network tree Round 1 Overcast network tree Round 2

State tracking – the Up/Down protocol • An efficient mechanism is needed to exchange information between nodes • 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

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

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 1. 1 1. 2. 2. 1 • The parent recognizes no changes and halts further propagation 1. 3 1. 2. 3 No change observed. Propagation halted. Birth certificates for 1. 2. 2, 1. 2. 2. 1

Is The Root Node A Single Point Of Failure? • Root is responsible for handling all join requests from clients – Note: root does not deliver content • Root’s Up/Down protocol functionality can not be easily distributed – Root maintains state for all Overcast nodes • Solution: configure a set of nodes linearly from root before splitting into multiple branches – Each node in the linear chain has sufficient information to assume root responsibilities – Natural side effect of Up/Down protocol

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

Client joins Key: Content query (multicast join) Query redirect Content delivery R 1 R 2 1 3 2 4 R 3 5 6

Evaluation

Results

Conclusions • A simple and bandwidth-efficient treebuilding protocol • Dynamically adapt to changes • Scales to large networks – based on simulation studies