Paying for delivery of packets (was about Sprint Peering, and Importance of Content)
JC Dill
nanog at vo.cnchost.com
Fri Jul 12 06:41:34 UTC 2002
On 08:33 PM 7/11/02, Barney Wolff wrote:
>
>On Thu, Jul 11, 2002 at 08:00:45PM -0700, JC Dill wrote:
>>
>> The problem with asymmetric pricing is that the cost of passing the
packets
>> is equally born by both ends. Take 2 networks that peer, one with mostly
>> content, one with mostly eyeballs. The content providers pay a higher
>> price *per MB* for bandwidth to their provider than the end user does, but
>> both networks have equal costs in transiting the packets from the
server to
>> the end user.
>
>This might be true per Mbps of capacity, but is simply not true per average
>user's MB/month. The typical cable/dsl subscriber still only uses about
>5-10 Kbps, averaged over a month.
Of course it's not true if you compare "one user" to "one content
provider". That comparison is useless.
What you need to compare is $100,000/month (or more) worth of customers,
either all content providers, or all end users. Which group requires more
total bandwidth, and more resilient (redundant) connections? Which group
is more resistant to price increases, more likely to just turn off their
services (or switch to a lower cost provider) rather than pay more if
prices go up (or service goes down)? Which group is more concerned with
Five Nines?
Clearly, one group has a greater interest in ensuring that their packets
are sent as fast as possible, as reliably as possible. Yet, both groups
are equally important for the network (as a whole) to work. My prediction
is that over time, this one group will be willing to foot more and more of
the total cost of the network (from end to end).
>If lots of people start watching video
>streams for much of the day, current cable/dsl rates will not survive.
Current cable/dsl rates will survive (or even decrease), *if* there are
settlements that subsidize the increased bandwidth use/cost from the
content providers to the "eyeball" networks that feed the end users.
jc
More information about the NANOG
mailing list