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

[Tom Herbert <[e-mail]>]

On Thu, Jul 11, 2019, 7:07 PM Joe Touch <[e-mail]> wrote:

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

#2 gives greatest probability of working with existing implementation of
checksum offload.


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