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