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

[Jonathan Morton]

> On 22 Jun, 2018, at 5:49 pm, Michael Richardson <mcr at sandelman.ca> wrote:
> 
>> I would instead frame the problem as "how can we get hardware to
>> incorporate extra packets, which arrive between the request and grant
>> phases of the MAC, into the same TXOP?"  Then we no longer need to
>> think probabilistically, or induce unnecessary delay in the case that
>> no further packets arrive.
> 
> I've never looked at the ring/buffer/descriptor structure of the ath9k, but
> with most ethernet devices, they would just continue reading descriptors
> until it was empty.   Is there some reason that something similar can not
> occur?
> 
> Or is the problem at a higher level?
> Or is that we don't want to enqueue packets so early, because it's a source
> of bloat?

The question is of when the aggregate frame is constructed and "frozen", using only the packets in the queue at that instant.  When the MAC grant occurs, transmission must begin immediately, so most hardware prepares the frame in advance of that moment - but how far in advance?

Behaviour suggests that it can be as soon as the MAC request is issued, in response to the *first* packet arriving in the queue - so a second TXOP is required for the *subsequent* packets arriving a microsecond later, even though there's technically still plenty of time to reform the aggregate then.

In principle it should be possible to delay frame construction until the moment the radio is switched on; there is a short period consumed by a data-indepedent preamble sequence.  In the old days, HW designers would have bent over backwards to make that happen.

 - Jonathan Morton