Re: [Bloat] [Make-wifi-fast] benefits of ack filtering

[Bob McMahon <bob.mcmahon@broadcom.com>]

[-- Attachment #1: Type: text/plain, Size: 2518 bytes --]

802.11 acks are packet or ampdu driven while tcp, being a byte protocol,
acks bytes.  Aligning these may not be straightforward.  We test with
different read() rates on the wifi clients as TCP is supposed to flow
control the source's writes() as well.  Wifi clients are starting to align
their sleep cycles with "natural" periodicity in traffic so having larger
aggregates can help both peak average throughput as well as power
consumption.  It's not obvious with Wifi that a faster RTT is always
better.  (Reminds me of the early days of NASA where many designed to
reduce weight without keeping in account structural integrity, shave a few
grams and lose a rocket.)

Bob

On Fri, Dec 1, 2017 at 9:42 AM, Dave Taht <dave@taht.net> wrote:

> Toke Høiland-Jørgensen <toke@toke.dk> writes:
>
> > Luca Muscariello <luca.muscariello@gmail.com> writes:
> >
> >> If I understand the text right, FastACK runs in the AP and generates an
> ACK
> >> on behalf (or despite) of the TCP client end.
> >> Then, it decimates dupACKs.
> >>
> >> This means that there is a stateful connection tracker in the AP. Not so
> >> simple.
> >> It's almost, not entirely though, a TCP proxy doing Split TCP.
> >
> > Yeah, it's very much stateful, and tied closely to both TCP and the MAC
> > layer. So it has all the usual middlebox issues as far as that is
> > concerned... Also, APs need to transfer state between each other when
> > the client roams.
> >
> > It does increase single-flow TCP throughput by up to a factor of two,
> > though... Which everyone knows is the most important benchmark number ;)
>
> Were you always as cynical as I am?
>
> I'd like to compare (eventually) what we are trying with cake's new ack
> filter here, which at least doesn't lie to the endpoint.
>
> my guess, however, would be that the media access negotiation will
> dominate the cost, and savings from (say) reducing 10 acks to 1 would
> only be somewhere in the 5-20% range, for simple benchmarks.
>
> I think we might get a better rrul result, however, as we'd be able to
> pack more big flows into a given aggregate, with less acks there.
>
> >
> > -Toke
> > _______________________________________________
> > Bloat mailing list
> > Bloat@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/bloat
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>

[-- Attachment #2: Type: text/html, Size: 3532 bytes --]