[ih] History from 1960s to 2025 (ARPANET to TCP)

[John Day]

Everything Alex says is true. I would even further to say that debate between new networking crowd and the PTTs was far more intense than Alex describes. While a smaller group doing the debating, it made the IPng debate look like a walk in the park. For the PTTs, virtual circuit (VC) was not only how they had always done phone networks, but it was also the core of their business model. Datagrams were a threat to their existence. They had big plans for putting Value-Added Services ‘in the network’ where it would be within their monopoly. Today rather saying ‘in the network’ one would say ‘in the cloud.’ The existence of a Transport Layer meant that all computing was at the edge of the network (outside their monopoly) and all the network did was move bits, a commodity business, which is hard work and small margins. Minitel (Videotex) was a good example of what the PTTs had in mind. Of course, the PTTs could do services outside their monopoly, but they really didn’t want the competition and they fought tooth-and-nail to make their view dominant.  This battle was primarily what distorted the OSI work.

However while all of this is true, it isn’t the key advantage of datagrams (DG) over VC. It was all about dynamic resource allocation. 

In 1968, Peter Denning had shown that pooled buffers require 3 or more orders of magnitude less buffer space than static allocation of buffers. (This appears to have been re-discovered at least 3 times since then, an indication of how unscientific networking is.) The practice at the time was that VC nailed everything down and tried to make it deterministic, i.e., static allocation. This demanded either more memory (expensive then) or fewer virtual-circuits of less capacity. In the early days, one real advantage of VC was that it used channel-ids rather than addresses. Channel-ids were much shorter and were swapped at each hop. (This is what made VC so brittle. The network couldn’t recover from failures with involving the end(s), all of the necessary state to recover was at the ends.) The smaller channel-ids were important because Max Packet Size was typically 256 or 512 bytes. 

Of course, one could implement VC with pooled buffers in the routers and occasionally that was done. However, even with pooled buffers with VCs, allocating VCs could lead to something analogous to the issues with contiguous memory allocation. (Available capacity but not where it was needed.)  Datagrams could be used to avoid this problem. However, because the US adopted a purest-position (some would say religious position) with respect to datagrams, it was never pursued.

Take care,
John

> On Jan 5, 2026, at 20:09, Alexander McKenzie via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> There was a huge debate in the period 1972-1978 about whether the
> communications subnet should provide "virtual circuit" or "datagram"
> service.  The flip side, of course is whether significant amounts of
> software to manage communications issues should or should not be in the
> user computers at the "ends" of a communication.Much of the debate was
> philosophical in nature, and much of the debate was about whether one
> wanted to increase or decrease the monopoly position of the communications
> carriers.  But a lot of the debate was also engineering, and I think it is
> fair to say that the engineering tradeoffs changed with the cost and
> capabilities of the computers at the ends of a communication.  I think good
> documents reflecting the engineering choices available in the 1975
> timeframe are
> 
> RFC 635 - An Assessment of ARPANET Protocols by Vint Cerf, arguing for
> datagram networks
>      https://datatracker.ietf.org/doc/html/rfc635
> 
> Issues in Packet Switching Network Design by 6 BBN authors (including me)
> arguing for virtual circuit networks
>      https://dl.acm.org/doi/pdf/10.1145/1499949.1499981
> 
> Cheers,
> Alex McKenzie
> 
> On Mon, Jan 5, 2026 at 7:54 PM Alex McKenzie <amckenzie3 at yahoo.com> wrote:
> 
>> 
>> 
>> ----- Forwarded Message -----
>> *From:* Jack Haverty via Internet-history <
>> internet-history at elists.isoc.org>
>> *To:* "internet-history at elists.isoc.org" <internet-history at elists.isoc.org
>>> 
>> *Sent:* Saturday, January 3, 2026 at 03:42:06 PM EST
>> *Subject:* Re: [ih] History from 1960s to 2025 (ARPANET to TCP)
>> 
>> On 1/1/26 01:26, Lars Brinkhoff wrote:
>>> I'd like to say one thing we have observed running this
>>> ARPANET reconstruction is how resilient and self organizing the IMP
>>> subnet[*] is.
>> 
>> I totally agree with Lars.   When I did a "deep dive" in 2012 into parts
>> of the 1973 IMP code, I was impressed at how it did its functions,
>> especially given the severe constraints of the computer hardware of the
>> era.
>> 
>> But thinking about the transition from ARPANET to Internet brought up
>> some questions.....
>> 
>> The ARPANET nurtured the Internet and eventually was decommissioned.
>> Reading the original ARPANET proposal by BBN, there were a number of
>> arguments made about the use of an external computer (the IMP) instead
>> of adding the required network functions to the "host" computers.  For
>> example, owners of those expensive host computers didn't like the idea
>> of added overhead from network operations consuming their CPU cycles.
>> Another argument was that maintenance and evolution of the network
>> mechanisms would be easier with a uniform set of IMPs, operated and
>> maintained by a single organization.
>> 
>> When TCP appeared, its architecture placed much of the work of network
>> functions on the host computers, which were now responsible for the
>> mechanisms to counteract errors during network transits. Checksumming,
>> retransmissions, re-ordering, and related functions previously performed
>> in the IMPs were now performed in the host computers.    The new
>> architecture pushed the "ends" of the network machinery closer to the
>> users, which better conformed to the "end-to-end" principle which was
>> the popular goal at the time.  But the new architecture also removed the
>> clean boundary between the network and the hosts (the "1822
>> specification"), as well as the possibility of having "the network"
>> operated and managed by a single organization.
>> 
>> Some TCP implementers in the 1980s chose to use a "front end" approach,
>> placing all of the TCP mechanisms in a separate processor somehow
>> attached to their main computer.   AFAIK, such implementations have
>> mostly disappeared.
>> 
>> I was at BBN from 1977 to 1990 in the same group that had built the
>> ARPANET.   During that time, the internal mechanisms of the IMP "subnet"
>> changed significantly.   I remember the introduction of "PSN7" and the
>> lengthy and elaborate process (analysis, simulations, tests, etc.) to
>> assure that the transition went well (it did, PSN6 was replaced by
>> PSN7).  More info on the process is in DTIC.   One such report is
>> https://apps.dtic.mil/sti/pdfs/ADA121350.pdf
>> 
>> In the new Internet architecture today, TCPV4 is still in use, even
>> though TCPV6 was "on the shelf" decades ago.   Has the delay been a
>> result of the change in architecture?  Are we missing the "process" for
>> evolution of the networking mechanisms?  Is such a process even possible
>> given the size and breadth of the Internet?
>> 
>> So, my basic question for History is "Why did the architecture change?"
>> Were the arguments for a separate network switch (e.g., an IMP) no
>> longer applicable?    Did the technology explosion during the 70s have
>> some effect?  What was the reasoning behind the decision to move the
>> "virtual circuit" mechanisms from the network (IMPs) to the hosts?
>> 
>> 
>> /Jack Haverty
>> --
>> 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
>> 
> -- 
> 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