[ih] TCP RTT Estimator

Greg Skinner gregskinner0 at icloud.com
Sat Apr 12 10:00:18 PDT 2025


I found some additional information that may shed some light on the issue of how much packet radio influenced the round trip time (RTT) and retransmission timeout (RTO) calculations.

There is a discussion of retransmission strategy in IEN 69 that makes a distinction between loss and congestion:

There are two problems that have the same symptoms - losing segments due to poor communications media, and delayed segments due to congestion.  These two problems call for distinctly different solutions.  In a lossy network, one would retransmit more frequently; in a congested network, one would retransmit less frequently.

Appendix E of IEN 69 gives some examples of specifying retransmission parameters.  One of those is for the SRI packet radio demo - 3 seconds with no backoff, initially.  (Subsequent retransmissions are a multiple of the initial value and two additional parameters that can be expressed as a fraction.)  Jim Mathis’ 1979 TCP implementation supports this feature.  It is also documented in IEN 150 as TENEX and TOPS20 JSYSs (system calls).

However, for some reason, this didn’t make it into RFC 793.  As previously noted, in IEN 177, a decision was made to use the RSRE algorithm in subsequent TCP specs.

I can understand why the RSRE algorithm was chosen, given what was understood about retransmission at the time.  Does anyone know why the alternate form was omitted?  Was there any more discussion about it prior to the publication of RFC 793?

--gregbo







More information about the Internet-history mailing list