Re: [tsvwg] Comments on ietf-106-tsvwg-udp-options

[Tom Herbert <[e-mail]>]

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.
>
>
> Thank you for the reply.
>
>>
>> Regarding the MUST SUPPORT flag part:
>>
>> On Dec 29, 2019, at 4:28 PM, C. M. Heard <[e-mail]> wrote:
>> ...
>> I'll comment when the updated text appears.
>>
>>>
>>> - regarding MUST SUPPORT flag
>>>
>>> The only need for this flag has been data that must not be received by
>>> legacy endpoints, e.g., compressed. That's already achievable more
>>> flexibly using the FRAG+LITE with pre and post reassembly options. Can
>>> anyone show a case this doesn't cover?
>>
>>
>> I disagree with this characterization, both of the proposed change and
>> the purpose that it serves.
>>
>>
>> I made two claims:
>> 1. the need is for data that shares fate with the option on legacy endpoints (is ignored)
>> 2. the need is already addressed by pre and (notably) post-reassembly options in FRAG+LITE
>> I was assuming FRAG that supports the degenerate case of a single fragment.
>>
>> During the e-mail discussion in the weeks prior to IETF 105, I proposed
>> an additional design requirement to supplement those set forth in
>> https://mailarchive.ietf.org/arch/msg/tsvwg/27I9XF-mEdXagcEPah22482v65c
>> (and also in the IETF 105 presentation slides).* It was:
>>
>> - Any option that affects the handling of the user data must share fate
>> with that user data,…
>>
>>
>> As noted above, already supported by FRAG+LITE.
>>
>> in the following sense: either the option and the
>> user data are processed together, with the data and option indication
>> being delivered to the user if the processing succeeds, or else both are
>> discarded, and nothing is delivered to the user. This requirement
>> applies to all receivers, legacy or otherwise.
>>
>>
>> That’s accomplished by post-reassembly options.
>>
>> I do not believe that the spec, either in previous incarnations or in
>> its current (-08) form, provides a way to satisfy this requirement. In
>> order to fill that (perceived) gap, I proposed that (a) there shall be
>> a means to transport user data in the options area with OCS coverage;
>>
>>
>> As noted in the update, OCS covers the entire option area now (which thus includes FRAG+LITE).
>>
>> (b) user data shall be transported using that mechanism whenever it is
>> accompanied by an option that affects how it is processed;
>>
>>
>> The user makes this decision by selecting to use an option “post reassembly”.
>
>
> OK, I'll wait for the promised update to FRG+LITE appears before I make further comments.
>>
>> 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