Re: [tsvwg] RDMA Support by UDP FRAG Option

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

On Mon, Jun 21, 2021 at 7:34 AM Tom Herbert wrote:

> In my opinion, the best chance for UDP options to be deployable and
> successful is to require that the surplus area always sums to zero.
>

Tom,

Had that statement been "the best chance for UDP options to be deployable
and successful is to require that the surplus area always sums to the
ones-complement of the surplus area length." But the statement above, taken
literally, is NOT TRUE.

You may remember the lengthy discussion that centered around the discovery
by the Aberdeen group (Fairhurst, Jones, and Zullo) that a significant
proportion of paths across the Internet BLOCK packets with a surplus area,
even if the UDP checksum is correct, unless it has been arranged that the
checksum ALSO comes to (ones complement) zero when computed over the IP
payload length and with the IP payload length substituted for the UDP
length in the pseudo-header.

See
https://datatracker.ietf.org/meeting/103/materials/slides-103-maprg-a-tale-of-two-checksums-tom-jones

I'm pretty sure that you knew of this, but forgot, because I saw messages
in the archive wherein you discussed this matter with Raffaele Zullo.

The root cause appears to be a BUG in middlebox implementations that
substitute IP payload for UDP payload length in the UDP checksum
computation. See pages 5 and 6 of the presentation. Note that the BUG was
corrected in Freebsd.

Making UDP options viable across a large proportion of real-world paths in
the Internet is a vital step in making it successful, and that is why the
WG (seems to have) converged on computing OCS so that it has the same
effect as the checksum compensation option (CCO, see
draft-ietf-fairhurst-udp-options-cco).

If the Linux stack pervasively takes the shortcut of substituting IP
payload length for UDP length, or making a similar substitution in
encapsulations, that is a BUG of the very same kind that CCO was invented
to work around. I have to agree with Joe on this point.

Having said that, I do still agree that if it is possible without undue
burden, it is desirable for the UDP options spec to play well with the
generic hardware checksum offload that you described in
draft-herbert-udp-space-hdr-01 that sum to the end of the packet. It is NOT
a bug for the device to offer the offload capability in that form (though
it would be a bug if the host software or the NIC firmware did not use that
capability correctly).

Happily, generic checksum offload works just fine for the usual case
(non-encapsulated data), as I think I proved  conclusively in
https://mailarchive.ietf.org/arch/msg/tsvwg/RZULHOKRgrSYIvsI-5Hg7sNtSS8/. I
think that the version of FRAG in -13 of the current draft may have some
problems with encapsulations, as I stated in
https://mailarchive.ietf.org/arch/msg/tsvwg/thc0mIjU6CcyppULA1L0aV3Mk7M/,
and I will offer specific comments on that. What I am not going to do is go
down any more ratholes where I pose a question to you about what is wrong
and then get in return a non-response that simply asserts that what we are
doing won't work with Linux. You have not made your case, and I will not
respond further until you do. Life is too short.

I have, of course, not made the case about protocol-specific checksum
offload hardware, but I do not think that it's reasonable to expect a
priori that a modification to UDP can be expected to work with them. If you
will provide pointers to specs for (or clear descriptions of) some common
ones I'll look when I have time.

Mike