Verizon Public Policy on Netflix

Mon Jul 14 00:06:02 UTC 2014

>My customers do not want me to "creatively" find ways to extract
>additional money from them so as to cover *expenses that Netflix
>should be covering*. Nor do they want me to subsidize Netflix
>subscribers from the fees from non-Netflix subscribers. They
>want to pay a fair price for their Internet that does not include
>paying ransom to third parties.

(emphasis mine)

I've gotta be frank here:  I really don't understand the line of reasoning from 
an access network's perspective that says $CONTENT needs to pay $ACCESS to 
accept the bits that $ACCESS's users requested from $CONTENT.  I might be 
missing nuances here, but I've not yet come across an argument that's convinced 
me of why this should be the case.

Of course your customers don't want prices raised; that's a no-brainer, and 
similarly it's fair for Grandma that just checks her email and Facebook to not 
want to carry the infrastructure costs of someone who consumes more content.  I 
think what Charles is driving at is that users don't care about whether you 
pull in content through 1850 Pearl Street, transit, direct peering, or 
whatever; if I as a customer am paying for a 50 mbps service, I want my 50 mbps 
service.  That said, to your point of no performance/connectivity guarantees 
to/from third parties: experience seems to indicate that users understand that 
you're not responsible for ensuring Netflix can *push out* the content at a 
given rate.  However, if Netflix is capable of delivering the bits to your 
doorstep (wherever that is), it becomes your problem to get those bits from 
your doorstep to the customer.

If Netflix users (or users of any other bandwidth-hungry service) are sucking 
up more than "their fair share", which is generally to say that they're over 
your oversubscription ratio, and they are *also* over the minimum capacity that 
you're guaranteeing below, you're in the clear from a business standpoint as 
long as your remaining users still get their minimum.  If other users are 
starting to get impacted so that they don't get their guaranteed minumum, 
that's a network management problem (i.e.  how do I cap the "offending" traffic 
so that other users' still get their guaranteed rate?).  I suspect you may have 
a hard time explaining to the Netflix users that, while you're 
dropping/delaying their traffic in that case, you're still delivering the 
promised service because they're still getting their minimum service to 1850 
Pearl as they're traffic is coming in from somewhere else, but I digress...

If those users are over the overscription ratio *but* still below their 
guaranteed minimum, that sucks for the provider, but it's still the provider's 
problem, and the math in the business plan was apparently wrong.  Since not all 
users consume exactly the same amount of network resources, someone is *always* 
subsidizing someone else's service; the question is just "by how much?"  If the 
value north of the oversubscription ratio is sufficiently large that it's 
becoming a problem, either the agreement with the user(s) needs to be adjusted 
("I know we said x mbps, but we actually meant < x mbps"), which again sucks 
from a business standpoint but is the provider's problem to deal with, or 
capacity needs to be augmented to match.  The agreement bump can be either 
global (which again is a difficult business maneuver) or targeted at the users 
sucking up the extra capacity (which is more palatable, though users still 
generally balk at tiered/usage pricing).

None of these are really fun to deal with from the business side, but if 
$CONTENT is simply getting the bits to your edge as requested, I don't see in 
any way how they can be blamed for the unfortunate business situation in which 
$ACCESS finds himself.  User asks for bits; $CONTENT gets the bits to $ACCESS's 
edge; $CONTENT's responsibility is done.

You stated earlier:
>"Open Connect" is not, in fact, a CDN. Nor is it "peering." It is merely a set
>of policies for direct connection to ISPs, and for placing servers in ISPs'
>facilities, that is as favorable as possible in every way to Netflix.

That's news to me.  We peer settlement-free with Netflix at the SIX, and they 
cover that in the OpenConnect umbrella term:

"ISPs can directly connect their networks to Open Connect for free. ISPs can do 
this either by free peering with us at common Internet exchanges, or can save 
even more transit costs by putting our free storage appliances in or near their 
network."
 -- https://www.netflix.com/openconnect

Also:
>Because it requires expensive bandwidth that's dedicated solely to Netflix,
>"peering" (as Netflix calls it; it's really just a dedicated link) has 0%,
>not 100%, offload. The ISP is paying for all of the bandwidth, and it
>cannot be used for anything else.

I don't see any requirements that this is a dedicated link; we peer with them 
over public peering fabric and exchange a bunch of other traffic over that 
link.  Is there another requirement in OpenConnect peering that we've just not 
hit but you are subject to?

OpenConnect has a range of options, from public peering to private 
interconnects to caching appliances; the intention, I gather, is to provide a 
range of options.  Exchange a bit of traffic but not really all that much?  
Public peering.  Starting to consume a bunch of traffic but don't want a cache 
appliance?  Private interconnect.  Exchange a bunch of traffic and prefer 
caching?  Get a free appliance.

Presumably if you're not peering with Netflix and you don't have an appliance, 
you're getting the traffic via transit.  You're free to not do any of the above 
if you find your transit costs for Netflix traffic are lower than those options 
(or if you just don't like OpenConnect), but for a lot of people public/private 
peering or a caching appliance saves $$ and resources.

>...(b) pay them equitably for direct connections (smaller and more remote ISPs 
>have higher costs per customer and should get MORE per account than Comcast, 
>rather than receiving nothing);

The Comcast and Verizon deals were made because those guys had leverage, not 
because it costs them more.  "We should get paid because Comcast got paid" 
doesn't add up.

On Sun 2014-Jul-13 17:00:46 -0600, Brett Glass <nanog at brettglass.com> wrote:
>At 10:25 AM 7/13/2014, Charles Gucker wrote:
>
>>ALL ISPs are in the business of providing access to
>>the Internet.    If you feel the need to rebel, then I suggest you
>>look at creative ways to increase revenue from your customers,
>
>My customers do not want me to "creatively" find ways to extract
>additional money from them so as to cover expenses that Netflix
>should be covering. Nor do they want me to subsidize Netflix
>subscribers from the fees from non-Netflix subscribers. They
>want to pay a fair price for their Internet that does not include
>paying ransom to third parties.
>
>We currently provide that: we guarantee each subscriber a certain
>minimum capacity  to the Internet exchange at 1850 Pearl Street
>in Denver (to which Netflix does not directly connect) with a certain
>maximum duty cycle. But we can't guarantee the performance of a specific
>third party service such as Netflix. If Netflix wants us to do that,
>it is going to have to pay us, as it pays Comcast. That's only fair,
>because we would be doing something special just for it -- something
>which costs money.
>
>If Netflix tries to use its market power to harm ISPs, or to smear
>us via nasty on-screen messages as it has been smearing Verizon, ISPs have
>no choice but to react. One way we could do this -- and I'm strongly
>considering it -- is to start up a competing streaming service that
>IS friendly to ISPs. It would use the minimum possible amount of
>bandwidth, make proper use of caching, and -- most importantly --
>actually PAY Internet service providers, instead of sapping their
>resources, by allowing them to sell it and keep a portion of the fee.
>This would provide an automatic, direct, per-customer reimbursement
>to the ISP for the cost of bandwidth. ISPs would sign on so fast
>that such a service could BURY Netflix in short order.
>
>--Brett Glass
>

--
Hugo