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

[Tom Herbert <[e-mail]>]

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

Joe
>