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

[Tom Herbert <[e-mail]>]

On Thu, Jan 2, 2020 at 1:50 PM Joe Touch <[e-mail]> wrote:
>
> 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.
>

Hi Joe,

Where has this been addressed? I see nothing in the draft that
discusses the constraints or requirements like this for soft-state
negotiation.

>
>
> 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".
>
It's simple. Just require that options that cannot be ignored (i.e.
ones with the bit set) can only be sent in LITE+FRAG mode. If the end
point doesn't understand UDP options all it will drop the packet. If
the endpoint does understand UDP options but doesn't understand one
that can't be ignored then the packet will also be dropped. This
procedure works in *all* cases, including unidirectional flows.

>
> 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.

If you're referring to negotiation, I don't see how that could be
considered more general. We've already pointed out one constraint that
doesn't exist for the drop if not recognized bit (the unidirectional
problem). There are likely other cases where negotiation won't work.

Tom

>
> Joe