[ih] early networking: "the solution"

Sun Apr 21 16:47:55 PDT 2024

Just a comment:  I recall the intensive work on algebraic error-correcting and error-detecting codes in the late 1950’s and early 1960’s while I was a graduate student at MIT in the presence of folks like Claude Shannon.  Among the most interesting were the Bose–Chaudhuri–Hocquenghem codes (BCH codes, also known as CRC codes) since they dealt with multiple errors. At the time we realized that the BCH codes were extremely effective (and simple) for error detection but were horribly complex for error-correction. It is no surprise that some years later they were incorporated in the early Arpanet for error detection. And here we are today!
Len

> On Apr 21, 2024, at 3:14 PM, Jack Haverty via Internet-history <internet-history at elists.isoc.org> wrote:
> 
> Probably not many people know the story behind the IP checksum.   I don't think anyone's ever written it down.  While I still remember...:
> 
> The checksum algorithm was selected not for its capabilities to catch errors, but rather for its simplicity for our overworked and inadequate computing power.  There was significant concern at the time, especially in the sites running the big host computers, about the use of scarce computing power as "overhead" involved in using the network.  See for example: https://www.rfc-editor.org/rfc//rfc425
> 
> Besides, at the time all TCP traffic was through the Arpanet, and the IMPs did their own checksums so any circuit problems would be caught there.  So as we were defining the details of the new TCP4 mechanisms, the checksum algorithm was kept intentionally simple, to be replaced in some future version of TCP when computers would be more capable and the error characteristics of pathways through the Internet were better understood by experience.   The checksum algorithm was a placeholder for a future improved version, like many other mechanisms of TCP/IP4.
> 
> The actual details of the checksum computation were nailed down on January 27, 1979.  That was the date of the first TCP Bakeoff, organized by Jon Postel.   I think of it as possibly the first ever "Hackathon".
> 
> The group of TCP implementers assembled on a weekend at USC-ISI and commandeered a bunch of offices with terminals that we could use to connect to our computers back home.   At first, we could all talk to ourselves fine.   However, no one could talk to any other implementation.  Everybody was getting checksum errors.
> 
> Since we could all hear each other, a discussion quickly reach a consensus.   We turned off the checksum verification code in all of our implementations, so our TCPs would simply assume every incoming message/packet/datagram/segment (you pick your favorite term...) was error-free.
> 
> It seems strange now, but computing in the 1970s was a lot different from today.  In addition to the scarcity of CPU power and memory, there was little consensus about how bits were used inside of each computer, and how they were transferred onto wires by network interface hardware.  Computers didn't agree on the number of bits in a byte, or how bytes were ordered into computer words, how arithmetic calculations were performed, or how to take the bits in and out of your computer's memory and transfer them serially over an I/O interface.  If you think the confusion of today's USB connectors is bad, it was much worse 50 years ago!
> 
> Danny Cohen later published a great "plea for peace" that reveals some of the confusion - see https://www.rfc-editor.org/ien/ien137.txt
> 
> So it wasn't a surprise that each TCP implementer had somehow failed in translating the specification, simple as it was, into code.
> 
> The disabling of checksums enabled us to debug all this and slowly (took two days IIRC) got implementations to talk to other implementations.  Then we re-enabled checksumming and tried all the tests again.  TCP4 worked!  Jon Postel took on the task of figuring out how the now working checksums actually were doing the computations and revised the specifications accordingly.   Rough consensus and running code had failed; instead we had running code and then rough consensus.
> 
> My most memorable recollection of that weekend was late on Sunday. Jon had set up the Bakeoff with a "scoring scheme" which gave each participant a number of points for passing each test.   His score rules are here: https://drive.google.com/file/d/1NNc9tJTEQsVq-knCCWLeJ3zVrL2Xd25g/view?usp=sharing
> 
> We were all getting tired, and Bill Plummer (Tenex TCP) shouted down the hall to Dave Clark (Multics TCP) -- "Hey Dave, can you turn off your checksumming again?"  Dave replied "OK, it's off".  Bill hit a key on his terminal.  Dave yelled "Hey, Multics just crashed!"  Bill gloated "KO! Ten points for me!"
> 
> Such was how checksumming made it into TCP/IP4.
> 
> Jack Haverty
> 
> 
> 
> On 4/21/24 12:27, John Day via Internet-history wrote:
>> So I wasn’t dreaming!  ;-)
>> 
>> CRCs also have problems in HDLC if there are a lot of 1s in the data.  (The bit stuffing is not included in the checksum calculation.)
>> 
>>> On Apr 21, 2024, at 15:22,touch at strayalpha.com  wrote:
>>> 
>>> I think it was this one:
>>> http://ccr.sigcomm.org/archive/1995/conf/partridge.pdf
>>> 
>>> Joe
>>> 
>>> —
>>> Dr. Joe Touch, temporal epistemologist
>>> www.strayalpha.com
>>> 
>>>> On Apr 21, 2024, at 12:20 PM, Scott Bradner via Internet-history<internet-history at elists.isoc.org>  wrote:
>>>> 
>>>> maybe in conjunction with the Pac Bell NAP
>>>> 
>>>> https://www.cnet.com/tech/mobile/pac-bell-adds-network-access/
>>>> 
>>>> https://mailman.nanog.org/pipermail/nanog/1998-March/127113.html
>>>> 
>>>> Scott
>>>> 
>>>>> On Apr 21, 2024, at 3:00 PM, John Day<jeanjour at comcast.net>  wrote:
>>>>> 
>>>>> I have a vague recollection of a paper (possibly by Craig Partridge) that talked about ATM dropping cells (and possibly other different forms of errors) and how IP and other protocols were not built to detect such losses.
>>>>> 
>>>>> Am I dreaming?
>>>>> 
>>>>> John
>>>>> 
>>>>>> On Apr 21, 2024, at 09:10, Scott Bradner via Internet-history<internet-history at elists.isoc.org>  wrote:
>>>>>> 
>>>>>> yes but...
>>>>>> 
>>>>>> the ATM Forum people felt that ATM should replace TCP and most of IP
>>>>>> i.e. become the new IP and that new applications should assume they were
>>>>>> running over ATM and directly make use of ATM features (e.g., ABR)
>>>>>> 
>>>>>> ATM as yet another wire was just fine (though a bit choppy)
>>>>>> 
>>>>>> Scott
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On Apr 21, 2024, at 9:02 AM, Andrew G. Malis<agmalis at gmail.com>  wrote:
>>>>>>> 
>>>>>>> Scott,
>>>>>>> 
>>>>>>> ATM could carry any protocol that you could carry over Ethernet, see RFCs 2225, 2492, and 2684.
>>>>>>> 
>>>>>>> Cheers,
>>>>>>> Andy
>>>>>>> 
>>>>>>> 
>>>>>>> On Sat, Apr 20, 2024 at 8:15 PM Scott Bradner via Internet-history<internet-history at elists.isoc.org>  wrote:
>>>>>>> 
>>>>>>> 
>>>>>>>> On Apr 20, 2024, at 8:11 PM, John Gilmore via Internet-history<internet-history at elists.isoc.org>  wrote:
>>>>>>>> 
>>>>>>>> John Day via Internet-history<internet-history at elists.isoc.org>  wrote:
>>>>>>>>> In the early 70s, people were trying to figure out how to interwork multiple networks of different technologies. What was the solution that was arrived at that led to the current Internet?
>>>>>>>>> I conjectured yesterday that the fundamental solution must have been in hand by the time Cerf and Kahn published their paper.
>>>>>>>>> Are you conjecturing that the solution was gateways? and hence protocol translation at the gateways?
>>>>>>>> Maybe it's too obvious in retrospect.  But the "solution" that I see was
>>>>>>>> that everyone had to move to using a protocol that was independent of
>>>>>>>> their physical medium.
>>>>>>> and ATM was an example of the reverse - it was a protocol & a network - OK
>>>>>>> as long as you did not build applications that knew they were running over ATM
>>>>>>> (or if ATM had been the last networking protocol)
>>>>>>> 
>>>>>>> Scott
>>>>>>> -- 
>>>>>>> Internet-history mailing list
>>>>>>> Internet-history at elists.isoc.org
>>>>>>> https://elists.isoc.org/mailman/listinfo/internet-history
>>>>>> -- 
>>>>>> Internet-history mailing list
>>>>>> Internet-history at elists.isoc.org
>>>>>> https://elists.isoc.org/mailman/listinfo/internet-history
>>>> -- 
>>>> Internet-history mailing list
>>>> Internet-history at elists.isoc.org
>>>> https://elists.isoc.org/mailman/listinfo/internet-history
> 
> -- 
> Internet-history mailing list
> Internet-history at elists.isoc.org
> https://elists.isoc.org/mailman/listinfo/internet-history