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."
-- Netflix | Open Connect
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.
