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

[Brian E Carpenter]

RFCologists have noted that the three oldest Internet Standard
RFCs that have never yet been obsoleted are:

RFC 768	User Datagram Protocol, J. Postel, August 1980
RFC 791	Internet Protocol, J. Postel, September 1981
RFC 792	Internet Control Message Protocol, J. Postel, September 1981

There are updates to all those RFCs (see https://www.rfc-editor.org/standards)
but they have been remarkably stable as base documents.

The paragraph that John quotes below was also present in RFC 760,
which is also numbered as IEN 128, and includes this statement:
"This document is based on five earlier editions of the ARPA Internet
Protocol Specification, and the present text draws heavily from them."
A little digging shows that those are IEN 123, IEN 111, IEN 80, IEN 54,
and IEN 41. Before that was IEN 28 (IP version 2).

The quoted paragraph first appeared in IEN 28, dated Feb 1978, which
states that it follows "the outline suggested by the committee on
protocol specifications at the recent TCP meeting." That was presumably
the meeting on Feb 1, 1978 reported in IEN 22.

The various IENs also said:

"There are no mechanism to promote relibility, flow control, sequencing,
or other services commonly found in host-to-host protocols."

This sentence also survives (with the typos fixed) in RFC 791.

Regards/Ngā mihi
    Brian Carpenter

On 04-Jan-26 20:18, John Gilmore via Internet-history 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
>