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

[vinton cerf]

The change was a consequence of the unreliability of the packet radio and
packet satellite systems which did not work the same way the IMPs did. it
forced us to support host level end/end flow, congestion and reliability.

v




On Sun, Jan 4, 2026 at 2:18 AM John Gilmore via Internet-history <
internet-history at elists.isoc.org> wrote:

> Jack Haverty via Internet-history <internet-history at elists.isoc.org>
> wrote:
> > 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?
>
> A major change was from IMPs guaranteeing to their hosts that they would
> deliver each packet.  The replacement, IP, *never* promised to deliver a
> packet; it was up to the host to re-send the packet if it cared for
> reliable delivery.  Thus the network did not offer virtual circuits,
> and the host had to synthesize one (with TCP) if the host wanted one.
>
> As RFC 791 (Internet Protocol, by Jon Postel) said:
>
>   The internet protocol does not provide a reliable communication
>   facility.  There are no acknowledgments either end-to-end or
>   hop-by-hop.  There is no error control for data, only a header
>   checksum.  There are no retransmissions.  There is no flow control.
>
> This architecture change also makes it possible to build the core of the
> network out of simpler, faster, cheaper IP routers, because the network
> only depends on them to do a few things (addressing, routing and
> fragmentation).
>
> I had always heard that the reason for this change was that one day the
> ARPANET froze up because all the IMPs' buffers were full of packets that
> they could not discard (because they had promised to deliver them), so
> they could not process any new incoming messages.  The cure for this, at
> a protocol level, was to let routers freely discard packets that were in
> their buffers, whenever convenient or necessary.  That required that the
> hosts be prepared to check acknowledgements and retransmit if needed.
>
> That's my memory -- but does the history support it?  Not so far.  In
> looking today, I found three RFCs and another few items that covered
> ARPANET-wide crashes, and none of them pointed out this particular
> failure mode.  See:
>
>   "Software Checksumming in the IMP and Network Reliability"
>   J. McQuillan, BBN; 1973-06-20
>   https://www.rfc-editor.org/rfc/rfc528.txt
>
>   "Christmas Day Lockup - Harvard IMP hardware problem leads it to
>   broadcast zero-length hops to any ARPANET destination, causing all
>   other IMPs to send their traffic to Harvard (25 December)" 1973
>
> https://www.cs.kent.edu/~rothstei/10051/history/Hobbes-Internet-Timeline.html
>
>   "On a Possible Lockup Condition in the IMP Subnet Due to Message
> Sequencing"
>   L. Kleinrock, H. Opderbeck, UCLA; 1974-03-00
>   https://datatracker.ietf.org/doc/html/rfc626
>
>     (This mentions the Christmas lockup, and cites to: BBN Report
>     No. 2717, "Interface Message Processors for the ARPA Computer
>     Network," Quarterly Technical Report No. 4, January 1974, which
>     might have contained a less terse description of the Christmas
>     lockup (which Kleinrock says was not on Christmas Day, but on
>     1973-12-21).  I have not found an online source of this BBN report
>     yet.)
>
>   "ARPANET Lessons"
>   Leonard Kleinrock; 1976 International Conference on Communications
>   https://www.lk.cs.ucla.edu/data/files/Kleinrock/arpanet_lessons.pdf
>
>     Detailed description of the "Christmas Lockup" and other forms of
>     network deadlock.
>
>   "Vulnerabilities of Network Control Protocols: An Example"
>   Eric C. Rosen, BBN; 1981-07-00
>   https://www.rfc-editor.org/rfc/rfc789.html
>
> Can anyone point us to better sources for this architectural change?
>
>         John
>
> --
> 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
>