[ih] TCP RTT Estimator

[Jack Haverty]

The 1980s era of The Internet was explicitly a time of research and the 
"Internet Experiment".    We tried to reflect that in the documents of 
the day, such as RFC793.

The general principle was that the "on the wire" formats and meanings 
were standardized, so that any implementation of TCP could communicate 
with any other implementation.  Everything else was at best Recommendations.

However, there were a lot of unanswered questions, such as the best way 
to deal with network errors such as dropped, duplicated, or mangled 
datagrams - such as discussed in IEN69.

To enable research into different techniques, the specific algorithms 
for TCP functions such as retransmission timers and strategies were 
explicitly *not* standardized.    That encouraged experimentation with 
different kinds of network environments and different ideas about how to 
cope with errors.   It also permitted implementations of TCP with 
different goals.  An implementer might pursue algorithms which minimized 
the load on their computer system.  Or load on the network.   Or 
rapidity of implementation. Or suitability for the specific user 
environment involved.  Or ...

No one in 1981 had any significant experience with real-world TCP 
networks and their behavior under heavy loads.   The ARPANET was the 
basic wide-area network in use as the substrate for The Internet, and 
the ARPANET provided only a reliable byte-stream service that made 
greatly simplified TCP's task.

IEN 177 says that the RSRE algorithm is the "current best procedure" and 
"will be included in the next ... specification".  I remember talking 
with Jon and others about this.  My recollection is that such an 
algorithm might be included as a "best practice" recommendation, not as 
a mandatory part of the standard.  In 1981 we simply didn't know enough 
to nail down an algorithm and there were lots of other outstanding 
unresolved issues that might be related (such as Type Of Service, Policy 
Routing, etc.).

In 1981, The Internet was still very much an Experiment, but being 
pulled forward by its adoption as a DoD Standard, and later to be 
rocketed forward by its adoption in non-military networking.   I think 
many of those research questions were never answered.  I recall we even 
at one point we even opined that The Internet would be fine as long as 
we kept enough capacity in the circuits and switches to avoid overloads, 
while the research continued, seeking the "right" answers.

Jack Haverty


On 4/12/25 10:00, Greg Skinner via Internet-history wrote:
> 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
>
>
>
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20250412/e3105396/attachment.asc>