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

[Joe Touch <[e-mail]>]

> On Jul 11, 2019, at 9:46 AM, Tom Herbert <[e-mail]> wrote:
> 
>> On Thu, Jul 11, 2019 at 8:55 AM Joe Touch <[e-mail]> wrote:
>> 
>> 
>> 
>> 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]> wrote:
>>> 
>>> Updating the subject line...
>>> 
>>>> On Jul 10, 2019, at 8:56 PM, Tom Herbert <[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?
> 
> If it's so easy then there shouldn't be any issue with specifying the
> protocol in the draft in normative language and including
> consideration for various edge conditions and recommendations for
> default value of protocol parameters such as the timeout in your
> algorithm.
> 

We can give examples, but this is user level not UDP. We don’t have or want an integrated, normative approach. 

Joe


> Tom
> 
>> 
>> Joe