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

[Joe Touch <[e-mail]>]

> 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] <mailto:[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] <mailto:[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. 

Joe