Re: [tsvwg] RDMA Support by UDP FRAG Option

[Tom Herbert <[e-mail]>]

On Mon, Jun 21, 2021, 9:31 AM C. M. Heard <[e-mail]> wrote:

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

Yes, I am aware of that. That is in fact a bug (middle boxes also shouldn't
be looking at UDP checksum in the first). The fix in the draft will
workaround that particular bug, but that would conflict with devices that
include the surplus area in their computation but use the correct length in
the pseudo header. Unfortunately these are conflicting requirements, so
100% correctness across all currently deployed devices may be impossible.
On the host side we at least have some control, for instance we could
disable TX checksum offload if we don't if the device can do it correctly.
RX offload would simply fail if the device doesn't do it right and host
would do checksum in CPU. The software stack can reworked to deal with any
use case and protocol agnostic offloads can work, but as I said the
simplest solution to that end would be surplus area summing to zero.

Tom


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