netdev - Re: [PATCH net-next] tcp: avoid slow start during fast recovery on new losses

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] [day] [month] [year] [list]

Date:   Mon, 2 Nov 2020 17:18:53 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Yuchung Cheng <ycheng@...gle.com>
Cc:     davem@...emloft.net, netdev@...r.kernel.org, edumazet@...gle.com,
        ncardwell@...gle.com, nanditad@...gle.com,
        Matt Mathis <mattmathis@...gle.com>
Subject: Re: [PATCH net-next] tcp: avoid slow start during fast recovery on
 new losses

On Fri, 30 Oct 2020 18:34:12 -0700 Yuchung Cheng wrote:
> During TCP fast recovery, the congestion control in charge is by
> default the Proportional Rate Reduction (PRR) unless the congestion
> control module specified otherwise (e.g. BBR).
> 
> Previously when tcp_packets_in_flight() is below snd_ssthresh PRR
> would slow start upon receiving an ACK that
>    1) cumulatively acknowledges retransmitted data
>    and
>    2) does not detect further lost retransmission
> 
> Such conditions indicate the repair is in good steady progress
> after the first round trip of recovery. Otherwise PRR adopts the
> packet conservation principle to send only the amount that was
> newly delivered (indicated by this ACK).
> 
> This patch generalizes the previous design principle to include
> also the newly sent data beside retransmission: as long as
> the delivery is making good progress, both retransmission and
> new data should be accounted to make PRR more cautious in slow
> starting.
> 
> Suggested-by: Matt Mathis <mattmathis@...gle.com>
> Suggested-by: Neal Cardwell <ncardwell@...gle.com>
> Signed-off-by: Yuchung Cheng <ycheng@...gle.com>
> Signed-off-by: Neal Cardwell <ncardwell@...gle.com>
> Signed-off-by: Eric Dumazet <edumazet@...gle.com>

Applied, thanks!