# Re: retransmission timers in TCP

jbn@FORD-WDL1
9-Jan-86 18:06:52-PST

I had to go into 4.3BSD recently and fix a few bugs here, so I'll document
how 4.3BSD does it, for the benefit of the community.

John Nagle

The algorithm in 4.3BSD works as follows:

1. Round trip times are computed for one packet at a time.
Only packets containing data and which are not being retransmitted
contribute to the round-trip time calculation. The timer starts
when a data packet is transmitted and no other packet is being
timed, and stops when an ACK covers the sequence number of the
packet being timed.

2. There is a smoothed round-trip timer. Its value is initially
0 and is a smoothed running average of past round-trip times.
It is updated at the completion of each successful timing, as
described above.
The formula is

const = 0.1
srtt = srtt * (1-const) + lastrtt * const;

This is actually computed in floating point.
On the first round-trip, srtt is simply set to lastrtt.
The result is then forced into the range 1 to 30 seconds.
[It's possible to use the 0 value if there is no good round-trip
before the first retransmit. This is a bug; see net.bugs.4bsd
for a fix.]

3. The initial retransmit interval is 2*srtt. A backoff algorithm
then applies. The standard algorithm is table-driven, and
has a table of constants beginning 1.0, 1.2, etc. These
are applied using the number of the retransmit as an index as
multipliers to srtt. There is an alternate algorithm available
by patching a flag, which uses srtt*(2^retransmitnumber) as the
retransmit interval. [There's a bug here; there is a multiply
by tcp-beta (=2.0) missing in one spot, and the time between
the first and second retransmit is shorter than between the
original and the first. Again, see net.bugs.4bsd for a fix.]
We prefer the alternate algorithm, which backs off faster.

Without the fixes, by the way, things are not good when the round-trip
time on the net actually exceeds one second.

JN

This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:35:39 GMT