[e2e] UDP checksum field?

Jonathan Stone jonathan at dsg.stanford.edu
Mon Apr 4 12:46:04 PDT 2005

In message <20050404183210.1AAF324B at aland.bbn.com>,
Craig Partridge writes:

>In message <200504041733.KAA26987 at gra.isi.edu>, Bob Braden writes:
>>  *> explaining exactly the problem and urging the TNS checksum be implemente
> >.  No
>>  *> response ever came back, and, if you look at a TNS packet today, the che
> >ksum
>>  *> is still zero.  I guess no one has used the gateway software who cares a
> >out
>>  *> their data.  :]
>>  *> 
>>  *> Alex
>>  *> 
>>Or, the incidence of (detected) failures is so low that no one cares.
>I vaguely recall that some part of BBN had experience with the NSF
>checksum problem and that it took a while for the corruption of the
>filesystem to become visible.  That is, errors are infrequent enough
>that NIC (or switch, or whatever, ...) testing doesn't typically catch
>them.  So bit rot is slow and subtle -- and when you find it, much has
>been trashed (especially if one ignores early warning signs, such as
>large compilations occasionally failing with unrepeatable loading/compilation

Hi Craig,

I beleive Steve Crocker mentioned this point after I presented one of
our papers on e2e checksums.  This instance was, again, a large NFS
server (don't know if it was BBN or elsewhere), where the data
corruption was not detected until after several backup cycles. So even
the backup tapes were corrupted.  I was told people working on key
projects had to go back to hardcopy print-outs and retype them.

Whether it's safe to trust outboard checksum offload is a whole
other story.

More information about the end2end-interest mailing list