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

[David Lang]

On Tue, 26 Jun 2018, Jonathan Morton wrote:

>> We only care about conserving txops when they are scarce, not when they are abundant.
>> 
>> This principle is why a window system as crazy as X11 is competitive: it naturally becomes more efficient in the face of load (more and more requests batch up and are handled at maximum efficiency, so the system is at maximum efficiency at full load.
>> 
>> Or am I missing something here?
>
> The problem is that currently every data aggregate received (one TXOP each 
> from the AP) results in two TXOPs just to acknowledge them, the first one 
> containing only a single ack.  This is clearly wasteful, given the airtime 
> overhead per TXOP relative to the raw data rate of modern wifi.  Relying 
> solely on backpressure would require that the channel was sufficiently busy to 
> prevent the second TXOP from occurring until the following data aggregate is 
> received, and that just seems too delicate to me.

If there are no other stations competing for airtime, why does it matter that we 
use two txops? [1]

If there are no other stations that you are competing with for airtime, go ahead 
and use it. If there are other stations that you are competing with for airtime, 
you are unlikely to get the txop immediately, so as long as you can keep 
updating the rf packet to send until the txop actially happens, the later data 
will get folded in.

There will be a few times when you do get the txop immediately, and so you do 
end up 'wasting' a txop, but the vast majority of the time you will be able to 
combine the packets.

Now, the trick is figureing out how long we can wait to finalize the rf packet

David Lang


[1] ignoring the hidden transmitter problem for the moment)