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