Brad Hunting writes:
| It even uses fewer resources for network providers.
|
| "The real difficulty of multicast" is that it's much more difficult
| for ISP's (and presumably router venders) to support than unicast.
These two statements are, unfortunately, mutually exclusive.
IP multicast does not scale well for S,G state; it may scale OK
for *,G for reasonable numbers of groups; it is not known whether
it will scale at all for little things like customer support.
Several backbones (including Ebone) offer native multicast "for free";
all a customer has to do is configure things up:
for source-active/rendezvous: use our (anycast) RP, talk MSDP to us
for RPF: use mBGP
for joins/prunes: use PIM in sparse mode
It's not so difficult to set up, but not many people actually do it.
A sister network which has a pretty similar overall architecture to ours
offers multicast "for free" with a transmissions cap of a few hundred kbps
or so from a customer to the rest of the world through that network.
I don't think that this threshold has ever been in the way of anyone so far...
Why? Poor client support springs to mind. I've always wanted to
have someone throw together a web page that downloads a Java applet
equivalent to vic/vat/rat/etc., joins the right group, and puts content
into the face of the clicker, perhaps for a fee. However, in the absence
of compelling content (sadly we don't have Vint to strip for us :) ), I
haven't suggested that this be a priority.
Also, not all routers at/near the edge can even do native multicast...
Sean.
P.S.: A long time ago there was a very interesting discussion (probably
on NANOG) involving Vadim Antonov and many others; the argument
advanced by Vadim's side (include me here) is, roughly, that if you consider
multicast to be a degenerate form of caching, where the cache is purged
immediately after servicing the implicit cache requests made by the
listeners who have joined below the current router, then native multicast,
particularly reliable native multicast, is being approached in fundamentally
the wrong fashion. In other words, rolling (maybe short term) content
caching into (some) routers is likely to be a more useful generalized
service than deploying actual native multicast, all while being able
to reuse some join/prune, SA and RPF state handling to optimize the
"network-based Content Distribution Network" (to use a set of buzzwords).