Re: [tsvwg] RDMA Support by UDP FRAG Option

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

On Mon, Jun 21, 2021 at 9:46 AM Tom Herbert  wrote:

> On Mon, Jun 21, 2021, 9:31 AM C. M. Heard 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.
>

That's true, it's not possible to compensate for all of the middlebox bugs.
But thanks to the work of the Aberdeen group, we have some actual data.
They found that found that paths that passed only the following oddball
combinations

"3rd CS" == "Full Payload Checksum, UDP length Pseudoheader"
"4th CS" == "UDP Length Checksum, IP length Pseudoheader"

were MUCH smaller in number than those that worked with CCO (" Full Payload
Checksum, IP length Pseudoheader").

The chosen solution works for the majority of cases and so is a logical
choice.

On the host side we at least have some control, for instance we could
> disable TX checksum offload if [ ... ] the device can[not] 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.
>

Making the surplus area sum to zero may well make SOME host software easier
to update to be compatible with UDP options, and it would work around SOME
host bugs.

But it would cause UDP options to fail over 25% - 25% of Internet paths.
Note the word PATH, which includes middleboxes AND hosts.

That IMO is not a good design tradeoff.

Mike

>