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/netgames2002/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
Stan1
Stan2
CMU
Berk1
Berkeley
Berk2
Overlay Tree
Stan1
Gatech
Stan2
CMU
Berk1
Berk2
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 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
1
10 Mb/s
R
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
10
R
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.1
1.2
1.2.2
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
R1
R2
1
3
2
4
R3
5
6
Evaluation
Results
Conclusions
• A simple and bandwidth-efficient treebuilding protocol
• Dynamically adapt to changes
• Scales to large networks – based on
simulation studies