Multicast Traffic on Backbones

Sun Jun 10 13:43:50 UTC 2001

On Sun, 10 Jun 2001, Eric Gauthier wrote:

> > 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...
>
> I'm relatively new to multicasting, but my impression is that if you have a
> 128K stream that you are sending out then, even if you are sending it towards
> hundreds or thousands of places, no individual link would have more than
> 128K on it (thus the point of multicasting).  There may be hundreds of
> different links each with an additional 128K, but the N-factor amplification
> you are referencing would be more from the "we now have to send this same
> 128K out 20 different peering links and possibly (depending on your peering
> policy) pay 20 times the bandwidth cost" but it shouldn't cause any
> individual link to become overloaded.

	In the original message keep reading. I stated the same thing. The
concept is not just to a peering location, but say you have hundreds to
thousands of receivers, each link is getting (in my example 384K) then you have
N number of links each getting 384K. If you have a backbone with say 500 major
links and there is a receiver off each wanting this traffic, then the backbone
provider is duplicating your traffic 500 times, delivering it to 500 locations,
but being paid for one 384K flow.

	Another manner to look at this is that in tradiational uni-cast there
is a hop on and a hop off that is a 1 to 1 relationship. In multicast there is
a 1 to N relationship and the provider is still being compensated on a 1 to 1
basis. The coutner to this is that each party is paying a hop on and hop off so
why should the provider be compensated more as each end party is paying for
their connection. The myth to the latter argument is that you are not truely
paying for the cost of delivering the packets from A to Z, the providers count
on the ability to aggregate traffic and knowing that at any given moment that
their tail links are not consumed. It is risk management, traffic engineering,
whatever you want to call it, but it ammounts to knowing that there is not a
full 1 to 1 relationship. Multicast if it ever becomes widely deployed will
shoot the theory and pricing model and one of two things will happen in my
opinion: Cost for multicast traffic will skyrocket as providers of content
reduce their demands for bandwidth (take 1000 streams of 384 and I can get it
on a T1 vs multiple OC-3), or cost for all connections will increase.