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

[Tom Herbert <[e-mail]>]

On Thu, Jul 11, 2019 at 10:25 PM Joe Touch <[e-mail]> wrote:
>
> 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”.
>
Per RFC768, a zero byte is appended if the UDP data length is odd.

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

It's a straightforward application of sending clause the robustness
principle. Other IP protocols ensure checksum and headers aligned so
this protocol should too in order to maximize robustness.

Tom

>
> Joe
>
>
>
>
>