[ih] Internet-history Digest, Vol 69, Issue 11

[Jack Haverty]

Gemini didn't catch some Internet-related aspects of History.

AUTODIN encountered the ARPANET in the mid 1970s.  There was a program 
called the "Military Message Experiment" (MME), intended to evaluate the 
possibility of providing AUTODIN functionality but using the ARPANET.  
It resulted in an actual experiment using military personnel.  The 
after-action report is available at 
https://archive.org/stream/DTIC_ADA155585/DTIC_ADA155585_djvu.txt

I was in Lick's group at MIT during that time, and we were implementing 
electronic mail, so we got involved in the MME.

There were quite a few functions present in AUTODIN that weren't of much 
interest to the ARPANET research community.  AUTODIN messages had 
security markings.   They also had various levels of "priority", such as 
ROUTINE, FLASH, FLASH OVERRIDE, et al, which dictated how messages 
should be handled.  They had notions of "workflow", in which various 
people in the command chain had to approve ("chop") a message before it 
could actually be transmitted.

Most of such features weren't available in the ARPANET email systems of 
the era, and there was a strong desire in the community to keep email 
things simple.  With Lick's oversight and Al Vezza's pressure, we tried 
to get appropriate primitives for AUTODIN added into the email protocols 
but mostly failed to reach "rough consensus and running code."

One of the artifacts which you can still see today (e.g., in this 
message) is the "Message-ID:" field which appears if your system lets 
you view the full header of today's emails.  I lobbied hard to get that 
included in the ARPANET mail header specs, so that it could be used for 
functions such as tracking messages as they passed through an approval 
chain, linking together replies, and other such functionality.  We 
viewed the message header as a poor place to keep all that metadata.

AUTODIN was due for replacement in the 1980s by AUTODIN II, with a 
typical big government contractor expected to be awarded the contract.  
After much outside pressure from ARPA and others, BBN reluctantly 
submitted a proposal, to use the ARPANET technology as the replacement 
for AUTODIN.

We submitted what was probably the largest proposal BBN ever did. We 
were surprised to receive an acknowledgement from the government 
congratulating us for the brevity of our proposal.  All the other bids 
were much more verbose, with lots of foldout color diagrams and such stuff.

Our surprise turned to shock when we learned that we had won the 
contract.   BBN had recently reorganized, and the contract landed in our 
new division.   Since I was the one with the more "operational" 
interest, I became the first program manager for the new DDN contract.  
That seemed like a full time job, involving lots of paper pushing which 
wasn't very interesting.  So we hired someone from a big government 
contractor to run the contract.  He quickly observed that it was much 
more than a full time job, and created a DDN Program Office at BBN, with 
lots of staff to handle all of the contract paperwork, scheduling, 
reports, and such stuff.  Whew, I escaped that one.

Autodin II had become the Defense Data Network, and was basically a 
larger clone of the proven ARPANET technology.

As part of a "System Engineering" task, we helped get various 
applications running on the DDN.  One I recall was a "mail gateway" for 
the US Army in Europe, used for communicating between Army supply 
officers and vendors out in the public world in Europe.  That was how 
things like toilet paper were purchased for the various military bases.

That "gateway" was extremely low tech.  A soldier was stationed at a 
desk, with two terminals.  One terminal was on the "inside" mail system, 
where security was highly important.  The other terminal was on the 
"public" network (X.25 probably), where all the vendors were 
accessible.  The soldier would retype messages to pass them "through" 
the gateway.

The Defense Message System (DMS) apparently happened after I had moved 
into the networked database world in the 1990s.   So I don't know much 
about DMS.  I wonder if the security, priority, and other issues 
surfaced in the 1970s Experiment were solved in the DMS deployment.

In any event, there was a lot of AUTODIN DNA in the Internet History.

Jack Haverty

