Re: [Bloat] lwn.net's tcp small queues vs wifi aggregation solved

["Toke Høiland-Jørgensen" <toke@toke.dk>]

David Lang <david@lang.hm> writes:

> On Tue, 26 Jun 2018, Jonathan Morton wrote:
>
>>> On 26 Jun, 2018, at 3:36 am, Simon Barber <simon@superduper.net> wrote:
>>>
>>> Most hardware needs the packet finalized before it starts to contend for the 
>>> medium (as far as I’m aware - let me know if you know differently). One issue 
>>> is that if RTS/CTS is in use, then the packet duration needs to be known in 
>>> advance (or at least mid point of the RTS transmission).
>>
>> This is a valid argument.  I think we could successfully argue for a delay of 
>> 1ms, if there isn't already enough data in the queue to fill an aggregate, 
>> after the oldest packet arrives until a request is issued.
>
> why does the length of the txop need to be known at the time that it's
> requested?

Because that's how the hardware is designed. There are really two
discussions here: (1) what could we do with a clean-slate(ish) design,
and (2) what can we retrofit into existing drivers such as the ath9k.

I think that the answer to (1) is probably 'quite a lot', but
unfortunately the answer to (2) is 'not that much'. We could probably do
a little bit better in ath9k, but for anything newer all bets are off,
as this functionality has moved into firmware.

Now, if there was a hardware vendor that was paying attention and could
do the right thing throughout the stack, that would be awesome of
course. But for Linux at least, sadly it seems that most hardware
vendors can barely figure out how to get *any* driver upstream... :/

Also, from a conceptual point of view, I really think ACK timing issues
are best solved at the TCP stack level. Which Eric is already working on
(SACK compression is already in 4.18, with normal ACK compression to
follow).

-Toke