Re: TCP timer bug in 2.0.x

Eric.Schenk@dna.lth.se
Sat, 31 May 1997 09:48:50 +0200

Matthew Ghio <ghio@temp0086.myriad.ml.org> 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
retransmitted.

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: http://www.dna.lth.se/~erics
Dept. of Comp. Sci., Lund University          email: Eric.Schenk@dna.lth.se
Box 118, S-221 00 LUND, Sweden   fax: +46-46 13 10 21  ph: +46-46 222 96 38