Subject: Stronger end-to-end checksum - was: the link draft...

From: "Zhang, Weimin" <[email-masked]>
Date: Thu, 4 Nov 1999 18:20:34 +1030

I would suggest that to distinguish the stronger checksum and whether to
discard a corrupted packet. A stronger checksum (eg. 32-bit CRC) at least
will provide the capability to deliver a more reliable "error free" packet
to the upper layer. Whether to discard a erroneous packet, especially for
UDP applications, should be dealt by another parameter and the user. I
personally support it to be delivered, if the address is right. This may
enable the user to make use of incomplete packets.

When talking about the cost of the checksum, there are two aspects: one is
the space taken in a packet header (eg. 16 bits vs 32 bits) and the other is
the processing time at both ends. In TCP and UDP, a one's complement 16-bit
checksum is used, which is not as strong as a 16-bit CRC. Change it to a
16-bit CRC will not cost any bandwidth, but may be some processing time. A
few years ago there was an High Frequency (HF) trial here that two errors
happened in a packet and were not detected by the TCP checksum - resulting
in a distorted picture. Apparently current HF Link Layer protocols are
switched to 32-bit CRCs, such as Fed-Std-1052. I am not sure whether this
means the end-to-end checksum can be weaker.

I have read some performance test on checksums and bounds on error detection
codes. However the test was not comprehensive and the bounds were not tight.
If any one knows more please share. 

Weimin Zhang

---

From: Greg Minshall <[email-masked]>
Date: Thu, 04 Nov 1999 10:56:19 -0800

Weimin,

You might want to look at Partridge, et al, at the SIGCOMM '95 proceedings.  
While the TCP/UDP checksum doesn't catch lots of failure scenarios, combining 
it with link level CRCs does an almost perfect job.

(In the HF trial you mention, was there a link-level CRC?)

Cheers,  Greg Minshall