Worse yet, it distracts from deployment of the real solution - cacheing.
One needs pay close attention to the problem trying to be solved. I see it as being 2 cases:
1. Broadcast "live" or "real-time" data. This is what multicast is (should be) really good at. Videoconferences with friendly geeks via some caching mechanism would be awful at best, and still require more than one feed from the source, or from some replication server (a la CUSeeMe). In case of DENSE network, yes, in case of (sorry, forget right word) RARE network, (SPARE?), it's almost the same. How much peopel over the world use CUSeeeMe even withouth the packet replicators? And how much use MBONE? Now compare...
2. "On-demand" data, such as your friendly neighborhood internet-movie rental center. Don't laugh, I expect to see it in my lifetime. These could be cached "close to home", assuming that there weren't some legal issues with intercepting and storing data someone else paid for. Caching is only good for asynchronous data likely to be requested numerous times from various sources. i.e. I want to watch the same movie my neighbor is, but I want to see it from the start, not pick up in the middle where he is. Just again - the CACHING and the MULTICASTING is two edges of the ONE PROCESS - name it _CACHE AND REPLICATE THE DATA_. Why to build two independent systems (caching and multicasting) instead of building one common (CACHE-REPLICATE servers, with the _on the fly_ mechanism like CISCO WWW-CPP protocol work), and with multicast on the far ends of the data tree?
And again - MCAST is not scalable, IP address (classical or CIDR) is.
In case 1 above, as I stated, cache would not work well for several people in disparate locations trying to videoconference. How many 20Gb/s streams can Where do you see 20Gb/s? I see the contents over the Internet with 16Kbit's, or (worst case) 80Kbit/s data streams. For the conference (when it's not high quality movie watching) 80Kbit streams are more then necessary.
100 * 80 = 8,000Kbit = 8Mbit. Image 2 - 3 level data replication - it should be 200 - 300Kbit. Image MCAST on the far end, in the LAN's - no bandwidth problems at all. No one ask to use data replication for the WEB TV in your local provider offer you it as the new TV system. But it's not INTERNET.
Some suggested goals for multicast design*:
. Ensure that data are replicated as close to the destination as possible. Yep. It cause this to be useless for the ON-DEMAND data, and when there is non-multicast networks between the data sor=urces and data listeners (i.e. at 99% cases).
. Ensure that multicast routers not carry more topology data than are absolutely necessary. And this cause the routers to know EVERY DATA STREAM you have in your media... And so on...
Please, understand - MCAST is not bad idea. MCAST has it's own fields. But it should not became GLOBAL MULTIMEDIA TRANSPORT for the global INTERNET.
. Ensure that the multicast system does not lend itself to DoS abuse, as other methods of one-to-many data replication do.
* I am a multicast newbie, and largely illiterate in current implementation, so don't laugh at my suggestions publicly, please. :-)
-- Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer
Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)