[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Netflix stuffing data on pipe
- Subject: Netflix stuffing data on pipe
- From: josh at kyneticwifi.com (Josh Reynolds)
- Date: Wed, 30 Dec 2015 02:22:09 -0600
- In-reply-to: <[email protected]>
- References: <[email protected]> <CAC6=tfaxmo3_7ze60L0WkYT+dJY0+k8_fzVgPNXHMk+BY7ipiA@mail.gmail.com> <[email protected]> <CAC6=tfaPSmF47R_c_BfEe+AHKbjiCaGa8nvSxgG=8nOi5VXFWg@mail.gmail.com> <[email protected]>
It's a long and ugly story...
1Gbps FD feeds -> switch -> 100Mbps FD radio port -> fluctuating PHY rate
Half Duplex wireless link/CPE (shaped here).
Netflix is microbusting, and its really nasty on his kind of network,
especially with the shaping being toward the end of his network.
On Dec 30, 2015 1:59 AM, "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)
>
>