1. Application Layer Multicast
- Swati Agarwal

2. What Is Multicast? Unicast Broadcast Multicast One-to-one
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
Few slides are based on slides originally developed by (1) L. Armstrong, Univ of Delaware, (2) Rao -

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

4. Routers with multicast support
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

5. 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

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

7. Benefits Scalability Easy to deploy
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

8. A few concerns.. Performance penalty Constructing efficient overlays
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

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

10. 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

11. 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

12. 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

13. Experimental Results
Dip due to congestion
stable

14. 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

15. Bandwidth – primary set, 1.2 Mbps

16. Bandwidth – extended set, 2.4 Mbps

17. RTT – extended set, 2.4 Mbps

18. 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

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

20. 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

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

22. 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

23. Bandwidth Efficient Overlay Trees1
100 Mb/s R
10 Mb/s
100 Mb/s 2
“…three ways of organizing the root and the nodes into a distribution tree.” R 1 2 R 1 2 R 1 2

24. 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

25. The node addition algorithm1 2 3 5 10 10 3 8 1 7 5 2
Overcast distribution tree

26. 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

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

28. 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

29. 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

30. Scaling sublinearly in terms of network usage1
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
1.2.2
Birth certificates for 1.2.2,
1.2.1
1.2.3

31. 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

32. 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

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

34. Evaluation

35. Results

36. Conclusions A simple and bandwidth-efficient tree-building protocol
Dynamically adapt to changes
Scales to large networks – based on simulation studies