Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde!uunet!tut.cis.ohio-state.edu!ucbvax!OKEEFFE.BERKELEY.EDU!sklower
From: sklower@OKEEFFE.BERKELEY.EDU (Keith Sklower)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: more on Fletcher
Message-ID: <8912051821.AA04015@okeeffe.Berkeley.EDU>
Date: 5 Dec 89 18:21:15 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 40

Johnny, Steve, Craig (et al):

	This tempest in a teapot started when Johnny Zweig took a
suggestion of mine for an alternative to the checksum employed in
OSI transport and asked if it could be adapted to the TCP protocol.
(And here I'm really speaking of TCP and TP and not the lower level
headers).

	I refered to it as a ``16-bit'' version of the Fletcher
algorithm, which actually yields 32 bits of checksum, has much
better error detection properties than the standard OSI checksum,
is twice as fast to compute, etc. etc.   At no time did I EVER
suggest that it would be a good thing to replace the TCP checksum
with it!!!!!!  (I could never make it run any faster than 2.5 times
slower than the corresponding best TCP checksum).

	It does have the amusing property that you could have 16 bits
of the 32 bits generated being the standard TCP checksum (in the standard
place), and the other 16 bits could appear anywhere else in the packet.
Craig suggested that if it were a TCP option, then it could be ignored
or declined in a graceful way.

	To address Steve's concern, I'm not imaginative enough to
think of a way to place TCP options behind the data; however the
verification algorithm is one of the kind, like ethernet CRC,
where you run along and compute numbers as you receive data,
and hopefully come up with a known quantity at the end
(in this case 32 bits of zeros).  And, should Steve's reason for
wanting the checksum at the end of the packet have to do with ease
of computing changes to the checksum given small changes to the packet,
in the case of TCP, you don't alter the TCP headers or data as they
pass through gateways.

	It wouldn't be hard to come up with a minor modification to
the VMTP checksum having the same property of position independence,
which would be almost as fast to compute as the TCP checksum.
The VMTP checksum would not detect 32 bit transpositions, nor double-bit
errors (which is what may have triggered Johnny's interest).
However, people on this list have already argued quite effectively
that a stronger checksum is really not needed.