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

[Joe Touch <[e-mail]>]

Tom, 

On 2019-07-17 08:35, Tom Herbert wrote:

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

Those are hard-state protocols; we're dealing with UDP. I think the U
keeps being forgotten. 

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

Again, that's what the KIND codepoint is for. 

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

We can't in the current approach. Even if we hit a KIND limit, we can
define one of the last KINDs as "use the next byte as extended KIND". 

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

TCP option space is limited exactly because of the fixed header
structure you keep advocating. 

The current udp-opt structure has no such limit, but you complain that
this creates a DOS vector. 

Hmm... 

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

This isn't IP. 

And "trailers" is where we are unless we send packets twice, which we
don't want to do. (there's no such thing as a "header" unless there is
zero data, which means legacy receivers won't see them, which means we
need to send two packets) 

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

Here's an example: 

IP was assigned one Ethernet codepoint, 0x0800 
IP has a version field, which was 4 at the time. 

When IPv6 was created, it complied with IP's generic structure and
version indication, using v6 in that field. 

However, a new Ethernet codepoint was assigned - 0x86dd 

This additional codepoint was assigned because *ethernet hardware at the
time* was parsing IP packets, but not fast enough to do the right thing
for IPv4 and IPv6 at the same time. 

So now we're stuck with two codepoints when we should have had one. 

> - Integration into a host stack
> 
>> what's the goal here?
> 
> It's "rough consensus and _running_ code"

I'm being more specific - "integration into the host stack" - are you
asking for running code (Gorry has some). Are you asking for design
advice in the doc (that's not appropriate). Are you asking for something
else? 

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

Accelerators change. Common ones today won't be common in 10 years
necessarily. 

Designing for "accelerators" (including zero-copy) is fine, but it
shouldn't be tied to too many details of today's implementations. 

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

I can point to car buying advice sites too, but they're no more relevant
for us. 

> IMO it's a mistake to just ignore them considering that these
> are the devices the will be transporting the packets.

Yes. Transporting. 

Routers shouldn't be this deep into a transport protocol; if they are,
they're not routers and not limited this way anyway. 

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

Remember that ALL routers dropped IPv6 when it was introduced. 

We should fix what's broken, not continue to try to design around it. 

And as long as we lack compliance enforcement (e.g., via an endorsement
mechanism), we should stop trying so hard to write our way around what
are clearly bugs. 

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

It isn't for several reasons: 

a) there has been no consensus so far on substantive changes 

b) the ID queue is closed 

As to source code, that's Gorry's decision on how and where to post. 

Joe