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

[Joe Touch <[e-mail]>]

> 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] <mailto:[e-mail]>> wrote:
> Updating the subject line...
> 
>> On Jul 10, 2019, at 8:56 PM, Tom Herbert <[e-mail] <mailto:[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?

Joe