netdev - Re: [PATCH net-next v12 3/7] sch_cake: Add optional ACK filter

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 17 May 2018 13:23:17 +0200
From:   Toke Høiland-Jørgensen <toke@...e.dk>
To:     Eric Dumazet <eric.dumazet@...il.com>, netdev@...r.kernel.org
Cc:     cake@...ts.bufferbloat.net
Subject: Re: [PATCH net-next v12 3/7] sch_cake: Add optional ACK filter

Eric Dumazet <eric.dumazet@...il.com> writes:

> On 05/16/2018 01:29 PM, Toke Høiland-Jørgensen wrote:
>> The ACK filter is an optional feature of CAKE which is designed to improve
>> performance on links with very asymmetrical rate limits. On such links
>> (which are unfortunately quite prevalent, especially for DSL and cable
>> subscribers), the downstream throughput can be limited by the number of
>> ACKs capable of being transmitted in the *upstream* direction.
>> 
>
> ...
>
>> 
>> Signed-off-by: Toke Høiland-Jørgensen <toke@...e.dk>
>> ---
>>  net/sched/sch_cake.c |  260 ++++++++++++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 258 insertions(+), 2 deletions(-)
>> 
>>
>
> I have decided to implement ACK compression in TCP stack itself.

Awesome! Will look forward to seeing that!

> First step is to take care of SACK, which are the main source of the
> bloat, since we send one SACK for every incoming out-of-order packet.
>
> These SACK are not only causing pain on the network, they also cause
> the sender to send one MSS at a time (TSO auto defer is not engaged in
> this case), thus starting to fill its RTX queue with pathological skbs
> (1-MSS each), increasing processing time.
>
> I see that your ACK filter does not take care of this common case :)

We don't do full parsing of SACKs, no; we were trying to keep things
simple... We do detect the presence of SACK options, though, and the
presence of SACK options on an ACK will make previous ACKs be considered
redundant.

> Doing the filtering in TCP has the immense advantage of knowing the
> RTT and thus be able to use heuristics causing less damage.

Quite so. I'll be quite happy if the CAKE ACK filter can be delegated to
something only relevant for the poor sods stuck on proprietary operating
systems :)


Are you satisfied that the current version of the filter doesn't mangle
the skbs or crash the kernel?

-Toke