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

[Joe Touch <[e-mail]>]

On Jul 11, 2019, at 9:51 PM, Tom Herbert <[e-mail]> wrote:
> 
> 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.

Sure, but here’s the issue:

Neither TCP nor UDP require their payloads to end on a word boundary. So transport checksums already need to deal with up to 3 bytes of “cleanup”.

Given that, why force the front alignment? At most it only doubles that cleanup, which ought to be nominal anyway.

Joe