jbn@FORD-WDL1.ARPA (01/10/86)
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.
JNchris@GYRE.UMD.EDU (Chris Torek) (01/14/86)
Speaking of 4.3BSD, I have heard that we were not the only beta test site to experience trouble talking to TOPS-20 machines. Does anyone have fixes for 4.3/TOPS-20 TCP/IP problems? (If so I sure hope you sent them on to Berkeley....) Chris
chris@GYRE.UMD.EDU (Chris Torek) (01/14/86)
My thanks to John Nagle for an amazingly fast response. Our telnet to TOPS-20 troubles have terminated. Three times thanks. Ta ta... Tchris
tcp-ip@ucbvax.UUCP (01/15/86)
We're running 4.3BSD too, and we also have problems with TOPS-20 systems. Could you please send me a copy of the note you got from John Nagle so we can fix it here too? Brian Kantor UCSD Office of Academic Computing Academic Network Operations Group UCSD B-028, La Jolla, CA 92093 (619) 452-6865 decvax\ brian@sdcsvax.ucsd.edu ihnp4 >--- sdcsvax --- brian ucbvax/ Kantor@Nosc
tcp-ip@ucbvax.UUCP (01/15/86)
Whoops! Cancel that; they just arrived in the mailing list! Thanks anyway! - Brian