Re: [tsvwg] Alternative version of the UDP FRAG option

[Tom Herbert <[e-mail]>]

On Mon, Mar 18, 2019, 7:15 PM Joe Touch <[e-mail]> wrote:

>
>
> On Mar 18, 2019, at 7:11 PM, Tom Herbert <[e-mail]> wrote:
>
>
>
> On Mon, Mar 18, 2019, 7:00 PM Joe Touch <[e-mail]> wrote:
>
>>
>> On 3/18/2019 6:33 PM, Tom Herbert wrote:
>>
>>
>>
>> On Mon, Mar 18, 2019, 5:32 PM Joe Touch <[e-mail]> wrote:
>>
>>> I'm trying to catch up with all the proposals and create a summary.
>>>
>>> That said:
>>>
>>> 1) the notion of soft state and its impact on the protocol is already
>>> mentioned in the draft, as are its limitations
>>>
>>>
>>> Joe,
>>
>> Is a normative description of UDP option negotiation forthcoming?
>>
>> We decided on soft state a while ago instead. That's already in the
>> current descciption.
>>
>>
>> 2) we definitely need to stick to some design principles. Some are
>>> already proposed in the draft, but the discussion of late has strayed
>>> far afield of those. In particular, the draft already has a list of
>>> rules for when to drop packets based on various option properties.
>>>
>>
>> But other existing standard protocols that have options already use a
>> certain set design principles (like skip option bit in HBH and dest
>> options). It's not clear to me at least why those aren't being followed.
>>
>> Because we're starting with "all options can be silently ignored" to
>> support consistency with legacy receivers (at least until soft state is
>> established) . That's NOT where other protocols start. There are several
>> other places where we diverge (trailer, optional core checksum, etc.).
>>
>
> Then you can only send options that can be ignored.
>
>
> You can’t force the behavior a receiver to act other than a legacy UNTIL
> you get soft-state confirmation otherwise, yes.
>


> If the idea is that soft state somehow allows sending of options that
> can't be ignored, that's fine, but we need the normative description of how
> soft state works to evaluate if the requirements are can be meant. This has
> to include edge condition handling. UDP is stateless, so inferring
> connection state from a 5-tuple is perilous. For instance, after a NAT
> state eviction one side sees an unchanged tuple, and the other side sees a
> completely new tuple and might even be a different host thanks to VIP. How
> does soft state handle that?
>
>
> It won’t work as you want (force drop) until the next ‘refresh’. That’s
> how soft-state works.
>

There's no guarantee between consecutive packets in UDP that the
destination is the same host. Important options must always be sent in a
format that legacy receivers drop. That is rule #1. Rule #2 is that
receivers must drop important options they don't understand. That's simply
addressed by the skip/drop bit in type. Rule #3 is that important options
need integrity check, hence a checksum. These rules are sufficient to meet
the requirements without depending on an external control plane or
configuration.



> Joe
>
>