View
228
Download
1
Tags:
Embed Size (px)
Citation preview
Application Layer Multicast
- Swati Agarwal
What Is Multicast?
• 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
Key:
Unicast transfer
Broadcast transfer
Multicast transfer
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
Example Applications
• Video / Audio broadcast (one sender)
• Conferencing (many senders)
• Real time news distribution
• Data distribution
IP Multicast
•Invented by S. Deering
•Senders transmit IP datagrams to the group identified by a class D IP address
•Efficient bandwidth utilization
Berkeley
Gatech Stanford
CMU
Routers with multicast support
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 multicastStanford
CMU
Stan1
Stan2
Berk2
Overlay TreeGatech
Berk1
Berkeley
Gatech Stan1
Stan2
Berk1
Berk2
CMU
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 Resultsstable 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 for 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
Bandwidth Efficient Overlay Trees
10 Mb/s
100
Mb/
s
100 Mb/s
R
1
2
R
1
2
R 1 2 R 12
“…three ways of organizing the root and the nodes into a distribution tree.”
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
5
57
1
10
2
103
8
R
1 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
1
10
2
20
R
1 2
Overcast network treeRound 1
15
R
2
1
Overcast network treeRound 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• 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
1
1.1 1.2 1.3
1.2.1 1.2.31.2.2
1.2.2.1
Birth certificates for 1.2.2, 1.2.2.1
No change observed.
Propagation halted.
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
R1
1
2
3
4
5
6
R2 R3
Key:
Content query (multicast join)
Query redirect
Content delivery
Evaluation
Results
Conclusions
• A simple and bandwidth-efficient tree-building protocol
• Dynamically adapt to changes
• Scales to large networks – based on simulation studies