Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!BBN.COM!haverty
From: haverty@BBN.COM (Jack Haverty)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: TCP Fletcher Checksum Option
Message-ID: <8911300523.AA28279@ucbvax.Berkeley.EDU>
Date: 29 Nov 89 22:42:35 GMT
References: <1989Nov29.160929.10160@brutus.cs.uiuc.edu>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 42

>Not to slam Postel and the whole IETF and everyone else who brought us the
>TCP/IP checksum algorithm, but the fact that it is not able to detect
>the transpostion of N (where N>=2 is an even number) octets in a datagram
>is of concern in some applications where ultra-reliable communication is
>essential.  Also, it has been pointed out by a number of hardware-types I
>have talked to that these sorts of errors can occur, for example, when
>DMAing bytes from an ethernet-controller to the main memory of a machine --
>i.e. after the ethernet CRC has already been checked. One case it to have
>a pair of 32-bit words go out over the bus in the wrong order under rare
>timing glitches....

I thought that the following snatch of history might be of interest.

I remember pretty clearly almost exactly this discussion at one of the
TCP working group meetings ten years ago.   There were two arguments
against having a more powerful checksum:

1/ I don't want to devote that much of my CPU to it (remember CPUs in
those days meant big, expensive, not-very-powerful timesharing systems)

2/ if we have to do complicated arithmetic (i.e., algorithms for which
the CPUs didn't have real good instructions available), it will make it
difficult to get high bandwidth

If I remember correctly, the telling argument was:

3/ People are working on new chips to do checksums in silicon.  We don't
want to adopt an algorithm that will preclude use of these chips.

The problem was that there was no obvious consensus to which chips would
hit the market when, and when computer manufacturers would put them into
their products.   This led to a basic plan which was:

Put in a rudimentary checksum now.   When CPU cycles become cheaper,
chips become available, and/or the drawbacks of the checksum become a
problem, select and standardize a new checksum.

If anybody else who was there remembers this differently, chime in!  

Maybe it's now the time....

Jack


Brought to you by Super Global Mega Corp .com