Re: net neutrality and peering wars continue

[Blake Dunlap <ikiris () gmail com>]

It's only cutting off your nose to spite your face if you look at the
internet BU in a vacuum. The issue comes when they can get far more money
from their existing product line, than what they get being a dumb bandwidth
pipe to their customers.

They don't want reasonable or even unreasonable pricing per meg, they want
content to pay for access to their customers in the same range of cost that
they currently get from their other arm's subscribers or to sit down and
shut up and stop competing with their much more profitable broadcast arm.
Because they can't just charge a premium on the internet access itself, as
their customers would leave due to competition from providers that *are*
just dumb pipes to transit based content.

-Blake


On Thu, Jun 20, 2013 at 6:18 PM, Leo Bicknell <bicknell () ufp org> wrote:

> On Jun 20, 2013, at 5:47 PM, Robert M. Enger <NANOG () enger us> wrote:
>
> > Perhaps last-mile operators should
> > A) advertise each of their metropolitan regional systems as a separate AS
> > B) establish an interconnection point in each region where they will
> accept traffic destined for their in-region customers without charging any
> fee
>
> C) Buck up and carry the traffic their customers are paying them to carry.
>
> Least I just sound like a complainer, I actually think this makes rational
> business sense.
>
> The concept of peering was always "equal benefit", not "equal cost".  No
> one ever compares the price of building last mile transport to the cost of
> building huge data centers all over with content close to the users.  The
> whole "bit-mile" thing represents an insignificant portion of the cost,
> long haul (in large quantities) is dirt cheap compared to last mile or data
> center build costs.  If you think of a pure content play peering with a
> pure eyeball play there is equal benefit, in fact symbiosis, neither could
> exist without the other.  The traffic flow will be highly asymmetric.
>
> Eyeball networks also artificially cap their own ratios with their
> products.  Cable and DSL are both 3x-10x down, x up products.  Their TOS
> policies prohibit running servers.  Any eyeball network with a asymmetric
> edge technology and no-server TOS need only look in the mirror to see why
> their aggregate ratio is hosed.
>
> Lastly, simple economics.   Let's theorize about a large eyeball network
> with say 20M subscribers, and a large content network with say 100G of
> peering traffic to go to those subscribers.
>
> * Choice A would be to squeeze the peer for bad ratio in the hope of
> getting them to pay for, or be behind some other transit customer.  Let's
> be generous and say $3/meg/month, so the 100G of traffic might generate
> $300,000/month of revenue.  Let's even say you can squeeze 5 CDN's for that
> amount, $1.5M/month total.
>
> * Choice B would be to squeeze the subscribers for more revenue to carry
> the 100G of "imbalanced traffic".  Perhaps an extra $0.10/sub/month.  That
> would be $2M/month in extra revenue.
>
> Now, consider the customer satisfaction issue?  Would your broadband
> customers pay an extra $0.10 per month if Netflix and Amazon streaming
> never went out in the middle of a movie?  Would they move up to a higher
> tier of service?
>
> A smart end user ISP would find a way to get uncongested paths to the
> content their users want, and make it rock solid reliable.  The good
> service will more than support not only cost recovery, but higher revenue
> levels than squeezing peers.  Of course we have evidence that most end user
> ISP's are not smart, they squeeze peers and have some of the lowest
> customer satisfaction rankings of not just ISP's, but all service
> providers!  They want to claim consumers don't want Gigabit fiber, but then
> congest peers so badly there's no reason for a consumer to pay for more
> than the slowest speed.
>
> Squeezing peers is a prime case of cutting off your nose to spite your
> face.
>
> --
>        Leo Bicknell - bicknell () ufp org - CCIE 3440
>         PGP keys at http://www.ufp.org/~bicknell/