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

[Tom Herbert <[e-mail]>]

On Sat, Jul 10, 2021 at 9:09 AM Joseph Touch <[e-mail]> wrote:
>
> Hi, Tom,
>
> On Jul 10, 2021, at 8:19 AM, Tom Herbert <[e-mail]> wrote:
>
> On Fri, Jul 9, 2021 at 5:15 PM Joseph Touch <[e-mail]> wrote:
>
> ...
>
> 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,
>
>
> OK, we agree on that. So at least we’ve established the use of TLVs isn’t an offload issue.
>
> UDP options does at least when UDP checksum is
> non-zero. If processing UDP options walks the list twice,
>
>
> Only when the SHOULD is not followed; we can certainly add that note.
>
> An implementation could easily walk the TLV and set a flag if options other than OCS or NOP appear. The walk ignores such options until OCS and restarts if OCS works.
>
> So we can note that this “double walk” would incur double work if:
> - options other than OCS and NOP appear before OCS

What if OCS is not present? If we ignore options in the first walk to
account for the possibility that an OCS might be present, doesn't that
mean that once the walk completes and we haven't found the OCS we need
to walk again to actually process all the options?

> AND
> - offloading is used
>
> Without offloading, the walk always occurs twice: once to compute the checksum, once to process options, and the first pass can keep a copy of the OCS value to check before the second pass.
>
> .... 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.
>
>
> We can mention that possibility, which would be no different than deep conditional processing that many systems alr
>
> But, again, the issue isn’t about offloading, it’s in post-offload processing, and only if the SHOULD is not followed.
>
> At that point, yes, we could do something to avoid that possible issue without impacting those who don’t use OCS, but it’s a lot simpler than has been proposed before. It does revive the idea of a required UDP option header, but it would basically be just an aligned OCS checksum:
>
> - NOPs until 4-byte alignment (note that some wanted 8-byte alignment, so we have to pick)
> - OCS checksum field only (no kind, no length)
>
> If we don’t require alignment, there’s a small amount of additional work. That might not be useful to optimize for because the UDP option space isn’t constrained the way TCP’s is, though.
>
> That overcomes the post-offload issue for OCS, though there’s still a similar post-offload issue for other options (ENCR, AUTH) that matches the same ‘chain’ problem you’ve been concerned about that still in other protocols that use offloading for crypto, e.g., IPsec, TCP-MD5/TCP-AO, etc.
>
> Joe
>