Multicast Traffic on Backbones

John Olp john.olp at olpinc.net
Fri Jun 15 16:41:53 UTC 2001


> The originator is being
> charged for the originating network's costs of getting his traffic off the
> originating network towards the recipient. The recipient is
> charged for the
> recipient network's costs of getting his traffic from the originating
> network and to the recipient.

We're saying the same thing.  If, as you say above, the recipient is charged
for his/her end of the connection, then the originating customer should not
have to pay all of those costs again.

>
> 	In the simplest case, where your ISP and my ISP meet
> directly at a peering
> point and you send me a packets, the costs go like this:
>
> 	You pay for your line and your ISP's costs of keeping that line
> operational. You pay the cost of getting traffic from your line
> to wherever
> the router is that peers with my ISP. You pay part of your ISP's costs in
> maintaining that peering link.

Exactly!  But multicast isn't (or shouldn't be) used for simple cases.

> 	I pay for my line and my ISP's costs of keeping that line
> operational. I
> pay for some of my ISP's costs in keeping that link to you operational.

You're paying this with a unicast connection anyway.  Why multiply the cost
by number of recipients and charge to originator instead of divide the cost
across all participants.

> 	But it does cost you more. You are ignoring the example of
> mine wherein it
> clearly costs you more.

There's a difference between "costing more" and "costing you more" --
roughly a point I am trying to make.  If you scale anywhere beyond your
simple 2 peer conversation for qualifying applications, multicast will
consume less resources than will unicast.

> 	You now have two self-contradictory arguments. One argument
> is that people
> are profiteering from multicast. The other is that they make more
> money with
> unicast. You can't have it both ways.

It would seem I said this.  True, both unicast and multicast offer profit
potential.  I meant to say that, given the pricing model where the
originator is expected to pay for each recipient, some users with
applications which could benefit from multicast will opt for the more
affordable, lower performance unicast.

In uses such as teleconferencing where originators and recipients both
become participants, this cost barrier is even more prevalent when each
participant would otherwise be charged for each other participant's
connection.  Few are willing to line the ISP's pockets with this exponential
profit.

I also meant to heighten awareness that this model has room for
optimization.

> If ISPs can get rich off of
> multicast,
> then they will promote it. Eventually, competition for multicast
> will bring
> the prices more in line with the actual cost to provide the service.

Agreed.

> 	While I agree that multicast is caught in a catch-22, it's
> not the one you
> think, it has nothing to do with cost.

Nothing? Well, it seems you can't have it both ways either (grin).  You are
arguing cost is a factor in supporting multicast and are also arguing cost
is not a factor. (Don't reply. I get your point well enough).

> It just has to do with the  fact that
> nobody wants multicast until enough other people have it. There are a few
> ways out of this (killer app, gradually increasing penetration,
> early-adopter incentives, and so on) but none of them have much to do with
> pricing.

There are certainly other obstacles.  But, IMHO, cost - TO THE USER, BASED
ON THE PRICING MODEL - is still a factor in wider acceptance of multicast.
Because of the profit potential, I don't see the model changing any time
soon.  Thus I believe it will be some time (if ever) before qualified apps
become killer apps.  I also believe that if transit or peering contracts are
renegotiated to provide incentives for multicast, the technology will take
off and everyone will benefit.

-John




More information about the NANOG mailing list