Re: [tsvwg] design assumptions - draft-ietf-udp-options - trying to see the bigger picture

["C. M. Heard" <[e-mail]>]

On Thu, Jul 18, 2019 at 9:16 AM Gorry Fairhurst wrote:
> On 18/07/2019, 16:46, C. M. Heard wrote:
>>> I'm hesitant to agree that the complexity of LITE is worth the perceived
>>> cost saving and there may be other ways that don't need this:
>>> cost saving and there may be other ways that don't need this:
>>> (*) Hardware  off-load of the checksum (e.g. Tom Herbert commened) means
>>> the cost can be minimal.
>>> (*) For a method designed just for reassembly, it is also possible to
>>> "checksum" the fragment checksums in a fragmentation protocol to provide
>>> equivalent one-pass checksum.
>>
>> I've argued that last point repeatedly (though Joe does not agree).
>>
>> If delivery of damaged payloads is adequately covered by UDP-Lite, it
>> would IMO make sense to strike support for LITE (#8) from the list of
>> design requirements. That would leave it only as a means to support
>> FRAG, and I think there are much better ways to do that (I've made two
>> proposals for FRAG that do not require LITE).
>>
> It would be interesting to understand the real desire to eliminate the
> cost of doing both a UDP and a reassembly checksum - so we can rule
> that out. It's going to waste cycles when there is no off-load, but
> it also allows full offload, and means you don't need LITE to do Frag.

My position is basically that the per-frgment checksum provided by OCS
should be mandatory, and any additional checksum on the reassembled
should be enabled only by user request. Here's the reasoning.

Having a checksum on each fragment that covers both options and fragment
data is necessary both for middlebox traversal and to ensure robustness
of the reassembly process. It provides protection equivalent to TCP
segment checksums, which should be good enough in most cases. An additional
checksum on the reassembled datagram payload is relatively expensive, so
it should be turned on only for applications that explicitly request it.
ACS is perfect for that purpose since it is defined to be per-datagram
and not per-packet and uses a different checksum than the the fragment OCS.

Consider:

- If fragment data is covered by OCS/CCO, that's comparable protection to
  what a TCP segment gets from the TCP checksum.

- Fragments are kept in sequence (and duplicates are discarded) by means
  of the fragment offset. That accomplished the same thing that TCP's
  sequence number does for segments.

- OCS/CCO on individual fragments can be readily offloaded, provided that
  the checksum is placed early in the packet. A checksum on the reassembled
  datagram, on the other hand, is very likely relegated to software, since
  the reassembled datagram will probably be in scatter-gather storage.

The first two bullets establish that per-fragment protection by OCS is
The third bullet plausibly suggests that the checksum on the reassembled
datagram payload is relatively expensive.

Furthermore, using the Internet checksum to check the reassembled datagram
payload won't add much protection if the ratio of fragment data to
headers+options is large. Every undetectable error pattern that hits the
data area in a single fragment will also go undetected in the reassembled
datagram payload. On the other hand, undetectable error patterns that hit
the data in multiple fragments may well be detected by the individual
fragment checksum. To me, this suggests that the two checksums should be
different, something that ACS will provide.

>>> A 16b CRC isn't that strong for a full-sized IP packet (but better
>>> than the Internet checksum), but a CRC32 would be.

+1

> DPLPMTUD works best with *just* padding packets (i.e. that carry no
> payloads or fragments). It's just so much easier to run the algorithm.

Yes, and the MTU discovery support requirement should be expanded to
say that. A probe packet consisting of padding data plus the request
and/or response options would fill the bill nicely.

Mike