🚀 go-pugleaf

The point I was trying to make is that TCP/UDP assume that the "unreliability"
of the underlying network is *mostly* of the dropping_packets kind, and
*very seldom* of the delivering_corrupted_data_and_saying_it's_good kind.
The link-level checksums should be designed to the particular characteristics
of the physical links, and so should make this assumption be "good enough"
(however you define "good enough"). But...

THERE ARE OTHER SOURCES OF CORRUPTION THAN LINKS! Memories may corrupt
bits and not be caught by parity (any even number of errors escapes a
single parity check), even assuming that *every* piece of memory
between you and the other end has parity (not a good assumption);
busses may glitch; software may have bugs; etc. The TCP/UDP checksum,
while not "strong" enough to protect very well against large amounts
of communications-link noise, *is* (1) very good at catching the
"occasional" error, and (2) easy to compute. (I assume everyone by
now knows how to do a load_multiple, add up the 32-bit words with an
"add_with_carry", and fold the result into 16 bits.) Thus, it forms
a last-ditch end-to-end check, which is not affected by the many
different environments the packet may have passed through on the way.

Link-by-link checksums, while necessary, are not sufficient.


Rob Warnock
Systems Architecture Consultant

UUCP:	  {amdcad,fortune,sun}!redwood!rpw3
ATTmail:  !rpw3
DDD:	  (415)572-2607
USPS:	  627 26th Ave, San Mateo, CA  94403