Path: utzoo!mnetor!uunet!husc6!mit-eddie!bbn!uwmcsd1!ig!agate!ucbvax!CCV.BBN.COM!haverty
From: haverty@CCV.BBN.COM
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Rumors about the death of the ARPANET
Message-ID: <8803231534.AA16421@ucbvax.Berkeley.EDU>
Date: 22 Mar 88 20:39:04 GMT
References: <8803221720.AA00215@braden.isi.edu>
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 39

Hi Bob,

Yes, good observation.  Actually it's not so much the weakness of the
TCP algorithm, it's the fact that so much has to remain intact for the
bad packet to make it to the destination at all to be checksummed!

The other thing to note is that error-correcting codes are related to
checksumming and to fault isolation - they detect, isolate the cause,
and repair all at the same time (but they DON'T usually report the
event to someone who might, for example, dispatch service to fix a
flaky component.  

Here's part of an exchange from Vint commenting on checksums that
would have a bit that is set for 'pointer-off', and another for
'count-off-by-one', etc. that you might find interesting:

Vint - You've touched on an interesting point.  Right now, checksums
are almost alway binary, i.e., the data is either intact to some high
probability, or it's bad in some undefined way.  Thus checksums become
good fault detection tools, but lousy fault isolation tools.  If we
could design a checksum algorithm that produced more than a yes/no
output, it could be a useful network management tool; e.g., even if it
could differentiate between a single-bit error in a packet, which
might be a 'normal' behavior of certain lines, and a totally clobbered
packet, e.g., all bytes zeroed, which might indicate a major hardware
or software failure, it would be very useful.  The former would be
ignored unless it happens a lot; the latter could trigger alarms,
memory snapshots, datascope traces, etc.
             
Of course the ultimate such algorithm would set bit 1 for off-by-one,
bit 2 for pointer problem, etc.  It may sound crazy, but I think it's
not so farfetched.  From lots of hours looking over people's shoulders
as they debug problems (and doing it myself), the key principle is to
look for something 'unusual' in the behavior.  If that test could be
converted into an AI-ish algorithm, it could become part of the 
network technology itself.  Deja vu - we talked about this kind ofd
thing when getting the original Automated Network Managemet prmoject
off the ground.  Maybe we should get the academic community to try to
invent a new branch of science and engineering focussed around 'checksums'?