Skip to content
  • Yuchung Cheng's avatar
    tcp: support DUPACK threshold in RACK · 20b654df
    Yuchung Cheng authored
    
    
    This patch adds support for the classic DUPACK threshold rule
    (#DupThresh) in RACK.
    
    When the number of packets SACKed is greater or equal to the
    threshold, RACK sets the reordering window to zero which would
    immediately mark all the unsacked packets below the highest SACKed
    sequence lost. Since this approach is known to not work well with
    reordering, RACK only uses it if no reordering has been observed.
    
    The DUPACK threshold rule is a particularly useful extension to the
    fast recoveries triggered by RACK reordering timer. For example
    data-center transfers where the RTT is much smaller than a timer
    tick, or high RTT path where the default RTT/4 may take too long.
    
    Note that this patch differs slightly from RFC6675. RFC6675
    considers a packet lost when at least #DupThresh higher-sequence
    packets are SACKed.
    
    With RACK, for connections that have seen reordering, RACK
    continues to use a dynamically-adaptive time-based reordering
    window to detect losses. But for connections on which we have not
    yet seen reordering, this patch considers a packet lost when at
    least one higher sequence packet is SACKed and the total number
    of SACKed packets is at least DupThresh. For example, suppose a
    connection has not seen reordering, and sends 10 packets, and
    packets 3, 5, 7 are SACKed. RFC6675 considers packets 1 and 2
    lost. RACK considers packets 1, 2, 4, 6 lost.
    
    There is some small risk of spurious retransmits here due to
    reordering. However, this is mostly limited to the first flight of
    a connection on which the sender receives SACKs from reordering.
    And RFC 6675 and FACK loss detection have a similar risk on the
    first flight with reordering (it's just that the risk of spurious
    retransmits from reordering was slightly narrower for those older
    algorithms due to the margin of 3*MSS).
    
    Also the minimum reordering window is reduced from 1 msec to 0
    to recover quicker on short RTT transfers. Therefore RACK is more
    aggressive in marking packets lost during recovery to reduce the
    reordering window timeouts.
    
    Signed-off-by: default avatarYuchung Cheng <ycheng@google.com>
    Signed-off-by: default avatarNeal Cardwell <ncardwell@google.com>
    Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
    Reviewed-by: default avatarSoheil Hassas Yeganeh <soheil@google.com>
    Reviewed-by: default avatarPriyaranjan Jha <priyarjha@google.com>
    Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
    20b654df