RA/RV Feeds from RBN

Mon Feb 16 00:11:36 UTC 1998

brandon at rd.bbc.co.uk (BrandonButterworth) writes:

> If MBONE is to be a serious contender the ISPs must
> deliver it, then us content providers that are wasting
> tons of net bandwith could become nicer netizens and
> wouldn't use the unicast products that end users are
> asking for. Of course the ISPs may not take as much
> money off us as we wouldn't need quite so much bandwidth
> (perhaps there's a reason there?)

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.

Content multicast is *wonderful* news for any ISP that
overbooks its backbone capacity: the amount of overbooking
possible increases with the volume of highly-popular
scheduled content.

That is, if you have lots of replication happening in
multicast routers (presumably because your customers have
things attached to them who want the same content at the
same time), then you can fill your customer links with
stuff that has less impact on your relatively large
backbone pipes.

InternetMCI is among a number of ISPs who have worked on
eliminating redundant copies of multicast traffic crossing
their backbones by deploying MBONE infrastructure.  This
is not the same as deploying a multicast infrastructure,
however that is a very different rant.

So, frankly, your suggestion that ISPs make less money off
you when there is lots of well-laid-out distribution trees
carrying lots of content to lots of places is simply
wrong.

The problem is mostly that people are busy making unicast
mostly work and are finding that sufficiently difficult
that making multicast work better than it does now just
does not get attention, particularly since multicast
routing is hard and multicast routing code is buggy at
least in part due to that.  The lack of perceived utility
for multicast also has an effect on the other side of a
cost-benefit analysis that does not favour rapid
deployment.

	Sean.