network architecture (r02) ip multicast deployment woes jon crowcroft, jac22
TRANSCRIPT
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 Traffic Driven
Explicit IGMP Driven
More Overheads! 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” Nack, Ack Aggr & Code based schemes Need various ordering semantics (if n-m)
Interesting e.g. of new style WG in standards 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 PIM DM v. SM RP for traffic RP for group management
Address Allocation – SD mechanism doesn’t scale
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 – seeOn 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 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