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

[Joe Touch <[e-mail]>]

Tom,

Some of these are design assumptions; some of these are design *approaches*. Can we please focus on the former? I’ll try for a few below:

> - Method to disambiguate legacy uses of surplus space

sure.

> - Specification for options negotiation

perhaps? a method to determine which options are supported

> - Denial of Service mitigations

perhaps? ways to use of options for DOS (we’re not trying to design for anti-DOS UDP use in general)

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

I don’t see a way to make this a design goal; UDP is unreliable and we can’t know where or why packets are dropped per se

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

it’s already extensible with the KIND codepoint space; given UDP lacks version numbers, it would not be useful to impose them on options alone

> - Protocol headers versus protocol trailers

that’s a mechanism; what behavior are you describing?

> - Implementation and deployment considerations

what is the design goal here? maximizing initial deployment probability of success? and if so, at what cost to future use?

i.e., this seems useful ONLY if it takes into consideration the ephemeral nature of the current deployment environment

>   - Integration into a host stack

what’s the goal here?

>   - Interaction with common accelerations for UDP

again, what’s the goal? again, would this be maximizing for the short term?

>   - Middleboxes interactions (particularly guidelines for protocols
> suggested in https://datatracker.ietf.org/meeting/104/materials/slides-104-wgtlgo-forwarding-plane-realities-00 <https://datatracker.ietf.org/meeting/104/materials/slides-104-wgtlgo-forwarding-plane-realities-00>)

Those are ROUTER guidelines; middleboxes that want to look inside transport protocols would already fail if limited to many of these constraints.

And many don’t apply from the start for us:
- we do not have fixed offset (we’re already at a variable location when used with legacy-compatible data)
- we do not have a fixed header structure (even if we assume we start with either OOC or CCO and even length, there’s not much more; the rest is necessarily a chain)

And what about some of that advice? not being a draft, its advice wasn’t widely discussed or vetted, and in some places is wrong IMO. In fact, I suspect you would agree, because that advice specifically says:
- avoid checksums over the entire packet
- make checksums optional

These are both points you’ve argued against here.

(and, as a side note, another case in point, the idea of not going through the pipeline twice for tunnel exit and entry is basically denying that tunnels are inherently a kind of recursion that needs to be fully reentrant, i.e., it would be much safer to claim “tunnel entry and exit MUST behave EXACTLY as if the packet traverses the pipeline and all its processing EXACTLY twice: once for exit and once for entry, and that information between the two be limited to the context contained in the packet only”)

>   - Running code that implements UDP option to evaluate and guide
> above. Preferably open source in Linux since that is the most deployed
> end host OS that would support UDP options

There are at many more OSes that are more widely deployed (e.g., in cellphones, etc.). We should not design for the short term.

And Gorry’s team has running code.

Joe