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

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

FWIW there is an incompletely edited sentence in the message below.

OLD
The first two bullets establish that per-fragment protection by OCS is

NEW
The first two bullets establish that per-fragment protection by OCS is
sufficient to protect reassembled datagrams passed to UDP-based applications
as well as TCP protects user data that is passed to TCP-based applications.

Sorry.

--cmh

On Thu, Jul 18, 2019 at 2:23 PM C. M. Heard <[e-mail]> wrote:

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