• Eric Dumazet's avatar
    tcp: defer SACK compression after DupThresh · 86de5921
    Eric Dumazet authored
    Jean-Louis reported a TCP regression and bisected to recent SACK
    compression.
    
    After a loss episode (receiver not able to keep up and dropping
    packets because its backlog is full), linux TCP stack is sending
    a single SACK (DUPACK).
    
    Sender waits a full RTO timer before recovering losses.
    
    While RFC 6675 says in section 5, "Algorithm Details",
    
       (2) If DupAcks < DupThresh but IsLost (HighACK + 1) returns true --
           indicating at least three segments have arrived above the current
           cumulative acknowledgment point, which is taken to indicate loss
           -- go to step (4).
    ...
       (4) Invoke fast retransmit and enter loss recovery as follows:
    
    there are old TCP stacks not implementing this strategy, and
    still counting the dupacks before starting fast retransmit.
    
    While these stacks probably perform poorly when receivers implement
    LRO/GRO, we should be a little more gentle to them.
    
    This patch makes sure we do not enable SACK compression unless
    3 dupacks have been sent since last rcv_nxt update.
    
    Ideally we should even rearm the timer to send one or two
    more DUPACK if no more packets are coming, but that will
    be work aiming for linux-4.21.
    
    Many thanks to Jean-Louis for bisecting the issue, providing
    packet captures and testing this patch.
    
    Fixes: 5d9f4262 ("tcp: add SACK compression")
    Reported-by: default avatarJean-Louis Dupond <jean-louis@dupond.be>
    Tested-by: default avatarJean-Louis Dupond <jean-louis@dupond.be>
    Signed-off-by: default avatarEric Dumazet <edumazet@google.com>
    Acked-by: default avatarNeal Cardwell <ncardwell@google.com>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    86de5921
tcp_input.c 186 KB