Messages in this thread | | | From | Eric.Schenk@dna ... | Subject | Re: TCP timer bug in 2.0.x | Date | 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
| |