Disclaimer: I think I know what I'm talking about, caveat emptor. 
The problem is, everyone thinks that million lemmings can't be wrong.
I am not foolish enough to argue with a million lemmings. One need only
convince the one in front to change direction.
Multicasting cannot be made scalable. It is as simple as that.
One can play with multicast routing protocols as much as one
wishes - in pilots and small networks. It only takes a question -
"ok, how are we going to handle 100000 multicast channels?" to
realize that L3 multicasting is not going anywhere as a real-world
production service.
That a more scalable solution has not yet been developed is not evidence
that one does not exist. Classful routing and address assignement wasn't
scalable, either, but we have (hopefully) come out of that era with some
cleverness and reliance on good design. You ask "ok, how are we going to
handle 100000 multicast channels?" rhetorically, assuming that there is
no answer to the query. Multicast is, in all reality, in its infancy. There
really aren't enough people using it to make scalability an urgent issue.
In order for cool ideas like internet broadcast television and radio
services work, the internet will require multicasting or ma-bell is going
to have to create cheap bandwidth of gargantuan proportions. I'm not holding
my breath for the telephone companies to do anything earth-shattering in the
next decade. <cliche>Necessity is the mother of invention.</cliche>
Nah. It is a clear and present case of not thinking hard enough.
Indeed, and you're willing to dismiss multicast without second thought?
> 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).
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.
> Multicasting is faster than disk.
This is a rather strange statement. I worked on a product (which was
shipped) which delivered something like 20Gb/s of streaming video content
from disk drives. RAID can be very fast 
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
you feed out simultaneously from your box? Say 100 people had the ability
to view data streams running at that speed. Now, consider that they all have
22Gb/s connections to your network. With multicast, you can feed all of them
simultaneously from a single 22Gb/s connection to your box of streaming
data. This would require 2.2Tb/s if done on unicast from your box. And it
would still require the same 22Gb/s incoming stream. Please explain to me
how the cache saves bandwidth in this case.
> I'm not sure how caching
> is the solution. Distributed content is also good.
Ah, distributed content Yet another kludge requiring lots of maintenance
and "special" relatioships between content providers and ISPs.
As time passes, I can assure you that the line between the two will blur,
whether because of multicast, caching, or greed is yet to be seen.
Some suggested goals for multicast design*:
. Ensure that data are replicated as close to the destination as possible.
. Ensure that multicast routers not carry more topology data than are
absolutely necessary.
. 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.