Re: [tsvwg] draft-ietf-udp-options issues from IETF 104

[Joe Touch <[e-mail]>]

> On Jul 11, 2019, at 2:46 PM, Tom Herbert <[e-mail]> wrote:
> 
> Assuming that the option checksum (OCS) issues are addressed (see above), the remaining motivations for discarding UDP options and doing something different appear to be:
> - Alignment: the NOP option in UDP options covers this
> - Protocol headers vs. protocol trailers: Something is wrong with that motivation as it leads to putting OCS immediately after the UDP length, i.e., before the data that it covers, whereas pipelined implementations would prefer to put it at the end of the IP length, i.e., after the data that it covers.
> 
> David,
> 
> I would agree with that if we were developing the IP checksum from scratch, but reality is we have thirty years experience optimizing checksum for TCP and UDP. For instance, in TX checksum offload the device is given the offset to write the checksum. Since the checksum is in header, some implentations express the offset in a byte to save a byte in TX descriptor. This is one example of implementation optimizing processing for headers, I doubt it's the only one.
> 
> Tom

Not sure I follow here - so there are only a few variants that seem viable:

1.- at the front of the surplus space
2.- at the front of the surplus space after alignment NOPs
3.- at the end of the surplus space
4.- at the end of the surplus space with alignment

AFAICT, there’s no real help in requiring OCS be aligned (it can be designed to tolerate any alignment), which means we don’t need #2 or #4.

So what’s preferable here? #1 or #3?

Joe