Re: [tsvwg] draft-ietf-udp-options issues from IETF 104

[Joe Touch <[e-mail]>]

> On Jul 18, 2019, at 3:01 AM, Derek Fawcus <[e-mail]> wrote:
> 
> On Wed, Jul 17, 2019 at 05:18:10PM -0700, Joe Touch wrote:
>>> On Jul 17, 2019, at 1:13 PM, C. M. Heard <[e-mail]> wrote:
>>> As I have explained previously, fate-sharing, while unachievable with the protocol trailer format but can be achieved with a protocol header packet format.
>> 
>> It really can’t - again, you can’t force a receiver to act as options-aware.
> 
> That is not what I understand Mike to mean by fate sharing, and his proposed framing.
> 
> I see it as two cases:
> 
> 1) Packet with legacy UDP data, and UDP options.
> 
> In this case there is no fate sharing, a legacy receiver will only see the
> UDP data, and the options will be lost.

This is how legacy data is handled in the current draft, per sec 8.

> 2) Packet with zero-length UDP data, and UDP options carrying application data and options.
> 
> In this case a legacy receiver will simply receive a zero length UDP packet.
> However a new receiver will have fate sharing for the application data and options.

This is already how LITE data is handled in the current draft, per sec 8.

> ...In a request / response scenario, one can initially send packets in form 1,
> and then switch to form 2 if the responder supports such, maintaining soft
> state as necessary.
> 
> Mike DNS example being one where a request would be send in form 1,
> a legacy response would be received as pure UDP,
> but a DNS server on a new host could send its response in form 2.

Right. And the first packet only needs to include OCS. If OCS is received correctly, then the server can respond using FRAG directly (no need for FRAG+LITE).

> So in general there is no fate sharing between the options within a given
> packet (they can be understood or not per option),

Yes, but that opens a new can of worms. Currently, we shut that can by declaring that only a subset of the initially defined apps are ever “required to implement”; everything else MUST be designed to allow options-aware endpoints to silently ignore them if not implemented.

> but there is fate sharing
> between the presence of any options and application data in form 2.

Yes, but that’s just what LITE already does…

The point I was making is that there is no way to have both forms at the same time.

Either options share fate with data ONLY FOR OPTIONS-AWARE endpoints,
or legacy and options-aware endpoints share fate BUT OPTIONS ARE THEN OPTIONAL TO EVERYONE (technically, including options-aware endpoints).

> Mike was also further suggesting to carve the option id space such that there
> is a signalling bit.  Doing so would then allow for fate sharing across options
> if at least 1 'discard if not understood' option was present.

Oh, no - that’s a huge can of worms because there’s another bit to set: “all or none” or “ignore individually”.

Then what do you do if you have three that you want required “all or none as a set”. or ignored that way?

The control bits get out of control very fast…

Also, note that IPv6 included bits to encode whether ICMPs were sent (and whether the source is multicast).  We haven’t addressed that can of worms yet either...

Joe