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

[Craig Partridge]

Hi Jack:

I'm not going to try to answer the larger architectural question of why did
things move into the host.   I wasn't there when the architectural
decisions were made.

I do want to correct some of your discussion of TCP implementation (while
recognizing, you were there for some early stuff I was not -- as I recall,
I ended working on TCP implementations descended from yours).

The TCP front end computer implementation is now ubiquitous and the front
end computer is called your Ethernet/WiFi chip (aka the NIC).  If you look
at a modern TCP implementation, it has hooks to hand off functions to the
network card.  This effort to make smart NIC chips goes way back and has a
complicated history, because it took a while to figure out how to do it
(and I dropped out of that evolution c. 2000, so some of what follows may
not quite be right).

In the 1980s, the general view was that TCP was a complex, host compute
hogging, protocol. About 1989 (and big credit to Van Jacobson here), we
began to realize that was wrong, but the TCP offload movement had already
started and, alas, started on the old assumption.  So the TCP offload folks
tried to create "lightweight" protocols to talk with the NIC card, only to
discover those lightweight protocols were as expensive to implement as TCP
-- indeed, the smart NIC cards were often slower.  (As I recall, there was
a dumb NIC card movement called WITLESS in response).

Where did things go wrong?  Well it turned out that, while some TCP control
code could be compute intensive, the main performance bottleneck in most
cases was actually the cost of copying data from the NIC, through the OS,
to the application's memory.  The checksum is, in fact, free (you piggyback
it on a copy at no cost) and, with a bit of predictive code, most TCP
control software becomes (literally) a few lines of code per TCP segment.

As a result it turned out you didn't want the NIC to offload all of TCP.
What you wanted it to do is have a smart memory interface (and a TCP
checksum in its data path) that allowed it to transfer data straight from
the NIC to the application's memory (and, perhaps, TCP retransmission
smarts) and an as simple-as-possible API to minimize the cost of managing
the NIC.  I believe similar evolutions were happening in disk storage
controllers for similar reasons.

Thanks!

Craig

On Sat, Jan 3, 2026 at 1:42 PM Jack Haverty via Internet-history <
internet-history at elists.isoc.org> wrote:

> 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
>


-- 
*****
Craig Partridge's email account for professional society activities and
mailing lists.