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

["Black, David" <[e-mail]>]

Commenting as an individual, **not** as a WG chair.

-- Option Checksum (OCS)

The IETF 104 tsvwg minutes match my impression that the topic of whether the offsetting option checksum (OCS) should be optional vs. mandatory remains an open issue for UDP options.

For my part, I've seen strong "running code" evidence of what breaks when the OCS is omitted, in contrast to almost no evidence of things broken by the presence of OCS (computed to offset the UDP checksum calculation when that is done over IP length instead of UDP length).  For that reason, my current view is that the OCS ought to be mandatory.  Beyond that, I think Tom has a strong argument for putting the OCS in a fixed position of some sort, although my initial sense is that the OCS checksum should be at the end of the IP length, as that works better for pipelined implementations.

One exception to OCS being mandatory that makes sense to me is that OCS doesn't seem to make a lot of sense with LITE, as the OCS would cover all the LITE payload data, thereby defeating the LITE goal of not having to checksum data whose reliability is not of interest.   One consequence is that UDP Options become unreliable when LITE is used, which may have implications for which UDP options are acceptable to use with LITE.  An important tradeoff is that LITE won't work on network paths that pass  UDP Options only when OCS is present.

-- Other uses of surplus space

Any hypothetical existing use of surplus space is incompatible with both UDP options and a new surplus header.  While I haven't seen evidence of any such existing use "running code," making the OCS mandatory helps defend against that possibility, as well as against bad endpoint implementations that put whatever junk bytes happen to be lying around in memory into that extra space, improving UDP Options robustness.

Both UDP options and the surplus header are extensible, which is the "80%" conclusion from my perspective.  Beyond that, I don't see a lot of difference in what the two extensibility approaches enable.

-- Additional motivations

Tom asked " See the motivations section in the draft." ... so I did ...

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.

-- Bottom Line --

I see clear opportunity for improvement in the option checksum (OCS) support in UDP options.  **If** suitable OCS improvements are made, then I don't see a strong case for an alternative approach.

Thanks, --David

> -----Original Message-----
> From: tsvwg <[e-mail]> On Behalf Of Joe Touch
> Sent: Thursday, July 11, 2019 2:32 PM
> To: Tom Herbert
> Cc: tsvwg
> Subject: Re: [tsvwg] draft-ietf-udp-options issues from IETF 104
> 
> 
> [EXTERNAL EMAIL]
> 
> 
> 
> > On Jul 11, 2019, at 9:46 AM, Tom Herbert <[e-mail]> wrote:
> >
> >> On Thu, Jul 11, 2019 at 8:55 AM Joe Touch <[e-mail]>
> wrote:
> >>
> >>
> >>
> >> On Jul 11, 2019, at 8:11 AM, Tom Herbert <[e-mail]> wrote:
> >>
> >>
> >>
> >>> On Wed, Jul 10, 2019, 10:16 PM Joe Touch <[e-mail]>
> wrote:
> >>>
> >>> Updating the subject line...
> >>>
> >>>> On Jul 10, 2019, at 8:56 PM, Tom Herbert <[e-mail]>
> wrote:
> >>>>
> >>>> ...
> >>>> So it took the better part of a day and quite a few emails to conclude
> that the only remaining issue in this proposal is one that we’ve already
> discussed at length.
> >>>
> >>>
> >>> Hardly the only remaining issue if you're referring to UDP options.
> >>>
> >>>
> >>> Please look at minutes from last IETF. Both the subject of disambiguation
> of surplus space
> >>>
> >>> as well as negotiation of UDP options was raised (i.e. if the receiver
> requires checksum how
> >>>
> >>> does sender know that). I haven't seen these addressed by UDP options
> draft at least…
> >>>
> >>>
> >>> If you review the minutes from IETF 104, you will note that the next
> steps were yours and QUICs, not mine.
> >>>
> >>> But let me jump in:
> >>>
> >>> - regarding other uses of the option space:
> >>> - as I’ve already noted in this thread, this was discussed on this list long
> before IETF 104
> >>> - past uses (if there are any) would be protected (if necessary) by use of
> OCS (when OCS is used)
> >>> - future uses need not be differentiated independently; they should be
> using the UDP option code points instead
> >>>
> >>> Regarding soft-state coordination:
> >>> - Sec 13 already addresses the general notion of soft state in a general
> sense.
> >>> - on 3/20/19, I noted on the list that soft state mechanisms are not
> specified because each option might vary in how this is achieved
> >>> - if this isn’t sufficient, can you please clarify?
> >>
> >>
> >> It's not sufficient. The point of a protocol specification is to describe how
> the protocol works, without normative requirements and procedures there
> is no interoperability and no robustness.
> >>
> >>
> >> It’s a USER protocol; the user decides.
> >>
> >> Other notes:
> >> - UDP remains unreliable, so there’s no hard state
> >> - UDP options are optional - UNLIKE TCP headers and UDP headers, so
> everything can and should be optional as the user desires
> >> (i.e., the UDP options are like the TCP option *field*, not the TCP header
> + option field)
> >>
> >> Here’s a simple version that I can include as an example:
> >>
> >> - user sends a zero-length UDP with the options the user wants to use
> and the ECHO-REQ (including either using OCS or not using OCS)
> >>
> >> - if the user receives an ECHO-RESP with the same options, set a timer and
> use those options until the timer expires
> >>
> >> Users can do this with more than one variation of options set and use any
> one of the sets that is successfully echoed.
> >>
> >> Why is this difficult?
> >
> > If it's so easy then there shouldn't be any issue with specifying the
> > protocol in the draft in normative language and including
> > consideration for various edge conditions and recommendations for
> > default value of protocol parameters such as the timeout in your
> > algorithm.
> >
> 
> We can give examples, but this is user level not UDP. We don’t have or want
> an integrated, normative approach.
> 
> Joe
> 
> 
> > Tom
> >
> >>
> >> Joe