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

[Joe Touch <[e-mail]>]

> On Jan 2, 2020, at 2:37 PM, Tom Herbert <[e-mail]> wrote:
> 
> 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.

Sec 13 makes it clear that there is no way to establish state for the first message.

That section also notes that options must be silently droppable until confirmed. it should be clear that a unidirectional flow can’t be confirmed.

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

OK, we can include that reminder. 

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

Negotiation doesn’t *have to work*. But if you don’t negotiate some sort of state, you can’t use options that can’t be silently dropped - regardless of whether they modify contents or not. That’s already stated in Sec 13.

I’ll certainly look at that section and revise to be more clear.

Joe