Netflix stuffing data on pipe

Wed Dec 30 12:42:33 UTC 2015

I'm not buffering. Switches have packet buffers. I'm seeing switch buffers getting overrun by what appears to be Netflix traffic coming in at rates faster than the subscribers throttled speeds. 

> On Dec 30, 2015, at 02:59, Hugo Slabbert <hugo at slabnet.com> wrote:
> 
>> 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)
> 