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

[Tom Herbert <[e-mail]>]

On Fri, Jul 9, 2021 at 5:15 PM Joseph Touch <[e-mail]> wrote:
>
> 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.
>
TCP and IPv4 do not require walking their respective options to
validate the checksum,  UDP options does at least when UDP checksum is
non-zero. If processing UDP options walks the list twice, once to
search for a specific TLV and once to process the rest of the options,
then relative to checksum processing for TCP and IPv4 that is a
performance degradation. Maybe there are other intended methods like
provisionally processing TLVs and throwing out work when a bad
checksum is detected or scoreboarding of TLVs, but those options are
not articulated in the draft nor are there any references to
implementation that show this.

Tom

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