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

[Dave Taht <dave.taht@gmail.com>]

On Mon, Jun 25, 2018 at 5:44 PM, Jonathan Morton <chromatix99@gmail.com> 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.

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@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat



-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619