Netflix stuffing data on pipe

Wed Dec 30 07:59:50 UTC 2015

On Tue 2015-Dec-29 21:17:51 -0600, Josh Reynolds <josh at kyneticwifi.com> wrote:

>The second part. Fixed wireless is not even on their radar.
>On Dec 29, 2015 9:16 PM, "Matt Hoppes" <mhoppes at indigowireless.com> wrote:
>
>> So they are trying to stuff every last bit as an end device modulates up
>> and down?
>>
>> Or are you saying that's how they determine if they can scale up the
>> resolution "because there is more throughout available now".
>>
>> On Dec 29, 2015, at 22:10, Josh Reynolds <josh at kyneticwifi.com> wrote:
>>
>> Adaptive bandwidth detection.
>> On Dec 29, 2015 8:59 PM, "Matt Hoppes" <mhoppes at indigowireless.com> wrote:
>>
>>> Has anyone else observed Netflix sessions attempting to come into
>>> customer CPE devices at well in excess of the customers throttled plan?
>>>
>>> I'm not talking error retries on the line. I'm talking like two to three
>>> times in excess of what the customers CPE device can handle.
>>>
>>> I'm observing massive buffer overruns in some of our switches that appear
>>> to be directly related to this. And I can't figure out what possible good
>>> purpose Netflix would have for attempting to do this.
>>>

Pardon my ignorance of WISP-specific bits here, but how are they supposed 
to know to back off on their bitrate ramp-up if you keep buffering rather 
than dropping packets when the TX rate exceeds the customer's service rate?  
Or what am I missing?

>>> Curious if anyone else has seen it?
>>
>>

-- 
Hugo

hugo at slabnet.com: email, xmpp/jabber
PGP fingerprint (B178313E):
CF18 15FA 9FE4 0CD1 2319 1D77 9AB1 0FFD B178 313E

(also on Signal)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20151229/86c24a85/attachment.sig>