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

[Simon Barber]

Current versions of Wireshark have an experimental feature I added to 
expose airtime usage per packet and show 802.11 pcaps on a timeline.

Enable it under Preferences->Protocol->802.11 Radio

Simon

On June 25, 2018 6:27:59 PM Dave Taht <dave.taht at gmail.com> wrote:

> On Mon, Jun 25, 2018 at 5:44 PM, Jonathan Morton <chromatix99 at gmail.com> wrote:
>>> On 26 Jun, 2018, at 3:36 am, Simon Barber <simon at 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.
>
> Whoa, nelly! In the context of the local tcp stack over wifi, I was
> making an observation that I "frequently" saw a pattern of a single
> ack txop followed by a bunch in a separate txop. and I suggested a
> very short (10us) timeout before committing to the hw - not 1ms.
>
> Aside from this anecdote we have not got real data or statistics. The
> closest thing I have to a tool that can take apart wireless aircaps is
> here: https://github.com/dtaht/airtime-pie-chart which can be hacked
> to take more things apart than it currently does. Looking for this
> pattern in more traffic would be revealing in multiple ways. Looking
> for more patterns in bigger wifi networks would be good also.
>
> I like erics suggestion of doing more ack compression higher up in the
> tcp stack.
>
> There are two other things I've suggested in the past we look at. 1)
> The current fq_codel_for_wifi code has a philosophy of "one aggregate
> in the hardware, one ready to go". A simpler modification to fit more
> in would be to (wait the best case estimate for delivering the one in
> the hardware - a bit), then form the one ready-to-go.
>
> 2) rate limiting mcast and smoothing mcast bursts over time, allowing
> more unicast through. presently the mcast queue is infinite and very
> bursty. 802.11 std actually suggests mcast be rate limited by htb,
> where I'd be htb + fq + merging dup packets. I was routinely able to
> blow up the c.h.i.p's wifi and the babel protocol by flooding it with
> mcast, as the local mcast queue could easily grow 16+ seconds long.
>
> um, I'm giving a preso tomorrow and will run behind this thread. It's
> nice to see the renewed enthusiasm here, keep it up.
>
>>> 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.
>
>>  - Jonathan Morton
>>
>> _______________________________________________
>> Bloat mailing list
>> Bloat at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
>
>
>
> --
>
> Dave Täht
> CEO, TekLibre, LLC
> http://www.teklibre.com
> Tel: 1-669-226-2619


Sent with AquaMail for Android
https://www.mobisystems.com/aqua-mail