Subject: Re: [tsvwg] UDP guidelines draft (5405bis) -07 - update

From: Joe Touch <[email-masked]>
Date: Tue, 1 Dec 2015 10:43:25 -0800

On 11/30/2015 10:04 PM, [email-masked] wrote:
> Yes, Stone's papers and PhD thesis are the usual references
> on errors and reliability for the Internet crowd.
...
> 
> I'm glad that e.g. the FAA is looking at computer reliability,
> and that work on better error detection is still ongoing.

As am I, but if your local hardware has undetected errors, I don't see
how using it to compute a checksum will be productive.

Yes, there are extreme corner cases and exceptions where a packet check
at some protocol layer can avoid wasted effort at other layers.

However, given the statistics, I disagree that we want to put these
protections in every protocol layer. To do so would increase complexity,
the potential for coding errors, cost (monetary, carbon, etc.)
unnecessarily.

Joe

---

From: <[email-masked]>
Date: Tue, 1 Dec 2015 22:59:53 +0000 (UTC)

> I disagree that we want to put these
> protections in every protocol layer.
 Where do you think I said that? Who are you disagreeing with?
If hardware computes a checksum on a copied packet it has received,it is an indication that either the packet has been corrupted - or thatthe storage has been corrupted, which e.g. Eth CRC32s won't pick up.
Since packets exist as not-always-perfect copies of themselves,having demux checks and end-to-end checks across (most of) thecopying path with UDP and UDP-Lite is imo very very useful, eventhough one's complement is so weak and can't detect e.g. swappedbytes.
The ever-longer list of caveats and exceptions for turningoff the UDP checksum makes me nervous....

Lloyd Wood [email-masked] http://about.me/lloydwood 
      From: Joe Touch <[email-masked]>
 To: [email-masked] 
Cc: [email-masked]; Tom Herbert <[email-masked]>; Tsvwg IETF List <[email-masked]>
 Sent: Wednesday, 2 December 2015, 5:43
 Subject: Re: [tsvwg] UDP guidelines draft (5405bis) -07 - update

...

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 3 Dec 2015 08:38:48 -0800

> Where do you think I said that? Who are you disagreeing with?

You, confirmed later in this message, except I'm taking your position to
its logical destination; you're arguing for checks at a specific
relaying layer simply because of relaying (rather than proximity to a
physical channel) or E2E.

> If hardware computes a checksum on a copied packet it has received,
> it is an indication that either the packet has been corrupted - or that
> the storage has been corrupted, which e.g. Eth CRC32s won't pick 
> up.
> 
> Since packets exist as not-always-perfect copies of themselves,
> having demux checks and end-to-end checks across (most of) the
> copying path with UDP and UDP-Lite is imo very very useful, even
> though one's complement is so weak and can't detect e.g. swapped
> bytes.

The tradeoff is your view of "very useful" vs my view of "helps only in
extraordinarily rare cases", and the corresponding cost (mostly
computational).

> The ever-longer list of caveats and exceptions for turning
> off the UDP checksum makes me nervous....

We really ought to have some consistent guidance for that, and stop
deriving the answer on a per-case basis.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Thu, 3 Dec 2015 09:17:58 -0800

> deriving the answer on a per-case basis.
RFC6935 and RFC6936 already provide clear guidance. Disabling UDP
checksum can only ever be a MAY where the decision to do that lies
with the network operator. Without knowing the details of any
particular case we can never know establish the actual tradeoffs of
disabling the checksum. In my data center network for instance,
probably largest IPv6 DC deployment, we have absolutely no reason to
disable UDP checksums in IPv6. There is simply no cost benefit to do
that.

Tom