• Yuchung Cheng's avatar
    tcp: remove bad timeout logic in fast recovery · 3e59cb0d
    Yuchung Cheng authored
    tcp_timeout_skb() was intended to trigger fast recovery on timeout,
    unfortunately in reality it often causes spurious retransmission
    storms during fast recovery. The particular sign is a fast retransmit
    over the highest sacked sequence (SND.FACK).
    
    Currently the RTO timer re-arming (as in RFC6298) offers a nice cushion
    to avoid spurious timeout: when SND.UNA advances the sender re-arms
    RTO and extends the timeout by icsk_rto. The sender does not offset
    the time elapsed since the packet at SND.UNA was sent.
    
    But if the next (DUP)ACK arrives later than ~RTTVAR and triggers
    tcp_fastretrans_alert(), then tcp_timeout_skb() will mark any packet
    sent before the icsk_rto interval lost, including one that's above the
    highest sacked sequence. Most likely a large part of scorebard will be
    marked.
    
    If most packets are not lost then the subsequent DUPACKs with new SACK
    blocks will cause the sender to continue to retransmit packets beyond
    SND.FACK spuriously. Even if only one packet is lost the sender may
    falsely retransmit almost the entire window.
    
    The situation becomes common in the world of bufferbloat: the RTT
    continues to grow as the queue builds up but RTTVAR remains small and
    close to the minimum 200ms. If a data packet is lost and the DUPACK
    triggered by the next data packet is slightly delayed, then a spurious
    retransmission storm forms.
    
    As the original comment on tcp_timeout_skb() suggests: the usefulness
    of this feature is questionable. It also wastes cycles walking the
    sack scoreboard and is actually harmful because of false recovery.
    
    It's time to remove this.
    Signed-off-by: default avatarYuchung Cheng <ycheng@google.com>
    Acked-by: default avatarEric Dumazet <edumazet@google.com>
    Acked-by: default avatarNeal Cardwell <ncardwell@google.com>
    Acked-by: default avatarNandita Dukkipati <nanditad@google.com>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    3e59cb0d
tcp_input.c 163 KB