[Bloat] benefits of ack filtering

[Dave Taht]

Toke Høiland-Jørgensen <toke at toke.dk> writes:

> Luca Muscariello <luca.muscariello at 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 at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat