diff options
| author | Neal Cardwell <ncardwell@google.com> | 2021-07-27 10:42:58 -0400 |
|---|---|---|
| committer | David S. Miller <davem@davemloft.net> | 2021-07-27 20:07:21 +0100 |
| commit | a657db0350bb8f568897835b6189c84a89f13292 (patch) | |
| tree | 40699aa991aa192060e472048665088a7029bfd1 /net/ipv4/tcp_recovery.c | |
| parent | 63f367d9de77b30f58722c1be9e334fb0f5f342d (diff) | |
| download | linux-a657db0350bb8f568897835b6189c84a89f13292.tar.bz2 | |
tcp: more accurately check DSACKs to grow RACK reordering window
Previously, a DSACK could expand the RACK reordering window when no
reordering has been seen, and/or when the DSACK was due to an
unnecessary TLP retransmit (rather than a spurious fast recovery due
to reordering). This could result in unnecessarily growing the RACK
reordering window and thus unnecessarily delaying RACK-based fast
recovery episodes.
To avoid these issues, this commit tightens the conditions under which
a DSACK triggers the RACK reordering window to grow, so that a
connection only expands its RACK reordering window if:
(a) reordering has been seen in the connection
(b) a DSACKed range does not match the most recent TLP retransmit
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Acked-by: Yuchung Cheng <ycheng@google.com>
Acked-by: Priyaranjan Jha <priyarjha@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/ipv4/tcp_recovery.c')
| -rw-r--r-- | net/ipv4/tcp_recovery.c | 3 |
1 files changed, 2 insertions, 1 deletions
diff --git a/net/ipv4/tcp_recovery.c b/net/ipv4/tcp_recovery.c index 6f1b4ac7fe99..fd113f6226ef 100644 --- a/net/ipv4/tcp_recovery.c +++ b/net/ipv4/tcp_recovery.c @@ -172,7 +172,8 @@ void tcp_rack_reo_timeout(struct sock *sk) /* Updates the RACK's reo_wnd based on DSACK and no. of recoveries. * - * If DSACK is received, increment reo_wnd by min_rtt/4 (upper bounded + * If a DSACK is received that seems like it may have been due to reordering + * triggering fast recovery, increment reo_wnd by min_rtt/4 (upper bounded * by srtt), since there is possibility that spurious retransmission was * due to reordering delay longer than reo_wnd. * |