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

[Tom Herbert <[e-mail]>]

On Thu, Jul 11, 2019 at 8:49 PM Joe Touch <[e-mail]> wrote:
>
>
>
> On Jul 11, 2019, at 7:14 PM, Tom Herbert <[e-mail]> wrote:
>
>> 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.
>
>
> A few questions on that:
> - Can we deal with a small amount of “cleanup” operations after the offload?
> - if so can that allow arbitrary byte start?
> - or at least16-bit instead of 32-bit alignment?
>
> Keep in mind that regardless of where we start, we shouldn’t need aligned ends, so there’s always some “cleanup” with such support anyway.
>
> I.e., why can’t we start at the 32-bit alignment and just add the rest and adjust later, rather than pad?
>
Joe,

Yes, we can do all these things. But, it's not a question of what can
be done, it's a question of what should be done. If you want to
maximize the chances of a deployable and successful protocol then the
best course of action is to follow the conventions and design patterns
previously set by successfully deployed protocols. Implementations,
both end hosts and middleboxes, have long baked in and optimized
around these conventions. For instance, we know TCP is a header not a
trailer, the multi-byte fields in the TCP header are properly aligned
including checksum, the start of the TCP options is aligned, the TCP
header length is multiple of four bytes, the checksum is in a fixed
location and not optional, etc. Implementations assume these
conventions, not just for TCP, but most IP protocols adhere to some
set of common conventions. Obviously we can't follow all conventions,
using the UDP surplus space is certainly unconventional, but the less
deviation from convention the higher probability of success in the
real world. Note that optimizing out a few bytes here and there is
immaterial as to whether the protocol will be ultimately prove
deployable-- it really isn't the highest priority issue we need to
worry about.

Tom

> Joe
>