[tsvwg] Rregarding soft-state and UDP options

[Joe Touch <[e-mail]>]

(changing the subject to track the thread)

As we’ve said before, soft state negotiation is an application layer issue.

There’s normative text to indicate that this is expected for some uses of these options but it cannot be specified here because it is not internal to UDP.

However - note that soft-state coordination isn’t needed to ensure fate sharing of options and option-modified data. That’s already reliably achieved without soft-state using the existing LITE+FRAG post-reassembly options. The revision integrates LITE+FRAG (as they would not be used independently) but otherwise is basically the same.

Joe

> On Jan 1, 2020, at 12:24 PM, Tom Herbert <[e-mail]> wrote:
> 
> On Wed, Jan 1, 2020 at 11:59 AM C. M. Heard <[e-mail]> wrote:
>> 
>> On Tue, Dec 31, 2019 at 7:09 AM Joe Touch wrote:
>>> 
>>> Thanks for the feedback, Mike.
>> 
>> 
>> ...
>>> 
>>> and (c)
>>> the Option Kind space shall be subdivided into two ranges, one for
>>> options that do not affect the handling of user data and another for
>>> options that do affect the handling of user data.
>>> 
>>> 
>>> That’s a mechanism - one that is not needed to achieve the other goals.
>>> 
>>> Note that (a) and (b) are needed to ensure that user data accompanied by
>>> an option that affects its processing is not delivered to a legacy
>>> receiver (which ignores all options) or to an option-aware receiver
>>> when OCS fails (for in that case, the option-aware receiver also
>>> ignores the options).
>>> 
>>> 
>>> a) and b) are already supported.
>>> 
>>> One way to accomplish (a) would be the version of FRAG proposed in
>>> https://mailarchive.ietf.org/arch/msg/tsvwg/Wv--BLVMPAX6g5umok9BQsXAEGg
>>> (other alternatives have also been discussed). I'll defer further
>>> discussion of the details until after I see the new LITE+FRAG option.
>>> 
>>> Note that (c) is needed to ensure that user data accompanied by
>>> an option that affect its processing is not delivered to an option-aware
>>> receiver that does not recognize the option.
>>> 
>>> 
>>> We have already described how this should be achieved using soft-state negotiation between the endpoints.
>> 
>> 
>> I have reservations about the adequacy of using soft-state negotiation for this
>> purpose. There are two issues I see: (1) the negotiation mechanism in the current
>> draft is, in my opinion, underspecified; (2) it won't work for a unidirectional
>> communication path.
> +1
> 
> More generally, soft-state negotiation has not been specified to show
> it's necessary and sufficient or even robust. Until and unless it's
> well defined, I don't see how it can claim to achieve any goal or be
> referenced in the context of a normative requirement (e.g. from the
> draft: ">> UDP options that rely on soft-state exchange MUST allow for
> message reordering and loss"-- where presumably "soft-state exchange"
> is the same concept as "soft state negotiation" which itself is not
> even clear). This issue has been brought up several times on the list
> and also at the WG meeting at IETF104. From
> https://datatracker.ietf.org/doc/minutes-104-tsvwg/:
> 
> Tom: The idea of option negotiation is unclear in the draft, and
> needed for options that are not stateless. How do you deal with
> unknown options - startling TCP-style negotiated options and stateless
> mechanisms as in IPv6.
> Gorry (as chair): I agree that clarity is important, please discuss
> on the list with Joe - the text needs to be clearer.
> 
> The answer to #2, and potential other cases where trying to force
> negotiation on an inherently stateless protocol, should follow from a
> normative specification of what soft-state negotiation is and how it
> works.
> 
> Tom
> 
> 
> 
> 
>> I'll give myself a homework assignment to be done while I
>> await the new FRAG+LITE text: prepare text to fix (1) and come up with a
>> convincing use case for (2).
>> 
>> Thanks & regards,
>> 
>> Mike Heard
>