The Three Ghosts of Multicast:Past, Present, and Future

Kevin Almeroth (almeroth@cs.ucsb.edu)University of California—Santa Barbara

22-May 2007TNC 2007

2

“Multicast could be the poster child for the irrelevance of the networking research

community. Few other technologies (quality of service springs to mind) have generated so many research papers while yielding so

little real-world deployment.”Bruce Davies, public review of ACM Sigcomm 2006 accepted paper, “Revisiting IP Multicast” by S. Ratnasamy, A. Ermolinskiy, S. Shenker

http://www.sigcomm.org/sigcomm2006/discussion/

3

Multicast’s failure… quantitatively Methodology:

Look at MBGP (BGP4+) prefixes advertised (these prefixes are used by receivers to send join messages toward sources)

Assumption is that such an advertisement indicates support for multicast

Metrics: Percentage of address space Percentage of prefixes Percentage of ASes

4

Multicast’s Failure… Quantitatively

Data by Marshall Eubanks, Multicast Technologieshttp://multicasttech.com/status/

5

Multicast’s failure was because…Multicast never become a ubiquitously deployed, revenue generating, native, one-to-many and many-to-

many service capable of securely and robustly supporting:

(1) all manner of streaming media (TCP-friendly adaptation), (2) reliable, TCP-friendly file transfer, and (3) audio/video conferencing (with minimum jitter and delay)

all with only minimal additional router complexity, deployment effort, management needs, or cost.

6

Multicast’s failure was because…Multicast never become a ubiquitously deployed, revenue generating, native, one-to-many and many-to-

many service capable of securely and robustly supporting:

(1) all manner of streaming media (TCP-friendly adaptation), (2) reliable, TCP-friendly file transfer, and (3) audio/video conferencing (with minimum jitter and delay)

all with only minimal additional router complexity, deployment effort, management needs, or cost.

So, is multicast really a failure?

7

The Success of Multicast… The real use of multicast is not widely visible

High speed research and education networks Plus, some campuses distribute CableTV/IPTV using multicast

Enterprises Major companies using a wide variety of apps Exchanges and securities trading companies

Other edge networks Often called “walled gardens” Examples: DSL and Cable TV (triple/quad play)

Military networks One statistic: “60% of our traffic is going to be multicast”

8

In Fact…

Multicast, as an academic-style research area, has been one of the more successful recent research areas

Original idea was generated in academia

Academic-based research has led to the standardization and deployment of protocols, industry/academia collaboration, start-ups, new technology, products, revenue, jobs, etc.

And these efforts continue…

9

A Quick Aside…

Replace “multicast” with “IPv6” or “QoS”

(and maybe “ad hoc networks”)(okay, not really)

10

Why the Perception Disconnect? Multicast evolved with simultaneous research,

prototyping, deployment, testing, and use Too many changes in direction (e.g., ASM v. SSM) At some point, too much deployed infrastructure and

too hard to make major changes

A lack of discipline among academics Too many irrelevant papers and projects

A lack of foresight about the scope of the problem, the groups involved, and group interaction A lack of the right expectations

11

The Interconnected Community

Users App developers (socket interface) OS companies (socket/network interface) Router vendors Network administrators Content providers Researchers

12

The Interconnected Community

Users App developers (socket interface) OS companies (socket/network interface) Router vendors Network administrators Content providers Researchers

Becomes one big chicken farm and omelet problem!

13

Two of the Biggest Early Problems Service just didn’t work

Remember, multicast started before there was a significant web presence and really even before inter-domain routing

Little consideration for large-scale deployments Especially the economies of deployment Especially monitoring/management/accounting

14

It was Doomed Soon After the Start Original architecture was based on Deering PhD

dissertation which was for LAN-based multicast We never got away from many of those assumptions

The first step was a small one and it worked… No scalability (broadcast and prune…), minimal

requirements, but it worked!

…but the second step was too big Would only accept (nearly-)infinite scalability “Small group multicast” was dismissed out-of-hand

15

What was Deployed did not Work Routing problems persisted

Trying to join dense with sparse Mis-configuration (that’s what the vendors said) Poor interface (that’s what the users said) Proper deployment was arcane and hard to debug Academics didn’t understand the problem

Hard for users to even know if it was working Try-it-and-see mentality… …and if it wasn’t working, it was nearly impossible to debug

Two experiments What do users see? What do the backbone routers see?

16

17

The Routers’ View

18

The Challenge of Economics Users

Don’t care how they get content, they just want it ISPs

Never figured out how to charge: UUNet (UUcast) tried, but the billing model wasn’t consistent with what multicast did

Odd “sweet spot” on the economics curve Sold as a “reduction in traffic”, but wasn’t

Content providers L-O-V-E multicast because they pay less…

Application developers Good AAA requires implementing some non-scalable features,

for example, tracking membership The lesson of Starbust

19

A Litany of Other Problems Inter-domain and source discovery

SSM fixes the problem, but too little too late

Reliability and congestion control

Firewall support

Authentication/Authorization/Accounting (AAA)

State scalability and router CPU processing

Security Data security and protocol operation security

Monitoring/Troubleshooting/Management

20

Current Adjustments IRTF SAM Research Group has a good mission

Continue work towards a hybrid solution Solutions must be incrementally deployable For example: Automatic Multicast Tunneling (AMT) Even Application Layer Multicast (ALM) is okay

Convince academic community to re-accept multicast They still are in many cases (even Sigcomm did), but what they

consider interesting are monolithic solutions Need a place that accepts good, deployable solutions Interest by the funding agencies would also help

21

Automatic Multicast Tunneling Allows multicast content to reach unicast-only receivers

The benefits of multicast wherever multicast is deployed Hybrid solution Multicast networks get the benefit of multicast but unicast users

still get the benefit of the content

Works seamlessly with existing applications Requires only client-side shim (somewhere on client) and router

support in some places

22

Automatic Multicast TunnelingMcast Enabled ISP

Unicast-Only Network

Content Owner

Mcast Enabled Local Provider

Mcast Traffic

Ucast Stream

Greg Shepherd, Cisco

23

Automatic Multicast TunnelingMcast Enabled ISP

Unicast-Only Network

Content Owner

Mcast Enabled Local Provider

Creates an expanding radius of incentive to deploy multicast.

Greg Shepherd, Cisco

Mcast Traffic

Ucast Stream

24

The Original MBone was Tunnels

25

Wrapping Up: More Directions Continued development

Clearly room for more monitoring/management/accounting Mobility support (as if the problem wasn’t hard enough already!)

Continued deployment efforts Plus requires more apps and more content (as always)

Continued engineering work Not necessarily by the academics but by the high-speed network

operators/engineers Keep multicast a de facto part of IPv6