Re: retransmission timers in TCP

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.


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