Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-13.txt

[Joseph Touch <[e-mail]>]

Hi, Tom,

> On Jul 9, 2021, at 3:21 PM, Tom Herbert <[e-mail]> wrote:
> ...
> I don't know if it's a bad design, but I do know that IPv4 and TCP
> have had a fixed checksum field that covers options for over forty
> years.

The field location is irrelevant; the issue for offload *calculation* is the location of the area being covered. For OCS, it’s the entire surplus area, which does not require TLV parsing to determine.

Note, though, that IP may be in a fixed place, but covers only the IP header. The more relevant example is TCP, which is NOT fixed relative to the IP header (because there could be IP options).

> Not unsurprisingly, implementators have long since figured out
> how to optimize checksum calculation. Checksum offload is ubiquitous
> and CPUs have add-with-carry instructions of 32-bit, 64-bit, or vector
> instructions to optimize checksum calculation.

Note: the OCS checksum start is just as well known as it is for TCP - once the UDP offset is known, the OCS always covers exactly the same area between the UDP Length and the end of the IP packet. It’s only the *check* of the OCS validation that can’t be offloaded as easily, but that’s not always offloaded either. Offload calculates the checksum; there’s not a big win in doing the check there unless bad packets are the norm.

> Also, because of the
> way checksum offload works both senders and receivers of UDP options
> are likely to compute the checksum over the surplus area regardless of
> whether the checksum field is present-- even today, a legacy receiver
> will compute the checksum of surplus area in order to offset the
> checksum received from the device in checksum offload. AFAICT, no
> users are complaining about Internet checksum performance.

Sure, but that doesn’t change here either - as noted. Wherever OCS is placed, the checksum always covers the whole “surplus” area.

> In contrast to checksum calculation, walking TLV lists is still
> considered a major problem for performance.

And that’s still required for TCP and IP. We’re no different. That has no impact on checksum offload for UDP, only in option processing.

> The algorithm is an
> inherently serialized loop that requires a number of conditionals

And we have lived with that for years with TCP. The only difference here happens *outside* of offload optimization.

Any device that offloads the rest of transport processing already walks TCP TLVs and can walk UDP ones just as quickly (or slowly).

Joe