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

[David Lang <david@lang.hm>]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2640 bytes --]

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?

I could see an argument that fairness algorithms need this info, but the per 
txop overhead is _so_ much larger than the data transmission, that you would 
have to add a huge amount of data to noticably affect the length of the 
transmission.

remember, in wifi you don't ask a central point for permission to use X amount 
of airtime, you wait for everyone to stop transmitting (and then a random time) 
and then start sending. Nothing else in the area knows that you are going to 
start transmitting, and it's only once they start decoding the start of the rf 
packet you are sending that they can see how long it will be before you finish

>> If there are no other stations competing for airtime, why does it matter that we use two txops?
>
> One further argument would be power consumption.  Radio transmitters eat 
> batteries for lunch; the only consistently worse offender I can think of is a 
> display backlight, assuming the software is efficient.

True, but this gets back to the question of how frequent this case is.

If you are in areas with congestion most of the time, so the common case is to 
have to wait long enough for the data to be combined, then the difference in 
power savings is going to be small.

'waiting just in case there is more to send' looks good on specific benchmarks, 
but it adds latency all the time, even when it's not needed.

Now, using a travel analogy

I think how we operate today is as if we were a train at a station, when we 
first are ready to move, the doors are closed and everyone sits inside waiting 
for permission to move (think of how annoyed you have been sitting in a closed 
aircraft at an airport waiting to move), and anyone outside has to wait for the 
next train

But if instead we leave the doors open after we request permission, and only 
close them when we know that we are going to be able to send very soon, late 
arrivals can board.