Transcript Slide 1
The Three Ghosts of Multicast:
Past, Present, and Future
Kevin Almeroth ([email protected])
University of California—Santa Barbara
22-May 2007
TNC 2007
“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/
2
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
3
Multicast’s Failure… Quantitatively
Data by Marshall Eubanks, Multicast Technologies
http://multicasttech.com/status/
4
Multicast
never become
ubiquitously
deployed,
Multicast’s
failure awas
because…
revenue generating, native, one-to-many and many-tomany 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.
5
Multicast
never become
ubiquitously
deployed,
Multicast’s
failure awas
because…
revenue generating, native, one-to-many and many-tomany 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?
6
The Success of Multicast…
The real use of multicast is not widely visible
High speed research and education networks
Enterprises
Major companies using a wide variety of apps
Exchanges and securities trading companies
Other edge networks
Plus, some campuses distribute CableTV/IPTV using multicast
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”
7
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…
8
A Quick Aside…
Replace “multicast” with “IPv6” or “QoS”
(and maybe “ad hoc networks”)
(okay, not really)
9
Why the Perception Disconnect?
Multicast evolved with simultaneous research,
prototyping, deployment, testing, and use
A lack of discipline among academics
Too many changes in direction (e.g., ASM v. SSM)
At some point, too much deployed infrastructure and
too hard to make major changes
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
10
The Interconnected Community
Users
App developers (socket interface)
OS companies (socket/network interface)
Router vendors
Network administrators
Content providers
Researchers
11
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!
12
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
13
It was Doomed Soon After the Start
Original architecture was based on Deering PhD
dissertation which was for LAN-based multicast
The first step was a small one and it worked…
We never got away from many of those assumptions
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
14
What was Deployed did not Work
Routing problems persisted
Hard for users to even know if it was working
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
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?
15
16
The Routers’ View
17
The Challenge of Economics
Users
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
Don’t care how they get content, they just want it
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
18
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
19
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
20
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
21
Automatic Multicast Tunneling
Mcast Enabled ISP
Content Owner
Unicast-Only Network
Mcast Traffic
Ucast Stream
22
Mcast Enabled Local Provider
Greg Shepherd, Cisco
Automatic Multicast Tunneling
Creates an expanding
radius of incentive to
deploy multicast.
Mcast Enabled ISP
Content Owner
Unicast-Only Network
Mcast Traffic
Ucast Stream
23
Mcast Enabled Local Provider
Greg Shepherd, Cisco
The Original MBone was Tunnels
24
Wrapping Up: More Directions
Continued development
Continued deployment efforts
Clearly room for more monitoring/management/accounting
Mobility support (as if the problem wasn’t hard enough already!)
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
25