CSE 581 Multicast Overlays

1
Multicast Overlays

• CSE 581 Internet Technology
• (Winter 2002)
• Instructor Prof. Wu Chang Feng
• Presenter Charles Buck Krasic

2
Papers Covered

• An Architecture for Internet Content Distribution
  as an Internet Infrastructure. Yatin Cahwathe,
  Steve McCanne, Eric Brewer (UCB). Feb 2000,
  Unpublished.
• The Inktomi Overlay Solution for Streaming Media
  Broadcasts. Inktomi Corporation. (Brewer
  Co-founder Chief Scientist, McCanne CTO).
  WWW whitepaper.
• Overcast Reliable Multicasting with an Overlay
  Network. John Jannotti, David K. Gifford, Kirk
  L. Johnson, M. Frans Kaashoek, James W. OToole,
  Jr (Cisco). OSDI 2000
• A Case for End System Multicast. Yang-hua Chu,
  Sanjay G. Rao, and Hui Zhang (CMU). ACM
  SIGMETRICS 2000.
• Enabling Conferencing Applications on the
  Internet using an Overlay Multicast Architecture,
  Yang-hua Chu, Sanjay G. Rao, Srinivasan Seshan
  and Hui Zhang (CMU). SIGCOMM 2001

3
The Problem

• Can the Internet today support large-scale
  Internet broadcasting? ? NO
• Traditional unicast model does not scale
• IP Multicast is not the right solution

Madonnas London gig broadcast live on the
Internet But as she burst into her first song on
Tuesday night, many fans were still queueing up
outside the virtual venue, struggling to connect
to the live feed. CNN News (Nov 29, 2000)
4
The Problem

• Traditional unicast model does not scale
• Millions of clients ? server and network meltdown

5
Traditional solution IP Multicast

• IP Multicast to the rescue

• Global broadcast distribution primitive
• Source sends single stream
• Routers split stream towards all clients

6
Concerns with IP Multicast

• Scalability with number of groups
• Routers maintain per-group state
• Analogous to per-flow state for QoS guarantees
• Aggregation of multicast addresses is complicated
• Supporting higher level functionality is
  difficult
• IP Multicast best-effort multi-point delivery
  service
• End systems responsible for handling higher level
  functionality
  
• Reliability and congestion control for IP
  Multicast complicated
• Inter-domain routing is hard.
• No management of flat address space.
• Deployment is difficult and slow
• ISPs reluctant to turn on IP Multicast

7
Alternative Multicast Overlay
Overlay network provides multicast service
above substrate (IP)
Application-level multicast
Application-specific customization
8
Overlay Architecture

• Maintain a complete overlay graph (COG) of all
  group members
• Links correspond to unicast paths
• Link costs maintained by polling

Step 0

• Mesh Subset of complete graph may have cycles
  and includes all group members
• Members have low degrees (makes mesh a subset of
  COG)
• Shortest path delay between any pair of members
  along mesh is small

Step 1
9
Overlay Architecture (2)

• Source rooted shortest delay spanning trees of
  mesh
• Constructed using well known routing algorithms
• Members have low degrees
• Small delay from source to receivers

Step 2
10
Multicast Proxy Discovery

• Bootstrap using list of well-known rendezvous
  proxies
• Gossip-style discovery
• Pick random proxy Xj send it our membership list
• Xj merges this into its own list
• Xj responds with part of its own list
• Gradually all proxies discover each other

Summary well-known rendezvous gossip to
disseminate session membership
11
Mesh Construction and Optimization

• Set up connections with up to k other proxies
• k degree restriction
• Periodically probe a random proxy, Xj
• Measure unicast distance to Xj
• Use local optimization algorithm to determine
  suitability for picking as a neighbor
• If Xj has better route towards source than a
  current neighbor, then replace that neighbor with
  Xj

Summary Local optimization based on unicast
distances to choose mesh neighbors
12
Application-level Routing

• Variant of distance vector routing
• shortest path routing protocol
• routing table entries only for source proxies
• to detect loops, store entire path in routing
  table
