Developing a Multicast Metric

1
Developing a Multicast Metric

• Robert C. Chalmers and Kevin C. Almeroth
• UC Santa Barbara, Computer Science
• robertc,almeroth_at_cs.ucsb.edu
• http//www.nmsl.cs.ucsb.edu/mwalk

2
Introduction

• Why is it important to understand multicast
  performance ?
• How can we begin to quantify multicast
  efficiency ?
• How can we measure efficiency for live multicast
  groups ?
• Is there some way to predict multicast
  performance ?

3
Why Multicast

• necessary for large broadcasts
• point to multi-point
• thousands of receivers
• useful in LAN and SAN environments for
  distributed applications
• multi-point to multi-point
• cluster-based computing
• how about for wide-area applications without
  huge audiences ?
• useful efficient

4
Multicast Efficiency

• source issues a single packet
• irrespective of the number of receivers
• reduced impact on local bandwidth and server
  resources
• network replicates packets only when paths to
  receivers diverge
• each link carries a single copy of the packet
• efficiency gain for a link is proportional to
  the number of downstream receivers

5
Why Is Multicast Not Deployed

• requires additional state in the network
• breaks end-to-end argument
• requires additional management
• debugging and monitoring tools are still
  evolving
• pricing models are under debate
• charge service provider more to compensate for
  less bandwidth used
• charge receivers directly, but decrease the
  price as more users join

6
Interested Parties

• end-users
• overall efficiency is not a concern
• care about quality and cost
• service providers
• concerned about local resources
• largest concentration of traffic
• network providers
• must consider needs of service providers
• optimal use of available bandwidth
• offsetting the cost to implement and manage

7
How To Justify Multicast

• sweetspot - where the bandwidth cost of using
  ucast outweighs the increased overhead of
  implementing mcast (Diot-00)
• how do we quantify mcast efficiency in terms of
  the cost of ucast ?
• monetary savings would be most useful
• we focus on bandwidth utilization
• can be converted into dollars with knowledge of
  link costs

8
A Simple Metric

• ? 1 - Lm / Lu
• Lm - number of links in mcast distribution tree
• Lu - sum of all ucast hops
• as ? approaches 0, Lm ? Lu
• little to no bandwidth savings
• as ? approaches 1, all receivers share a path
• maximum possible bandwidth efficiency

9
Other Calculations

• total flow bandwidth
• ?u (ucast hops)(data rate)
• ?m ?u(1 - ?)
• average flow per hop
• ?u ?u / (distinct hops) ?u / (mcast hops)
• ?m (data rate)
• maximum flow per hop
• ?u (ucast streams)(data rate)
• ?m ?m (data rate)

10
Measurement

• hard to measure Lm and Lu accurately for real
  mcast groups
• using Mhealth we can count the links directly
• collects RTCP packets to determine sources and
  receivers
• uses mtrace to construct distribution tree

11
(No Transcript)
12
Problems With Approach

• ucast path ? mcast path
• less of a problem as mcast is natively deployed
• policy routing may actually increase disparity

unicast vs. multicast path length
13
Problems With Approach

• presence of mcast tunnels
• shorten the perceived mcast path length
• each mcast hop contains numerous ucast hops
• multi-access hops
• mcast is extremely efficient
• ignoring the presence of these hops will give a
  pessimistic view of multicast efficiency
• satellite links are particularly applicable
• dialup links actually degrade mcast to ucast on
  the last hop

14
Problems With Approach

• accurate membership and tracing
• membership depends upon RTCP
• not all receivers implement RTCP
• RTCP uses UDP and is inherently unreliable
• some firewalls block RTCP traffic
• traces are performed sequentially
• may miss some receivers that join for a small
  period
• many routers do not have mtrace support active
• the result is a partial snapshot of the mcast
  tree
• may not represent any actual distribution tree
• does capture the trend of the group over time

15
Predictive Metrics

• provide an estimate prior to implementation
• provide a baseline for evaluation

16
Key Factors

• height
• as a tree grows taller and receivers attach near
  the bottom, the number of shared links increases
• breadth
• branching near the source means early packet
  replication while branching nearer the receivers
  indicate a long series of heavily shared links
• number of receivers
• as the number increases, the likelihood that new
  receivers will share a portion of the existing
  tree also increases

17
Focus On Number Of Receivers

• expand on work to price mcast (Chuang-98)
• Lm / Lu Nk
• Lm - number of links in mcast distribution tree
• Lu - average ucast path length between any two
  nodes
• N - number of receivers
• k - economies of scale factor ? 0.8

18
An Efficiency Estimate

• Lm / Lu Nk
• assuming Lu Lu / N
• ? 1 - N?
• where ? k - 1 ? 0.8 - 1 -0.2

19
An Efficiency Estimate
20
Experimentation

• estimate seems unintuitive
• shouldnt the shape of the tree have an impact
• does extrapolation from pricing formula hold
• performed a number of experiments using real and
  synthesized group distributions
• introduced a new tool mwalk which parses MHealth
  logs to create a global view of the session
• results to appear in Infocom 2001

21
Experimentation
real group distribution
synthesized group distribution
22
Conclusions

• quantifying mcast efficiency is important
• to help in deployment efforts
• to provide a decision point for service
  providers
• predictive metrics are extremely useful
• measuring mcast properties is difficult and
  time-consuming
• accurate models require constraint parameters
• this work provides a starting point for more
  advanced metrics