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

From: Vernon Schryver <[email-masked]>
Date: Thu, 4 Nov 1999 08:44:37 -0700 (MST)

> From: "Zhang, Weimin" <[email-masked]>

> 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.

That begs the question of how you know the error occurred in the UDP
payload instead of the UDP/IP header.  You cannot rely on the UDP or IP
checksums.  You would not send the header and payload in separate packets
(for whatever you care to call a link layer packet here), because the
per-packet overhead for such tiny gobs of bits as compressed UDP/IP header
or at most a few dozen milliseconds of sound would be terrible to double.

> 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.
> ...

If you are considering breaking the end-to-end nature of the UDP checksum,
then why not consider more straightforward approaches?  For example, on
the radio link why not honestly convert UDP/IP to what you've described,
a format with two or more error detection mechanisms, such as a good
FEC on the (compressed) information of UDP/IP headers (note, "information
of") and on the payload something as weak as you please including nothing?

The worst evils in kludges or not following standards are usually not in
their technical natures but in intellectually dishonesty.  UDP/IP is not
the right solution for everything.  When it doesn't fit as well as
something else, and you can justify the various costs of doing something
else, then do it openly.  Don't do a poor second choice that violates the
letter and spirit of the standard merely because it seems to salespeople
and ignorant customers to fit the popular standard.  Have the gumption to
stand up and say "The standard is wrong for this application so we're not
using it."

In other words, design a the best available solution to the problem,
and only then see if you can change to use standards.  Don't start
with the design constraint of pretending to use only standards.

Vernon Schryver    [email-masked]

---

From: Joe Touch <[email-masked]>
Date: Thu, 4 Nov 1999 10:18:03 -0800 (PST)

> From [email-masked]  Thu Nov  4 01:30:44 1999
> Delivery-Date: Thu, 04 Nov 1999 01:30:44 -0800
> Return-Path: [email-masked]
> To: [email-masked]
> Subject: Stronger end-to-end checksum - was: the link draft...
> Date: Thu, 4 Nov 1999 18:20:34 +1030 
> 

This has been discussed ad-infinitum on E2E before.
The primary problem is that a whole-packet checksum cannot
place the error - which means everything, including address,
is suspect. At that point, a "count" of erroneous packets
is OK, but sending the data up to the application is of
very dubious utility.

Progressive checksums (multiple checksums over increasingly longer
prefixes, or over disjoint portions) may provide the distinction between
"the body is bad, but the header is OK"; these are typically much more
complicated than you want to have for just a link layer, though.

For this draft, it might be useful to indicate that "bad packet counts"
or "events" be signalled up the stack, but that "there is no clear
indication that sending corrupt data is useful".

> 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.

E2E asserts that the composition of arbitrarily strong hop-by-hop services
cannot itself strengthen the corresponding E2E service. I.e., no - it doesn't
allow weaker E2E checksums.

Joe