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
