Network Architecture (R02) IP Multicast Deployment Woes

1
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/

2
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

3
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

4
Group State Management

• Implicit
• Traffic Driven
• Explicit
• IGMP Driven
• More Overheads!
• So not only state overhead is SG
• But also control overhead O(G) messages
• Aggregation probably doesnt do much
• Any Source v. Source Specific v. Single

5
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

6
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

7
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

8
The IEEE Network Problem Paper

• _at_ARTICLEDiot00deploymentissues, 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 gt 195 times! (to calibrate, gt10 cites is
  lt1 of papers)
• N,b. Sprint Advanced Tech Lab author co-lo with
  operations in Burlingame

9
The Sprint Viewpoint

• Sprint is a Tier-1 ISP
• Fastest US backbone at time
• Zero packet loss on their net
• In 2000, gt 8 years of WWW expo growth
• Since 1988, very little multicast growth
• So whats the problem with ipmc?

10
Sprint list of pbs

• Domain independence
• PIM DM v. SM
• RP for traffic
• RP for group management
• Address Allocation
• SD mechanism doesnt scale
• Group Management
• IGMP
• Multicast Security
• none (or ipsec or app)

11
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/nos
  sdav00.pdf
• Alternatives possible
• Single Sender (won for IPTV)
• Multipeer application layer service
• Re-unite, I3 etc

12
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 -(

13
So what now for multicast?

• Not in Sprint/IEEE Network paper but
• ATT and Telefonica world 13 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 dont
  need it really.
• see how digital broadcast TV works too
  application layer relays between BBC, Sky, etc