Re: [tsvwg] Rregarding soft-state and UDP options

[Joe Touch <[e-mail]>]

Hi, Tom, 

On 2020-01-02 08:19, Tom Herbert wrote:

> On Wed, Jan 1, 2020 at 1:08 PM Joe Touch <[e-mail]> wrote: 
> 
>> (changing the subject to track the thread)
>> 
>> As we've said before, soft state negotiation is an application layer issue.
> Pushing the problem to the application layer really doesn't help to
> clarify or resolve the issues that have been raised. For instance,
> Mike's question on how soft-state negotiation would work for a
> unidirectional flow is still valid.

We've addressed this too - state negotiation is impossible for
unidirectional flows. Always has been. 

>> 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.
> 
> Neither are UDP options internal to UDP. If the intent is that is the
> draft is adding UDP options to be internal to the protocol in the same
> manner as TCP options are internal to TCP, then one would reasonably
> expect "UDP option negotiation" to be specified in the manner that TCP
> option negotiation is specified for TCP.

The options are carried within UDP and some are internal while others
are not. E.g., FRAG and OCS are strictly internal where others are
primarily useful when passed to the user as "out of band" info (MSS,
REQ/RES, TIME). 

The same is true for TCP options - and TCP options aren't universally
negotiated by TCP. That has to be specified for each option; some are
(and defined as integrated with TCP), some aren't. E.g., TCP-AO isn't
negotiated; it has to be setup in advance. 

>> However - note that soft-state coordination isn't needed to ensure fate sharing of options and option-modified data.
> 
> The terminology you're using is confusing. In this email both
> "soft-state coordination" and "soft state negotiation" are used, but
> the draft doesn't mention those but does use the term "soft-state
> exchange". I don't see any definitions of these and I'm not even sure
> if they all are supposed to mean the same thing. Please clarify this
> in the draft and define the terms to make this precise.

Soft state is a widely known concept. The nuances of coordination vs.
negotiation vs. exchange aren't relevant; they all are used in the same
sense - means to set and refresh state that is considered a hint of
previous context. 

>> 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.
>> 
>> From the draft:
> 
> "The above requirements prevent using any option that cannot be safely
> ignored unless that capability has been negotiated with an endpoint in
> advance for a socket pair."
> 
> That assumes that negotiation works and sufficient which has yet to be
> shown so I see no basis for this statement.

Fair point - that section should discuss the use of soft or hard state
at the user level. Hard user state would provide that assurance. 

> However, I will again
> point out that the "drop unrecognized options bit" in the option type,
> similar to that defined for IPv6 options,

IP is not a model for transport protocols. There's a reason why some
features were added to IP - some of which *remain unused and
unsupported*. 

And you don't want "drop unrecognized options". You want "drop this
ENTIRE PACKET" if the option isn't recognized. 

a) LITE+FRAG with pre and post options accomplishes this *safely* for
both legacy and option-aware endpoints 

b) an option-required" bit *cannot* accomplish this safely for both
legacy and option-aware endpoints. Legacy endpoints already treat all
options as "silently ignore". 

> is sufficient to prevent a
> receiver from ignoring options that cannot safely be ignored (note
> this works in the unidirectional flow case for instance).

LITE_FRAG pre and post options already accomplish this. If the
data-modifying options aren't handled properly then the OCS on the
reassembled result would fail. And legacy receivers will ignore it all. 

The option-required bit never works properly for legacy endpoints unless
you design the option to basically *BE* LITE+FRAG (to bury the user data
in the option). We already have a solution that does that more
generally; there's no need for a bit to accomplish this. 

Joe