Re: [tsvwg] design assumptions - draft-ietf-udp-options

["C. M. Heard" <[e-mail]>]

On Wed, Jul 17, 2019 at 7:27 AM Tom Herbert wrote:
> On Tue, Jul 16, 2019 at 5:31 PM Joe Touch wrote:
> >
> > Getting back to the core design assumptions:
> >
> > 1- support options
> > 2- allow at least some options to be silently ignored by legacy
> >    receivers (to enable ‘“optionally enhanced” exchanges)
> > 3- allow at least some options to be required
> > 4- allow the options themselves to be protected
> > 5- support for fragmentation/reassembly
> > 6- support for MTU discovery
> > 7- support (optional?) middlebox checksum/payload length bug traversal
> > 8- support LITE, i.e., where some of the payload is not covered by at
> >    least some checksum processing
> >
[...]
> >
> > Are there any other design requirements?
> >
>
> - Method to disambiguate legacy uses of surplus space

+1

> - Specification for options negotiation

I don't think we need a full specification for options negotiation, e.g.,
something along the lines of what's done for PPP in RFC 1661. There was
a message about a week ago that I think captured what's needed very well:

On Thu, Jul 11, 2019 at 9:30 AM Wesley Eddy wrote:
> The way I understand it, this is supposed to be handled by the
> application (or other protocol) on top of UDP.
>
> Section 9 talks about how the API needs to be extended for the
> application to indicate receive options that are required, and which
> ones should be included on a sent datagram.
>
> Maybe that section should also just explicitly say that the application
> protocol (either by its definition or in its signalling) is supposed to
> work out compatible sets of sent and received options, based on what the
> application needs.  I think that would solve the question you raise.

In other words, the udp-options spec should be seen as a toolbox for
application protocols, i.e., it should provide a means for application
protocols to carry out UDP option negotiation. This could take the form
of a (set of) general-purpose option negotiation options, or it could be
achieved by having each option specification say how its use is negotiated.

> - Denial of Service mitigations

+1

> - Fallback mechanism to use when intermediate devices drop packets
>   with UDP surplus space

That's out of scope

> - Extensibility, i.e. something like version number for the protocol

Already provided

> - Protocol headers versus protocol trailers

That's an implementation decision, not a design requirement. And it may
not be one or the other; indeed, I believe that BOTH are needed in order
to satisfy all

> - Implementation and deployment considerations
>    - [ Ease of] Integration into a host stack
>    - [ Ability to take advantage of] with common accelerations for UDP

I see this as a factor to take into account when deciding between
different means to achieve the requirements, or as a consideration
that may lead to a requirement being dropped. IMO, it is not in and
of itself a functional requirement of the protocol.

>    - Middleboxes interactions

Support for middlebox checksum/payload length bug traversal is already
on the list, and I agree that it should NOT be an optional design feature
(though it may be optional to use, turned off at your own risk). Beyond
that, if you mean enabling DPI, that should be an explicit non-goal.

>    - Running code that implements UDP option to evaluate and guide above.

That's a desirable goal -- but it is not not a design requirement.

Mike Heard