nanog mailing list archives
RE: Multicast Traffic on Backbones
From: "John Olp" <john.olp () olpinc net>
Date: Fri, 15 Jun 2001 09:41:53 -0700
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
Current thread:
- Re: Multicast Traffic on Backbones, (continued)
- Re: Multicast Traffic on Backbones Joel Jaeggli (Jun 09)
- Re: Multicast Traffic on Backbones Jared Mauch (Jun 09)
- RE: Multicast Traffic on Backbones Deepak Jain (Jun 09)
- Re: Multicast Traffic on Backbones Jared Mauch (Jun 10)
- Re: Multicast Traffic on Backbones Jared Mauch (Jun 09)
- Re: Multicast Traffic on Backbones Christopher Johnston (Jun 13)
- Re: Multicast Traffic on Backbones Marshall Eubanks (Jun 13)
- RE: Multicast Traffic on Backbones John Olp (Jun 14)
- RE: Multicast Traffic on Backbones David Schwartz (Jun 14)
- RE: Multicast Traffic on Backbones John Olp (Jun 15)
- RE: Multicast Traffic on Backbones David Schwartz (Jun 15)
- RE: Multicast Traffic on Backbones John Olp (Jun 15)
- Re: Multicast Traffic on Backbones Joel Jaeggli (Jun 09)
- RE: Multicast Traffic on Backbones Steve Schaefer (Jun 15)
- Re: Multicast Traffic on Backbones David Charlap (Jun 15)
- RE: Multicast Traffic on Backbones David Schwartz (Jun 15)
- Re: Multicast Traffic on Backbones David Howe (Jun 15)
- RE: Multicast Traffic on Backbones David Schwartz (Jun 15)
- Re: Multicast Traffic on Backbones Joshua Goodall (Jun 10)
- Re: Multicast Traffic on Backbones Tim Winders (Jun 10)
- Re: Multicast Traffic on Backbones Joshua Goodall (Jun 10)
- Re: Multicast Traffic on Backbones Tim Winders (Jun 10)