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

[Jack Haverty]

The managers in the military hierarchy mostly had to trust their 
technical staff, who were either within the military or one of their 
contractors, for technical issues.    DCA was responsible for operating 
communications infrastructure and changing it as new technologies became 
viable.   ARPA was responsible for supplying a stream of new 
technologies.   Together they ran the "pipeline" to move ideas from 
research to operational systems.

DCA had a "lab" arm, called the Defense Communications Engineering 
Center (DCEC) where technologies, such as TCP/IP, were tested and judged 
to be, or not yet be, appropriate, for general deployment throughout 
DoD.  Ed Cain was in charge of a lab for evaluating TCP/IP.   He was 
also a member of Vint's ICCB.  So DCA was aware of the outstanding issues.

But other issues are usually surfaced as any new technology goes into an 
operational environment. Getting "in the field" experience as early as 
possible provides a way to shake out those operational issues, and feed 
them back into the technical evolution.

SATNET had been operated by ARPA for a while, but MATNET, a clone of 
SATNET, was also being evaluated by a Navy lab, run by Frank Deckelman, 
with its nodes on ships such as the USS Carl Vinson. Similarly, Packet 
Radio networks were in use at places like Fort Bragg and elsewhere to 
get similar operational experience in the Army.  All such testbeds could 
generate feedback of issues important to military needs.

TCP/IP was ready enough to go "into the field", but was known to be not 
yet "done".  There was a list of outstanding issues that the ICCB kept, 
of things that needed to be addressed but were not yet resolved by us 
"techies".  Many of the issues involved routing, as well as how to best 
support a mix of traffic types with different needs for "type of 
service".  These were all things that us techies simply didn't know how 
to do yet.

While the then-current version of TCP/IP (V4) was deployed and 
operational experience gathered, the outstanding issues could be 
addressed by the ongoing Research Community, to discuss, debate, test, 
and choose appropriate mechanisms for each of the pending issues, and 
incorporate them in the next release of TCP/IP Specifications.

Meanwhile, the limitations of the current release were understood and 
avoided.   IP Fragmentation is one example; we knew it didn't work very 
well, but the "Don't Fragment" bit was added to provide a way to avoid it.

So, important "features" weren't "omitted".  They were targetted to be 
solved and incorporated in a future release, once the technical experts 
reached "rough consensus and running code".

The Defense Research Internet (DRI) was supposed to be a new high-speed 
network to provide a foundation for continuing such research, such as 
the "policy routing" and "type of service" requirements that were on the 
to-do list.

I don't myself know much about the DRI though, or what role it might 
have played in creating the "next release" of TCP/IP  (V6?).  Or if DRI 
ever got built at all.  Perhaps someone else does.

I think the whole Internet world changed quite a bit when NSF got 
involved, and when the commercial world chose TCP/IP as their target 
architecture.  The military became just one of a global list of 
customers.   NSF instigated the creation of a bunch of regional 
networks, with a mandate and deadline to become self-sufficient, and 
public ISPs started to spread as a result - leading to The Internet we 
know today.

Jack Haverty

On 4/25/25 15:17, Greg Skinner wrote:
> Just to clarify, I have listened to the computer-freaks podcasts about 
> Joe Haughney.  He (and his successors) had access to information about 
> the TCP/IP implementations that were discussed at the meetings 
> summarized in the IEN notes.  So in theory, there was a means for them 
> to raise concerns about retransmission algorithms, or collect 
> information that could be passed on to people who had those concerns. 
>  Furthermore, they were getting feedback on the tcp-ip list about 
> implementation concerns, in general. [1]
>
> So far, based on what I’ve read, I don’t see any evidence that the 
> concerns of the military, or users of lossy networks, were given 
> insufficient consideration.  I see that there were features left out 
> of RFC 793 that could have mitigated some retransmission issues that 
> impacted performance.  But there were DCA people involved who, in 
> theory, could have questioned the wisdom of omitting those features, 
> at least.
>
> --gregbo
>
> [1] https://www.columbia.edu/~rh120/other/tcpdigest_paper.txt
>
>
>> On Apr 25, 2025, at 11:11 AM, Jack Haverty <jack at 3kitty.org> wrote:
>>
>> 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
>

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