Verizon Public Policy on Netflix

Fri Jul 11 19:31:19 UTC 2014

Miles Fidelman <mfidelman at meetinghouse.net> writes:

> Either way, if one is a customer of both, one will end up paying for
> the infrastructure - it's more about gorillas fighting, which bill it
> shows up on, who ends up pocketing more of the profits, and how many
> negative side-effects result.

In this case, though, this isn't quite right, is it?

There are a bunch of different ways to get Netflix to an eyeball ISP's
customers.  It seems like right now, Verizon is using one of the ways
which is both expensive and poor quality: settlement-free peering with
Netflix's transit provider.

But, they have other options: direct peering with Netflix and/or using
Netflix's cache architecture.  These seem like they should, overall,
cost less than the current arrangement, and probably would reduce
costs and improve performance for everyone involved.

That's where the posturing comes in.  See, you'll notice Verizon
actually made two arguments for why they weren't going to fix their
capacity problem with Netflix.  One was that Netflix is an
exceptionally huge traffic source and unexpectedly dropped this
traffic load on Verizon through a path that wasn't prepared for it.
That's a semi-reasonable argument for why Netflix should contribute to
improving the situation; it's not like this is really unexpected, or
that Netflix hasn't offered to contribute, but it's reasonable to have
a negotiation about who pays for what.

The other argument was essentially "Netflix sends us more data than we
send them".  As others have commented, that's nonsense.  But the
reason for trying this argument is the old settlement-free peering
problem: Verizon does not want Netflix as a peer if it can possibly
have Netflix as a paying customer, and so it has an incentive to place
obstacles in its path; and it certainly doesn't want to give everyone
else the idea that they can become peers too.  That is the real
problem here and is why this has become a huge fight instead of a
really straightforward transaction.