netdev - Re: [PATCH net] tcp: fix F-RTO may not work correctly when receiving DSACK

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: <CADVnQy=0MQ-AvfJShdP9mCWHVG3cVpHXrkuw9wbzGSsXughxeg@mail.gmail.com>
Date:   Thu, 28 Apr 2022 13:06:26 -0400
From:   Neal Cardwell <ncardwell@...gle.com>
To:     Pengcheng Yang <yangpc@...gsu.com>
Cc:     Eric Dumazet <edumazet@...gle.com>,
        Yuchung Cheng <ycheng@...gle.com>, netdev@...r.kernel.org,
        "David S. Miller" <davem@...emloft.net>,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        David Ahern <dsahern@...nel.org>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>
Subject: Re: [PATCH net] tcp: fix F-RTO may not work correctly when receiving DSACK

On Tue, Apr 26, 2022 at 6:04 AM Pengcheng Yang <yangpc@...gsu.com> wrote:
>
> Currently DSACK is regarded as a dupack, which may cause
> F-RTO to incorrectly enter "loss was real" when receiving
> DSACK.
>
> Packetdrill to demonstrate:
>
> // Enable F-RTO and TLP
>     0 `sysctl -q net.ipv4.tcp_frto=2`
>     0 `sysctl -q net.ipv4.tcp_early_retrans=3`
>     0 `sysctl -q net.ipv4.tcp_congestion_control=cubic`
>
> // Establish a connection
>    +0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
>    +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
>    +0 bind(3, ..., ...) = 0
>    +0 listen(3, 1) = 0
>
> // RTT 10ms, RTO 210ms
>   +.1 < S 0:0(0) win 32792 <mss 1000,sackOK,nop,nop,nop,wscale 7>
>    +0 > S. 0:0(0) ack 1 <...>
>  +.01 < . 1:1(0) ack 1 win 257
>    +0 accept(3, ..., ...) = 4
>
> // Send 2 data segments
>    +0 write(4, ..., 2000) = 2000
>    +0 > P. 1:2001(2000) ack 1
>
> // TLP
> +.022 > P. 1001:2001(1000) ack 1
>
> // Continue to send 8 data segments
>    +0 write(4, ..., 10000) = 10000
>    +0 > P. 2001:10001(8000) ack 1
>
> // RTO
> +.188 > . 1:1001(1000) ack 1
>
> // The original data is acked and new data is sent(F-RTO step 2.b)
>    +0 < . 1:1(0) ack 2001 win 257
>    +0 > P. 10001:12001(2000) ack 1
>
> // D-SACK caused by TLP is regarded as a dupack, this results in
> // the incorrect judgment of "loss was real"(F-RTO step 3.a)
> +.022 < . 1:1(0) ack 2001 win 257 <sack 1001:2001,nop,nop>
>
> // Never-retransmitted data(3001:4001) are acked and
> // expect to switch to open state(F-RTO step 3.b)
>    +0 < . 1:1(0) ack 4001 win 257
> +0 %{ assert tcpi_ca_state == 0, tcpi_ca_state }%
>
> Fixes: e33099f96d99 ("tcp: implement RFC5682 F-RTO")
> Signed-off-by: Pengcheng Yang <yangpc@...gsu.com>
> ---

Thanks for the fix and test! Both look good to me. The patch passes
all of our team's packetdrill tests, and this new test passes as well.

Acked-by: Neal Cardwell <ncardwell@...gle.com>
Tested-by: Neal Cardwell <ncardwell@...gle.com>

thanks,
neal