Transcript Research is communication

Network Architecture (R02)
IP Multicast Deployment Woes
Jon Crowcroft,
http://www.cl.cam.ac.uk/~jac22
http://www.cl.cam.ac.uk/teaching/1213/R02/
IP Multicast

Could be useful traffic reduction tool





Load reduction for transmitter of N
Load reduction in ISP of ln(N)
Scale out Live IP TV/Radio
Possibly useful for s/w distribution
Natural API/Model for Groupware


N-way video/whiteboard/CSCW
Very easy to understand “just join”
Multicast - Classic


Make the Internet one big Ethernet
Steve Deering (w/ Dave Cheriton) 1988





New address (“Class D”) = Host Group, G
Forwarding Scheme = away from S
Prune/Graft per interface “towards” G
Need (S,G) state, Per Router…
State Management…
Group State Management

Implicit


Explicit


IGMP Driven
More Overheads!




Traffic Driven
So not only state overhead is S*G
But also control overhead O(G) messages
Aggregation probably doesn’t do much
Any Source v. Source Specific v. Single
Single Source


Can use reverse path fwd only
Can auth/check source



(exactly same as Best Practice RPF check)
Not much use for many-to-many apps?
N.b. looking at main early use of
multicast (“mbone”) 

was many-to-many video conf
main use now? IPTV, Radio, S/W
Reliable Multicast

Seems to be no “one size fits all”



Interesting e.g. of new style WG in standards



Nack, Ack Aggr & Code based schemes
Need various ordering semantics (if n-m)
Did “building blocks”
Then composed RM protocols from these
One v. interesting idea - GRA


minimal router processing engine needed for e2e
protocol support
Precursor of other middle box ideas…
RM - Congestion Control & Failures

Two things hard to define



How should multicast flow “compete” with
TCP?
What are the “late join”, “early leave” and
“fail” semantics for some members?
Again, no “one size fits all” answer…
The IEEE Network Problem Paper
@ARTICLE{Diot00deploymentissues,
author = {Christophe Diot and Brian Neil and Levine Bryan and Kassem Doug
Balensiefen},
title = {Deployment issues for the IP multicast service and architecture},
journal = {IEEE Network},
year = {2000},
volume = {14},
pages = {78--88}
abstract = {IP multicast offers scalable point-to-multipoint delivery necessary
for using group communication applications on the Internet. However, the IP
multicast service has seen slow commercial deployment by ISPs and carriers. The
original service model was designed without a clear understanding of commercial
requirements or a robust implementation strategy. The very limited number of
applications and the complexity of the architectural design — which we believe is
a consequence of the open service model — have deterred widespread
deployment as well. We examine the issues that have limited the commercial
deployment of IP-multicast from the viewpoint of carriers. We analyze where
the model fails, what it does not offer, and we discuss requirements for
successful deployment of multicast services. }
}
Cited > 195 times! (to calibrate, >10 cites is <1% of papers)
N,b. Sprint Advanced Tech Lab author co-lo with operations in Burlingame
The Sprint Viewpoint






Sprint is a Tier-1 ISP
Fastest US backbone at time
Zero packet loss on their net
In 2000, > 8 years of WWW expo
growth
Since 1988, very little multicast growth
So what’s the problem with ipmc?
Sprint list of pbs

Domain independence




Address Allocation –


SD mechanism doesn’t scale
Group Management –


PIM DM v. SM
RP for traffic
RP for group management
IGMP
Multicast Security –

none (or ipsec or app)
Sprint

Non-technical aspects



Network Management
Billing for multicast
Cost/Benefit at all?





Eg. Router migration pain
Training ops in new mess
Debugging overheads
Smart people tried and only very partly succeeded in solving these
problems – see
On Scalable Internet Multimedia Conferencing Systems
http://www0.cs.ucl.ac.uk/staff/m.handley/papers/
Protocol independent multicast pricing
http://www.cs.st-andrews.ac.uk/~tristan/pubs/nossdav00.pdf
Alternatives possible



Single Sender (won for IPTV)
Multipeer application layer service
Re-unite, I^3 etc
The “Truth” about Multicast

In fact, in a conference in 2006

Berkeley Sys Admins reported that





Turning on IP multicast broke Unicast!
Basically terrible code
Also reported multicast self-inflicted RP worm…
Classic deployment dilemma
Specially Bad Case




Multicast has to be in “fast path”
Multicast routing depends closely on Unicast (viz
PIM)
It also depended on monitoring data to drive
routing update
So new control plane interface to fast path :-(
So what now for multicast?

Not in Sprint/IEEE Network paper but



AT&T and Telefonica world #1&#3 ISP use
single soruce multicast for IPTV
For data centers and link-local, heavily used
Given up on interdomain


but flattening of Internet Topology means
don’t need it really.
& see how digital broadcast TV works too
application layer relays between BBC, Sky,
etc