[e2e] UDP checksum field?

[Jonathan Stone]

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
>d
> >.  No
>>  *> response ever came back, and, if you look at a TNS packet today, the che
>c
> >ksum
>>  *> is still zero.  I guess no one has used the gateway software who cares a
>b
> >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
>errors).

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.