Re: [Make-wifi-fast] Status of the industry on over buffering at the WiFi air interface

["David P. Reed" <dpreed@deepplum.com>]

Wow. I didn't know Pause Frames were becoming commonly used. That's terrible in general, but I guess for a dedicated box with only one path outgoing it is OK. A pause tells a source to stop sending to the access router. It doesn't reflect any path dependency, so if the access router were actually a *router* that could feed more than one outgoing link, a pause would not be selective enough.

So this is a special case that moves the bufferbloat situation into the router.

But I really thank you, because that resolves one issue being observed. That's new information for me. So thanks again! Is there a "best practice RFC" aoout using Pause Frames in the Ethernet under IP? Or is this just random hacking by hardware vendors who don't understand the end-to-end nature of congestion management?

However, the other issue observed, which I didn't mention, is that there is a big problem on the downlink side, too, when using one of several different APs. I'm not aware of how a pause frame might be utilized by a laptop using WiFi, or even if there is a notion of Pause Frame in Windows WiFi drivers. (if there were, then "out of control" congestion would be a property of both a Netgear and a Linksys AP, both of which had this "download" lag under load.)

On Thursday, February 13, 2020 5:36pm, "Jonathan Morton" <chromatix99@gmail.com> said:

>> On 14 Feb, 2020, at 12:23 am, David P. Reed <dpreed@deepplum.com> wrote:
>>
>> The modem clearly is capable of giving congestion control signals to a directly
>> connected Ethernet path (non-wireless), by dropping packets.
> 
> No - by sending Pause frames back.  It's an increasingly-used method of applying
> back pressure on an Ethernet link, in preference to dropping packets.  If it *did*
> drop packets, you wouldn't get an F grade for bloat.
> 
> So the Nighthawk is correctly halting Ethernet output in response to those frames
> (it's probably a function of the NIC hardware or driver), but exercises absolutely
> no control over the queue that builds up as a result.
> 
>  - Jonathan Morton
> 
>