• Build distribution trees from routing tables
• source-rooted trees
• reverse shortest path
• forward data using reverse path forwarding

Summary Shortest path routing to build
source-rooted trees
13
Scattercast Evaluation

• Simulate the Gossamer control protocol
• 1000 node topology, approx. 4000 edges
• Constructed using gt-itm topology generator
• Measure
• Average latency compared to multicast
• Cost Ratio (avg latency with Gossamer)
  (avg latency with multicast)
• Time to construct stable overlay
• Time for changes in overlay structure to stop
• Packet duplication overhead
• Number of physical Internet links with multiple
  copies of same packet

14
Variation of Cost Ratio with Session Size
Cost ratio remains low (lt 1.9) even as session
size increases
15
Time to Stability
Most mesh changes occur early on in the protocol
16
Packet Duplication Overhead
Most heavily loaded link for Gossamer 14 copies
Most heavily loaded link for unicast 99 copies
Load on physical links is lower for Gossamer than
for vanilla unicast
17
Contributions

• Overlay Architecture
• Lower-level constructs a routing mesh, shared
  across multicast sessions
• Mesh is a subset of complete virtual graph
• Mesh is constructed through gossiping
• Nodes continuously arrive and leave the mesh
• Use dynamic optimization to improve mesh
  efficiency
• Must correct for path failures, esp. partitions
• Each multicast session tree constructed above
  mesh

18
Contributions (continued)

• Evaluations of Overlay Approach
• Mostly simulation based
• Metrics
• Efficiency of chosen paths
• Cost ratio, Relative Delay Penalty(RDP), Link
  stress, Normalized Resource Usage
• Mesh convergence times
• Time for gossiping to stabilize

19
Advantages of Approach

• Localize hard multicast problems
• Bandwidth allocation, congestion control, loss
  recovery are tractable
• Simplify network layer via intelligent
  infrastructure
• No inter-domain multicast routing required
• Impose access restrictions within overlay proxies
• Leverage well-understood wide-area unicast
  protocols and naming schemes
• Incorporate app-specific semantics within proxies
  to address heterogeneity
• App-specific reliability and data scheduling
• On-the-fly content and bandwidth adaptation

20
Disadvantages

• Topology of Overlay trees only approximate
• Link stress number of times a packet crosses a
  given physical link
• For IP Multicast 1
• Overlay gt 1
• Overlays represent are a trade-off relative to
  pure unicast or native IP multicast
• Relative to IPM, overlays gain benefits in
  exchange for
• Lower overall bandwidth efficiency
• Higher end-to-end latency

21
Scattercast and Narada

• Topology discovery through learning/gossiping
• 2 levels multicast tree over unicast mesh
• Scattercast mech uses directed edges
• Simplifies mesh optimization (eliminates
  add/remove race).
• More robust against unplanned partition
• Narada emphasizes low-latency more
• Narada target application is video conferencing
• Scattercast chose shared whiteboard and internet
  radio broadcast
• Scattercast group seems to moving toward
  application specific enhancements

22
Overcast

• Overcast direct tree construction
• Doesnt share information across sessions
• Prone to partitions?
• Less scaleable?
• Emphasizes deployment
• Protocols do everything in the upstream direction
  to ensure compatibility with NAT and web proxies
• Everything done with http
• Overcast also emphasizes role of persistent
  storage
• Target application is efficient download of large
  production quality MPEG video files

23
Inktomi

• Mostly static approach
• Overlay topology decided based on operator policy
• Limited automatic adaptation when substrate
  topology changes
• Emphasizes explicit network management tools more
• Tools for the broadcast war room
• Vaporware?
• Where are the broadcasts?

24
Further Work and Improvements

• CMU SIGCOMM 01
• Use better metrics during mesh construction/optimi
  zation (bandwidth and latency)
• Evaluate on real internet
• Effects of Policy routing?
• Improve scalability?
• Would like all metrics to have sub-linear
  relationship to group size
• Still linear
• Time for mesh to converge
• Bandwidth and latency penalties
• Application specific processing
• Congestion control, content adaptation