Multicast Traffic on Backbones

Michael Whisenant mwhisen at foreigner.whisenant.net
Sun Jun 10 13:05:24 UTC 2001


On Sun, 10 Jun 2001, Tim Winders wrote:
>
> However, with unicast, if you have a 10MB connection, you can't send more
> than 10MB with unicast.  If you need more bandwidth, you buy more.
>
> My argument back, was that it is highly unlikely that I will have 100
> different receivers which will have 100 different paths across their
> network.  If their network is designed properly, there should be less
> impact on their network with multicast than with unicast.  I hope they buy
> that.  :-)

	Now you get to a Randy Bush argument of what are you actually paying me
for (Sorry Randy, but I like your comment so I decided to apply it here) from
the provider. If the provider is assumming all the risk for your flow should
they not be compensated for the flow? If you are going to have N times
receivers of your stream, should they then not have the ability to charge you
some factor greater than 1 to support the flow? One method is to limit the
amount of bandwidth of multicast per edge interface, but if a 128K stream is
sent to hundreds or thousands of places then it could impact certain links as
well. Maybe not the backbone running at OC-x speeds...

	The impact to their backbone is calculated on a fixed connection speed.
There have been enough studies that proper traffic engineering can be
accomplished with Y number of connections at X data rate. The larger number Y
is the actually closer that they can better construct their models. Then with
actual trending they can forcast and the situation continues.... Then comes
multicasting... If I started streaming a popular live event (since so much
attemtion with multicast is for multimedia anyway) at say 384K and tens of
thousands of people subscribe there will be N number of nodes that will be
getting the stream once, but the overall impact to the network on any given
link is 384K, but the overall impact would be N times of 384K. That could
amount to a total aggregate of say 10times that you are paying or higher. I
would think that a charge based on number of receivers at a reduced rate over
unicast would be in order.

> > > an option with customers.  There isn't a demand, so the providers don't
> > > put the resources into it...

	That is the way our economy works...




More information about the NANOG mailing list