• Y
    tcp: add reordering timer in RACK loss detection · 57dde7f7
    Yuchung Cheng 提交于
    This patch makes RACK install a reordering timer when it suspects
    some packets might be lost, but wants to delay the decision
    a little bit to accomodate reordering.
    
    It does not create a new timer but instead repurposes the existing
    RTO timer, because both are meant to retransmit packets.
    Specifically it arms a timer ICSK_TIME_REO_TIMEOUT when
    the RACK timing check fails. The wait time is set to
    
      RACK.RTT + RACK.reo_wnd - (NOW - Packet.xmit_time) + fudge
    
    This translates to expecting a packet (Packet) should take
    (RACK.RTT + RACK.reo_wnd + fudge) to deliver after it was sent.
    
    When there are multiple packets that need a timer, we use one timer
    with the maximum timeout. Therefore the timer conservatively uses
    the maximum window to expire N packets by one timeout, instead of
    N timeouts to expire N packets sent at different times.
    
    The fudge factor is 2 jiffies to ensure when the timer fires, all
    the suspected packets would exceed the deadline and be marked lost
    by tcp_rack_detect_loss(). It has to be at least 1 jiffy because the
    clock may tick between calling icsk_reset_xmit_timer(timeout) and
    actually hang the timer. The next jiffy is to lower-bound the timeout
    to 2 jiffies when reo_wnd is < 1ms.
    
    When the reordering timer fires (tcp_rack_reo_timeout): If we aren't
    in Recovery we'll enter fast recovery and force fast retransmit.
    This is very similar to the early retransmit (RFC5827) except RACK
    is not constrained to only enter recovery for small outstanding
    flights.
    Signed-off-by: NYuchung Cheng <ycheng@google.com>
    Signed-off-by: NNeal Cardwell <ncardwell@google.com>
    Acked-by: NEric Dumazet <edumazet@google.com>
    Signed-off-by: NDavid S. Miller <davem@davemloft.net>
    57dde7f7
tcp_output.c 106.4 KB