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

[Derek Fawcus <[e-mail]>]

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.

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.

Both cases can be used depending upon the application in question.

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.

So in general there is no fate sharing between the options within a given
packet (they can be understood or not per option), but there is fate sharing
between the presence of any options and application data in form 2.

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.

DF