[ih] TCP RTT Estimator

[Jack Haverty]

Instead of "formats and meanings", I should have said "formats and 
interactions".  The required sequences of messages, and the meanings of 
those sequences, were part of the Protocol and the Standard, captured in 
details such as the State Diagram included in RFC793 as part of the 
Specification.

At one of the early TCP meetings, Vint explained to all of us what 
"protocol" meant.  It was derived from the Greek word "protokolon" 
(sorry, can't remember how to make my computer type Greek 
characters...).  Vint explained that the protokolon was the section of 
ancient scrolls at the very beginning of any such "document".  It 
described what the entire scroll contained - something like a table of 
contents or Executive Summary or today perhaps the TLDR.   That was 
apparently useful in ancient times as a way to avoid having to unroll an 
entire scroll when searching for some particular piece of information.   
We recognized it of course as The Header.

Internal algorithms within host implementations, such as calculation of 
retransmission timers, were explicitly not specified as a Standard at 
that point, although we hoped they could be someday after more 
experience and experimentation.

It wasn't so much that we had to consult with somebody more 
knowledgeable.  Rather we had experienced the unpredictable behavior of 
paths that traversed multiple networks, and didn't think that anyone 
knew how to characterize or model such behavior so that suitable methods 
for error detection and correction could be chosen.

It's also important to remember that the Standardization effort that 
resulted in RFC793 et al was an unexpected surprise.  Vint gave a short 
introductory talk at the beginning of each meeting.  At one of them he 
announced that DoD had decided to establish TCP as a DoD Standard, which 
had all sorts of consequences beyond the research community of ARPA.   
For example, such a Standard would then influence all sorts of military 
procurements of hardware and software for anything that used computers 
and communications.

That announcement led to Jon getting the assignment to quickly create 
some required documentation, since Standards feed on paper rather than 
code.   That led to a lot of discussion as we tried to help Jon figure 
out what all the existing code actually did.   There was also a lot of 
whining about "It's not ready yet!" or "It's too soon!" and "but we 
don't know what the algorithm should be" (guilty!).

I recall having lots of discussions with Jon during that period. Jon was 
enamored with the notion that implementations "be conservative in what 
you do, be liberal in what you accept from others."  It's in the RFC793 
spec.

I argued against that, on the principle that incorrect behavior was 
indicative of a bug, either in the specification or implementation, and 
should be reported so that it could be fixed.   Otherwise it just left a 
"time bomb" in some deployed system that would probably explode at some 
very inopportune time in the future.

I lost.

There weren't a lot of TCP implementations at the time.  Bill Plummer at 
BBN did Tenex.  Jim Mathis at SRI did the LSI-11 version used in Packet 
Radio experiments.   I suspect those two were the first implementations, 
used in the early Packet Radio experiments. Before my time.

I used Jim's code (e.g., implementation of the state diagram) as the 
core for my PDP-11/40 Unix implementation, which was part of a Network 
Security project at BBN in 1977.  Dave Mills had his Fuzzballs.   Bob 
Braden did the IBM 360 implementation at UCLA. Dave Clark and Noel 
Chiappa handled Multics at MIT.  There may have been one or two more, 
but it was a small group.  In between meetings, lots of debate and 
discussion was carried out by email, much of which is probably lost 
now.   Jon collected it all and distilled it into words and Specifications.

He had some earlier experience with such a task.  The first "TCP 
Bakeoff" was held at ISI on a weekend (January 27, 1979 IIRC) when lots 
of offices and their terminals were unoccupied.  We all had TCP 
implementations that could talk to themselves, but none of them could 
talk to anyone else.   Checksums were the primary culprit. But after a 
while we all got our TCPs to talk to each other.   Jon then captured the 
exact checksumming algorithm that reflected what all our code actually 
did to compute and verify checksums.   We had achieved Consensus at the 
Bakeoff, after starting with just Running but incompatible Code.   Jon 
wrote it down.

(BTW, all the time I was interacting with Jon, he was at USC-ISI, in an 
office tower in Marina Del Rey.  I didn't know he had ever been at UCLA)

Out of all that, and a Herculean effort by Jon, documentation for the 
DoD Standard emerged.  It wasn't a pretty process.  RFC 793/791 specify 
Version 4, which grew out of previous versions we had named things like 
"2.5" or "2.5+", or "2.5+epsilon".  All such versions were documented 
purely in email exchanges.

There was even an early definition of Version 3, which was quickly found 
to be incorrect and replaced by Version 4.   Unfortunately, someone in 
the DoD contractor community (Ford Aerospace IIRC) had been contracted 
to implement Version 3.  They had their TCP working, but couldn't find 
anybody to talk to.   We had all gone on to Version 4.

Standards are messy.   Formal standards organizations usually debate for 
years, refining documents with new ideas and epiphanies.  Code comes 
later.   The TCP community believed in "rough consensus and running 
code" as the first step.   Experience and experimentation drove changes. 
   Documentation came later.

It was fun too!

Jack Haverty

-------------- 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/20250413/19f5030d/attachment.asc>