[ih] NBS seminar on TCP/IP (was TCP RTT Estimator)

Fri Apr 25 11:11:39 PDT 2025

Since I'm listed as one of the speakers, I was probably there.  But I 
don't remember that particular seminar at all.  OTOH, during the early 
1980s I went from Boston to DC probably at least once a week, often to 
brief someone or some group on The Internet.  I do recall going to NBS, 
but can't remember exactly why.   It certainly could have been to give a 
talk on TCP for an hour to some audience.

That seminar was almost certainly part of DCA's efforts to support the 
standardization of TCP as a DoD Standard.  See, for example, RFC 761, 
published in January 1980 - with a seminar scheduled for November.

The adoption of TCP as a requirement for DoD procurements (not just 
research contracts) triggered a lot of big and small government 
contractors to get interested in exactly what this thing was that they 
were going to have to implement.  I recall even getting a phone call 
from a cousin, who worked at a big government shop, to get a little free 
education and advice.

So the NBS seminar was probably more of an educational venue for people 
new to TCP; it was likely not a place where nuances of retransmission 
algorithms would be of interest.

At the time, the ARPANET had been transferred from ARPA to DCA. Research 
results were progressing towards operation, part of the "technology 
transfer" impetus.  Joe Haughney was in charge of the ARPANET in DCA 
Code 535.  IIRC, there's a lot more detail in the podcasts which Joe's 
daughter Christine put together recently - see 
https://www.inc.com/podcasts/computer-freaks

Jack Haverty

On 4/25/25 09:47, Greg Skinner wrote:
> On Apr 13, 2025, at 1:40 PM, Jack Haverty via Internet-history<internet-history at elists.isoc.org>  wrote:
>> 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
> Do any of you remember a seminar in November 1980 at NBS where there were several presentations about the TCP/IP protocols that were being developed at that time?  [1] It seems like this seminar would have been an ideal time for concerns (such as what we have been discussing about retransmissions) to be discussed.
>
> --gregbo
>
> [1]https://www.rfc-editor.org/rfc/museum/ddn-news/ddn-news.n3.1
>

-------------- 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/20250425/ba24e3da/attachment-0001.asc>