[lkml]   [1997]   [May]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: TCP timer bug in 2.0.x

    Matthew Ghio <> writes:
    >The problem is in the retransmit timer backoff. The timer is set based
    >on the roundtrip time when a packet is transmitted/acked. When a sent
    >packet is not acked, it will retransmit, doubling the time between each
    >retransmit, up to a maximum of 120 seconds.
    >The bug is that when a retransmitted packet gets acked, the timer doesn't
    >get reset. So if the timer was at 120 seconds, then we'll have to wait a
    >whole 120 seconds before sending the next packet, no matter how quickly
    >the packet was acked.

    No! This is NOT a bug. It is known as Karn's rule, and it is absolutely
    requried by RFC 1122.
    The problem is that when you get an ACK for a retransmitted packet you
    have no information about the actual RTT of that packet, since the ack
    could be for any one of the multiply transmitted packets.
    If you start trying to reduce the RTO and the retransmission time really
    did get longer, then you will get yourself into a situation where
    you can never make a valid RTT measure again, and every packet will be

    The way to fix this is to use RFC1323 timestamps, which give you valid
    RTT measures on all packets, even retransmitted packets.
    Unfortunately, both ends must talk RFC1323 to allow this.

    BTW, you have misread the code a bit. sk->send_head != NULL means
    that there is something in the retransmission queue, not that there
    is something in the transmit queue. The tiemr gets reset by the first
    good packet send/ack after a retransmission episode.

    Eric Schenk www:
    Dept. of Comp. Sci., Lund University email:
    Box 118, S-221 00 LUND, Sweden fax: +46-46 13 10 21 ph: +46-46 222 96 38

     \ /
      Last update: 2005-03-22 13:39    [W:0.018 / U:230.208 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site