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]

Message-ID: <877eo2xw8s.fsf@toke.dk>
Date:   Thu, 17 May 2018 15:11:31 +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/17/2018 04:23 AM, Toke Høiland-Jørgensen wrote:
>
>> 
>> 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.
>> 
>
> But they are not redundant in some cases, particularly when reorders
> happen in the network.

Huh. I was under the impression that SACKs were basically cumulative
until cleared.

I.e., in packet sequence ABCDE where B and D are lost, C would have
SACK(B) and E would have SACK(B,D). Are you saying that E would only
have SACK(D)?

-Toke