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

[Tom Herbert <[e-mail]>]

On Wed, Jul 17, 2019 at 7:58 AM Joe Touch <[e-mail]> wrote:
>
> 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
>
It's a common problem to deal with the situation where the network
drops packets with new protocols or formats it hasn't seen before.
Some kind of falback is generally required to a rudimentary protocol.
See Happy Eyeballs for TCP, QUIC fallback to TCP, etc.

> - 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

It's generally useful to have something that allows version or
alternative formats. For instance, five years from now someone may
discover a fatal flaw in UDP Options deployment that makes them
unusable in that format. Or maybe options become so popular that we
run out of option space. For example, TCP option space is quite
limited and has caused problems with extensibility-- if there was a
version number in the protocol we could define a new version to allow
larger options space and still use protocol number 6. Having the
ability to fundamental change the format is very useful for the cost
of a few bits and is common in protocols.
>
> - Protocol headers versus protocol trailers
>
>
> that’s a mechanism; what behavior are you describing?

The use of protocol trailers is a design decision. The consequences of
taking this path may be significant since it is a departure from
convention for nearly all other IP protocols.

>
> - 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
>
I'm not sure how ephermeral deployment is. Consider that it "only"
took IPv6 twenty years to get to deployment. If you design it a
protocol for an idealized Internet and ignore reality it won't get
deployed.

>   - Integration into a host stack
>
>
> what’s the goal here?

It's "rough consensus and _running_ code"

>
>   - Interaction with common accelerations for UDP
>
>
> again, what’s the goal? again, would this be maximizing for the short term?
>
Deployability. Accelerations have existed since the 90's and will be
with us with the next thirty years. There's nothing short term about
them and it's not like it's a stop gap we wait for CPU performance and
power to catch up with network speeds.

>   - Middleboxes interactions (particularly guidelines for protocols
> suggested in 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.

Yes, but these are guidelines offered which is more than we've had
before. IMO it's a mistake to just ignore them considering that these
are the devices the will be transporting the packets. And as we've
seen all too often, it routers or middleboxes for whatever reason
decide to arbitrarly drop packets, say a firewall drops packets with
UDP options because it doesn't have visibiity into the surplus space,
then the protocol is doomed.
>
> (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.
>
I'm not how this is designing for the short term. There's over 2.5
billion users of Linux on smart phones for instance, i don't think
it's going away any time soon.

> And Gorry’s team has running code.

Great. Please include a reference to the source code in the next
update of the UDP options draft which I assume is forthcomoing.

Tom

>
> Joe
>