On 8/16/25 14:25, vinton cerf via Internet-history wrote:
> one might also check the timeline for AUTODIN
>
> from gemini:
>
> The *Automatic Digital Network (AUTODIN)* was built between 1959 and 1963,
> with its initial operational phase beginning in 1962. It was officially
> declared fully operational in February 1963.
>
> The system was originally designed as the "Combat Logistics Network"
> (ComLogNet) to handle the U.S. Air Force's logistics challenges. In 1962,
> the U.S. Department of Defense realized its broader value and transferred
> it to the Defense Communications Agency, renaming it AUTODIN.
>
> The initial network consisted of five switching centers in the United
> States, with a global expansion beginning in 1966. AUTODIN remained a
> primary communication system for the DoD until it was replaced by the
> Defense Message System (DMS) in the late 1990s and early 2000s.
>
> On Sat, Aug 16, 2025 at 5:18 PM John Shoch via Internet-history <
> internet-history at elists.isoc.org> wrote:
>
>> My friends at the Computer History Museum always warn me about declaring
>> "firsts":
>> a.  you better get the facts absolutely correct, and
>> b.  you better be fanatically precise in defining the terms (every noun,
>> every adjective, etc.) -- and you better include the definitions.
>>
>> The UCLA statement which started this exchange lacks both -- thus, almost
>> by definition, it is ambiguous and imprecise (and thus probably wrong).
>>
>> Efforts at NPL and Sage are certainly worth looking at.
>>
>> In addition, there was earlier work at SDC -- apparently in 1963 w/SRI, and
>> ca. 1966 with MIT Lincoln Labs.  I will make no judgement about any
>> "firsts" but let me bring to everyone's attention a couple of items:
>>
>> --There is an interesting and comprehensive historical look at this Q-32
>> work in a paper by David Hemmendinger, published in 2016:
>> "Two Early Interactive Computer Network Experiments." 
>> https://www.computer.org/csdl/magazine/an/2016/03/man2016030012/13rRUwciPgt 
>> You can also access it at: 
>> https://cs.union.edu/~hemmendd/History/network6.pdf --In that paper 
>> he discusses an experiment in 1963 between SRI and SDC. At that time 
>> Lick had taken over ARPA/IPTO, and ARPA had taken over the Sage Q-32 
>> prototype that had been built for Sage at SDC. Lick wanted SRI to 
>> connect to the Q-32. Doug Engelbart described the work at the History 
>> of Workstations conference in 1986 [I spoke at the conference, and 
>> heard Doug's talk, but 40 years later I do not remember these 
>> comments]: https://dl.acm.org/doi/pdf/10.1145/61975.66918 "Lick moved very swiftly. By early 1963 we had a funded project. But,
>> whereas I had proposed using a local computer and building an interactive
>> workstation, Lick asked us instead to connect a display to the System
>> Development Corporation's (SDC's) AN/FSQ32 computer, on site in Santa
>> Monica, to do our experimenting under the Q32's projected new time-sharing
>> system. (Converting the Q32 to be a timeshared machine was SDC's IPTO
>> project.) Later that year, our project was modified to include an online
>> data link from Menlo Park to Santa Monica, with a CDC 160A minicomputer at
>> our end for a communication manager, supporting our small-display
>> workstation."
>>
>> --Hemmendinger also discusses the more well-known work several years later,
>> ca. 1966, by Tom Marill (at CCA) and Larry Roberts (at MIT) to connect the
>> TX-2 to the Q-32 machine at SDC.
>>
>> --There seems to have been a CCA Technical Report in mid-1966, but I have
>> never seen it;  Hemmendinger cites it as:
>> T. Marill, "A Cooperative Network of Time-Sharing Computers: Preliminary
>> Study," Technical Report No. 11, Computer Corporation of America,
>> Cambridge, Mass. (1966).
>> The preliminary study is also cited in a bibliography about the Arpanet:
>> https://apps.dtic.mil/sti/tr/pdf/ADA026900.pdf
>> Marill, T. A cooperative network of time-sharing computers: preliminary
>> study. Cambridge, Ma., Computer Corporation of America, I Jun 66. 53 p.
>> CCA-TR1-1 NIC 06458.  [Is this an SRI NIC identifier?]
>>
>> --The Preliminary Report may have been a predecessor or an early draft or a
>> pre-print of a paper published later that year, to which Larry Roberts is
>> added as a co-author:
>> Thomas Marill and Lawrence G. Roberts, “Toward a cooperative network of
>> time-shared computers” in Proceedings of the AFIPS Fall Joint Computer
>> Conference, pp. 425-431, ACM, New York, NY (November, 1966).
>> https://dl.acm.org/doi/10.1145/1464291.1464336
>>
>> --Some interesting highlights from the paper:
>> --They talk in passing about shipping programs from one machine to another,
>> but then focus only on providing remote terminal access -- from a terminal
>> on one computer, through a "network" to a program running on another
>> computer.
>> --An "elementary" model merely routes characters from a user's terminal
>> through to the local machine, and then out another terminal link to the
>> distant machine.  This requires no modifications at either end, but runs at
>> terminal speeds.
>> --They then expand the model:  "Thus, a possible alternative technique for
>> achieving increased data-rates without greatly increasing the burden on the
>> monitor would be to use high-rate data-only links, supplementing these by
>> low-rate command-plus-data channels over which communication to the remote
>> monitor could take place."  But this would require changes to the OS or
>> monitor.
>> --"The first step in that direction is the establishment of a message
>> protocol, by which we mean a uniform agreed-upon manner of exchanging
>> messages between two computers in the network."
>> --These are point-to-point messages, but can provide error control:  "The
>> primary reasons for considering the establishment of a message protocol are
>> the following: ... By formatting transmissions into messages, and including
>> a check-sum with each message, transmission errors can frequently be
>> detected. If detected, the messages can automatically be retransmitted in
>> accordance with the protocol."
>> --But this was (at the time the paper was written) still an experimental
>> work-in-progress:  "As will be seen below, work is proceeding on an
>> experimental network between the TX-2 computer at Lincoln Laboratory and
>> the Q-32 computer at System Development Corporation."
>> --"As soon as possible, a series of demonstrations and experiments will be
>> performed using the experimental network. The experience gained will be
>> reported at the conference."  [Was anyone at the 1966 Fall Joint?]
>>
>> For more background on these early "networking" efforts I commend to you
>> the Hemmendinger paper from 2016.
>>
>> John Shoch
>> --
>> Internet-history mailing list
>> Internet-history at elists.isoc.org
>> https://elists.isoc.org/mailman/listinfo/internet-history
>> -
>> Unsubscribe:
>> https://app.smartsheet.com/b/form/9b6ef0621638436ab0a9b23cb0668b0b?The%20list%20to%20be%20unsubscribed%20from=Internet-history
>>

-------------- 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/20250816/55b97b6a/attachment-0001.asc>