Multicast Traffic on Backbones

John Olp john.olp at olpinc.net
Fri Jun 15 07:49:21 UTC 2001


> 	Let's take an example. I'm a small provider. I have an OC3
> to FooNet and an
> OC3 to BarNet and I get full transit on both. I sell a DS3 to someone.

> 	Now you can argue that I should just eat this cost.

Not quite my argument, but yes, I can argue this (see below).

> 	In any event, it has always been my position that where
> possible and within
> reason, ISPs will be most competitive (and the Internet will
> remain the most
> stable) if they can develop and implement pricing models that charge their
> customers based upon the actual cost to provide the customer with the
> service.

Precisely the thoughts I intended to provoke.

Assuming the group members are other customers of foo and/or bar, then foo
and/or bar are charging both you and those customers (essentially charging
you for something already paid for).  Even if foo/bar is just routing to
some other network and just passing on their overcharge to you, the argument
stands that someone is charging twice for the same traffic.

While it might be true that you have a cost based on your transit/peering
agreements (i.e. the pricing model), the argument stands that multicast
doesn't cost more.  The truth is, it costs less.  You're just being charged
more because you accept it.  And to recoup your cost, you consider passing
it on to your customer (who with this model concludes multicast isn't cost
effective).

I haven't begun to conceive a model that works to everyone's satisfaction,
but it's plainly obvious the existing model doesn't work in favor of
multicasting.  You can bet that whoever is pocketing the overcharges is not
going to stop on their own accord.  But until we come up with the right
model, the profit potential of unicast is going to remain an obstacle to the
general acceptance of multicast.

-John




More information about the NANOG mailing list