RA/RV Feeds from RBN

Tue Feb 17 00:22:45 UTC 1998

Sean M. Doran wrote:

> The real problem is that IPv4 Multicast scales badly with
> the number of groups, and Multicast routing is difficult.
> If you doubt any of this, kindly review the recent Dave
> Meyer presentations at any of your favourite conferences.

The _real_ problem is that the very concept of IP multicasting
 is brain-dead.  A multicast-based production service is neither
 implementable, nor needed.  Here are my reasons for concluding
 so:

 1) Multicast routing is not scalable and _cannot be_ scalable.
 There are three distinct ways to do IP-level multicasting:

 a) the most broken one: flooding multicast routing information
     all over the network.  Equivalent to host routing to source hosts.

 b) on-demand spanning tree, like that used in EXPRESS multicasting
     as developed by David Cheriton's students.  That requires every
     gateway carrying multicast packets to keep track of all transit mc
     channels.  Equivalent complexity-wise to virtual circuit-based networking.

 c) sparse spanning tree, with state kept only in replicating gatways,
     like that described in a TRAP draft.  This has the best scaling properties,
    but replicating is very likely to occur at exchange points for the majority
    of channels - i.e. the exchange-point gateways will still have to keep
    the significant amounts of per-flow state.

  Any multicasting sheme makes routing dependent on user-supplied
  routing information.  This is a major operational nightmare.  Just imagine
  what happens if some bozo starts injecting streams of Join-s and Leave-s.

 This all means that multicasting is ok only as a nice toy.  When you try to
  make it available to "masses" you end up with serious routing problem.

 2) IP multicasting represents a major security problem since anyone can
  produce major avalanches of bogons by sending them down the existing
  multicast trees.

 3) Not all links are created similar.  A multicast stream suitable for a T-1 does
 not fit into 28.8 modem connection.  It means that multiple different-rate streams
 have to be transmitted simultaneously to accomodate different conditions.

 4) There is no good way to make IP-level multicasting congestion control-friendly.
  Any provider brave enough to let multicasting into his backbone w/o strict rate
  controls is asking for a serious trouble.

 So much for technical feasibility of multicasting in the real-life backbones.  Now,
 do we really need it?

 1) There already are ubiquotus, cheap, high-bandwidth and technically feasible
  multicasting delivery systems - also known as "boob tube", "idiot's box" and,
  sometimes, "television".

  The experience with TV illustrates that there's no shortage of transport capacity
  to large audiences; there's a shortage of quality content.   Due to the technical
  problems, it is highly unlikely that multicasing can be used for large numbers
  of  small audiences (aka "oligocasting").

 2) IP muticasting offers no significantly new services which could be attractive to
  consumers.  The receiption is still simultaneous and extracting parts of it require
  waiting until unwanted content is skipped.

  Are there any alternatives to multicasting?  Yes, of course.  The same service
  can be provided by application-level caches run by backbone ISPs.  Unlike
   multicasting, cacheing allows non-simultaneus usage of the material (i.e. you
   can imagine treating a newscast as a VCR tape - for example back up to view
   the segment once again, etc).  This makes "Internet TV" a completely different
   medium from the multicasting TV - for example, it would kill "soundbite TV" of
   CNN style, in favour of a more detailed in-depth stories, w/o sacrificing breadth
   or immediacy of coverage.  Just compare CNN.COM and CNN on TV - their Web
   site is a lot more informative.

   Cacheing does not break congestion control and routing in backbones.  It allows
   network operators to have finer-grained control of their traffic.  In the most trivial
   case, cacheing with zero-time expiration time is equivalent to multicasting in terms
   of traffic savings.  On the other hand, intelligent usage of cache preloads during
   night hours would allow to reduce high-bandwidth canned-content traffic significantly
   during the peak hours.

   In other words - why anyone would ever need IP multicasting?  I strongly suspect that
   the whole IP multicasting hoopla is going the same way as ATM - stupid idea propped
   by enourmous expenditure of research and development resources, ultimately discarded
   in favour of more conservative and demonstrably working technology.

--vadim