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: