• A
    [TCP]: continued: reno sacked_out count fix · 79320d7e
    Aki M Nyrhinen 提交于
    From: Aki M Nyrhinen <anyrhine@cs.helsinki.fi>
    
    IMHO the current fix to the problem (in_flight underflow in reno)
    is incorrect.  it treats the symptons but ignores the problem. the
    problem is timing out packets other than the head packet when we
    don't have sack. i try to explain (sorry if explaining the obvious).
    
    with sack, scanning the retransmit queue for timed out packets is
    fine because we know which packets in our retransmit queue have been
    acked by the receiver.
    
    without sack, we know only how many packets in our retransmit queue the
    receiver has acknowledged, but no idea which packets.
    
    think of a "typical" slow-start overshoot case, where for example
    every third packet in a window get lost because a router buffer gets
    full.
    
    with sack, we check for timeouts on those every third packet (as the
    rest have been sacked). the packet counting works out and if there
    is no reordering, we'll retransmit exactly the packets that were 
    lost.
    
    without sack, however, we check for timeout on every packet and end up
    retransmitting consecutive packets in the retransmit queue. in our
    slow-start example, 2/3 of those retransmissions are unnecessary. these
    unnecessary retransmissions eat the congestion window and evetually
    prevent fast recovery from continuing, if enough packets were lost.
    Signed-off-by: NDavid S. Miller <davem@davemloft.net>
    79320d7e
tcp_input.c 129.0 KB