[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.036 / U:5.984 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site