Verizon Public Policy on Netflix

Fri Jul 11 22:46:26 UTC 2014

On 7/11/14 2:01 PM, Christopher Morrow wrote:
> On Fri, Jul 11, 2014 at 3:07 PM, Blake Hudson <blake at ispn.net> wrote:
>> joel jaeggli wrote the following on 7/11/2014 1:39 PM:
>>
>>> CDN's choose which exit the use all the time, it's kinda the raison de
>>> etré.
> they do this with DNS changes for client requests... pushing a
> customer to an endpoint reachable across one path vs another. (added
> for clarification only)
client requests are typically directed to a pop or distributed between
pops using DNS based GTM,  There are other methods (e.g. anycast
selection). Exit selection from a pop is a forwarding decision. Assuming
the availability of multiple paths, they choose which one to use. this
may be simple best path, ecmp coin flipping, deliberately tuned metrics
or so on... if 174 is having a bad day on the east coast for example you
might to chose to favor 3356 as a path to foo large as. You might favor
a decision which costs you the least as opposed to the one that offers
the best performance.
>>> If a pop has 174 3356 2914 7992 transit(s) chances are they can use any
>>> one of them or all of them to get to foo other large transit as.
>>>
>> Yes, but no matter which network Netflix uses as an exit from their network,
>> Verizon still has the final say on how it enters Verizon's network. If

foo large AS can engage in traffic engineering that would bias one path
selection vs another. Foo Large ASes peers has a distinct incentive to
offload traffic bound for foo large as quickly as possible, and will do
so at their earliest convenience. so the BGP traffic engineering the
influence inbound path selection for the prefix being announced by foo
large AS may not be the most influential decision (unless the withdraw it).

They can of course deliberately constrain the path, engage in quos
marking and queue management to the detriment of the traffic,  or I
suppose just drop it on the floor, but the later would generally be
characterized as an outage.
>> not really? verizon's held (for relationships they call 'settlement
>> free interconnects') to a standard that includes essentially equal
>> announcements across all common interconnects. Ideally this means vzb
>> announces all 10,123 routes across all of the interconnects between
>> 701 and network B...
>>
>> Netflix has several transit providers to choose from, at best they can try
>> each one and see what delivers the best experience to their mutual
> yup, netflix has some idea that "At time T path X-Y-Z-701 is better
> than A-B-C-701" so they force some set of customers across this path
> as best they can by telling these customers taht
> X-Y-Z-701.stream.netflix.net == 1.2.3.4 is the right name/address
> mapping for the content requested.
>
> If something happens during the dns TTL / decision process to change
> DNS with traffic across the X-Y-Z-701 path though... it's not clear to
> me that netflix can affect those active streams. If the pathway goes
> away sure things shift around, if the path just gets congested...
> whoops.
>
> On top of this, there are lots of folk over the peering-wars-years
> that have shown they can influence peering discussions one way or the
> other by pushing traffic across distinct points in the as graph, then
> making press-hay about the mistreatment they are receiving.
>
> (NOTE NOTE NOTE: I have no idea if that's going on, I'm just making
> the point that this very clearly has happened in the past with other
> players)
>
>> customers. Of course, Verizon might change their routing policy tomorrow (or
>> on-demand) and throw that all out of whack. My point is that Verizon
>> advertises several ways to reach Verizon's network. If one path is
>> 'inneficient' as Verizon states, Verizon is at fault for announcing that
>> inefficient path. Netflix does not dictate Verizon's border routing policy,
>> contrary to Verizon's claims.
> it's not the inefficiency of the path, it's the (probably, maybe)
> difference in capacity available vs other/alternate paths.
>
> -chris
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 286 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20140711/290addd6/attachment.sig>