What Is Multicast? Key: Unicast transfer Broadcast transfer - PDF document

What Is Multicast? Key: Unicast transfer Broadcast transfer • Unicast Multicast transfer – One-to-one – Destination – unique Application-Level Multicast receiver host address • Broadcast Routing – One-to-all – Destination – address of network Michael Siegenthaler • Multicast CS 614 – Cornell University November 2, 2006 – One-to-many – Multicast group must be identified – Destination – address of group A few slides are borrowed from Swati Agarwal, CS 614, Fall 2005. Few slides are based on slides originally developed by (1) L. Armstrong, Univ of Delaware, (2) Rao - www.ibr.cs.tu- bs.de/events/netgames2002/presentations/rao.pdf Some Applications… Why Multicast? • Streaming broadcast media • Traditional mechanisms for one-to-one – Radio communication do not scale – Television – Overloading a single source • Live events involving multiple parties – Network links carry the same traffic separately for – Video conferencing each receiver – Distance learning • Multicasting solves both problems. In the ideal • Content distribution case: – Software – Source only needs to transmit one or a few copies of – Movies the data • All of these involve one-to-many communication – Each link only caries one copy of the data Network-Level (IP) Multicast Problems with IP Multicast Cornell Davis • Deployment is difficult – Requires support from routers MIT • Scalability Berkeley – Routers maintain per-group state Routers with multicast support • Difficult to support higher level functionality • Reserved a portion of the address space – Reliability, congestion control • Route packets to the group identified by the class D destination IP address • Billing issues • “You put packets in at one end, and the network • As a result, barely anybody uses it conspires to deliver them to anyone who asks.” – David Clark 1

Application layer multicast Benefits Cornell Dav1 Davis • Scalability Dav2 – Routers do not maintain per group state • Easy to deploy MIT Berk1 – No change to network infrastructure Berkeley – Just another application • Simplifies support for higher level Berk2 Overlay Tree Dav1 functionality Cornell – Can utilize existing solutions for unicast Dav2 congestion control MIT Berk1 Berk2 Application-Level Multicast A few concerns… • Performance penalty • Two basic architectures are possible – Redundant traffic on physical links – Proxy-based • stress = number of times a semantically identical packet traverses a given link • Dedicated server nodes exchange content among – Increase in latency themselves • stretch = ratio of latency in an overlay network compared to a baseline such as unicast or IP multicast • End clients download from one of the servers and • Constructing efficient overlays do not share their data – Application needs differ – Peer to peer • Adapting to changes • All participating nodes share the load – Network dynamics – Group membership – members can join and leave • “End clients” also act as servers and relay data to – Both of these contribute to churn other nodes Overcast Components • Single source multicast • Root : central source (may be replicated) • Proxy-based architecture • Node : internal overcast nodes with – Assumes nodes are well-provisioned permanent storage • Reliable delivery – Software or video distribution – Organized into distribution tree – Buffered streaming media • Client : final consumers (HTTP clients) • “Live” could mean delayed by seconds or minutes • Long term storage at each node • Easily deployable, seeks to minimize human intervention R • Works in the presence of NATs and firewalls Root Node Client 2

Self-Organizing Algorithm Bandwidth Efficient Overlay Trees • A new server initially joins at the root s 1 • Iteratively moves farther down the tree / b M 0 0 – Relocate under a sibling if doing so does not sacrifice 1 bandwidth back to the root 10 Mb/s R – This results in a deep tree with high bandwidth to every node 100 Mb/s • A node periodically reevaluates its position 2 – May relocate under a sibling – May become a sibling of its parent “ …three ways of organizing the root and the nodes into a distribution tree. ” • Fault tolerant – If parent fails, relocate under grandparent 1 R R R 1 2 2 1 2 Self-Organizing Algorithm Connecting Clients • Client contacts the root via an HTTP request R R R – Allows unmodified clients to connect – URLs provide flexible addressing • Hostname identifies the root 10 20 • Pathname identifies the multicast group 1 2 2 • Root redirects the client to a node which is 1 15 geographically close to the client – Root must be aware of all nodes 1 2 Overcast network tree Overcast network tree Round 1 Round 2 State Tracking – the Up/Down Client joins Key: protocol Content query (multicast join) Query redirect 1 Content delivery • Each node maintains state about all nodes in No change its subtree observed. Propagation 1.1 1.2 1.3 halted. 1 3 – Reports the “births” and R 1 R 2 R 3 “deaths” among its Birth children certificates 1.2.1 1.2.2 1.2.3 2 4 6 for 1.2.2, – Information is aggregated 1.2.2.1 on its way up the tree • Each child periodically 1.2.2.1 5 checks in with its parent – Support NATs/firewalls 3

Is The Root Node A Single Evaluation 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 Evaluation Evaluation Lease period = how long a parent will wait to hear from a child before reporting its death Enabling Conferencing Applications Overcast Conclusion on the Internet using an Overlay Multicast Architecture • Designed for software, video distribution – Bit-for-bit integrity, not time critical • Latency and bandwidth are important • Could fullfill a similar role as content – Real-time interaction between users • Evaluates how to optimize for dual metrics distributions systems such as Akamai • Small-scale (10s of nodes) peer to peer • Also works for “live” streams, if sufficient architecture buffering delay is used – Single source at any given time • Gracefully degradable – Better to give up on lost packets than to retransmit and have them arrive too late to be useful 4

Self-Improving Algorithm Evaluation • Two-step tree building process (Narada) • Schemes for constructing overlays – Construct a mesh , a rich connected graph – Sequential Unicast – Choose links from the mesh using well-known • Hypothetical construct for comparisons purposes routing algorithms – Random • Routing chooses shortest widest path • Baseline to compare against – Picks highest bandwidth, and opts for lowest – Latency-Only latency when there are multiple choices – Bandwidth-Only – Exponential smoothing and discrete – Bandwidth-Latency bandwidth levels are used to deal with instability due to dynamic metrics Evaluation Comparison of schemes • Primary Set – 1.2 Mbps • Primary Set – 2.4 Mbps • Extended Set – 2.4 Mbps • Primary Set contains well connected nodes – North American university sites • Extended Set – more heterogeneous environment – Some ADSL links, hosts in Europe and Asia Bandwidth – primary set, 1.2 Mbps Bandwidth – extended set, 2.4 Mbps 5

RTT – extended set, 2.4 Mbps Conclusion • It is possible to build overlays that optimize for both bandwidth and latency • Unclear whether these results scale to larger group sizes More Recent Work Discussion Questions • SplitStream • Is a structured overlay the right approach, or is something more random better? – Uses multiple overlapping trees – How much do we really care about stress or • Various DHT-based approaches stretch? • BitTorrent • Both papers mainly use heuristics – Unstructured, random graphs – Could a more mathematically based approach do better? 6