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>
This commit is contained in:
Neal Cardwell 2021-07-27 10:42:58 -04:00 committed by David S. Miller
parent 63f367d9de
commit a657db0350
2 changed files with 10 additions and 2 deletions

View File

@ -1001,7 +1001,14 @@ static u32 tcp_dsack_seen(struct tcp_sock *tp, u32 start_seq,
return 0; return 0;
tp->rx_opt.sack_ok |= TCP_DSACK_SEEN; tp->rx_opt.sack_ok |= TCP_DSACK_SEEN;
tp->rack.dsack_seen = 1; /* We increase the RACK ordering window in rounds where we receive
* DSACKs that may have been due to reordering causing RACK to trigger
* a spurious fast recovery. Thus RACK ignores DSACKs that happen
* without having seen reordering, or that match TLP probes (TLP
* is timer-driven, not triggered by RACK).
*/
if (tp->reord_seen && !(state->flag & FLAG_DSACK_TLP))
tp->rack.dsack_seen = 1;
state->flag |= FLAG_DSACKING_ACK; state->flag |= FLAG_DSACKING_ACK;
/* A spurious retransmission is delivered */ /* A spurious retransmission is delivered */

View File

@ -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. /* 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 * by srtt), since there is possibility that spurious retransmission was
* due to reordering delay longer than reo_wnd. * due to reordering delay longer than reo_wnd.
* *