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

[Gorry Fairhurst <[e-mail]>]

On 18/07/2019, 11:01, Derek Fawcus 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.
>
> 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
Close to what I assumed.

Gorry