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

[Gorry Fairhurst <[e-mail]>]

On 18/07/2019, 11:11, Gorry Fairhurst wrote:
> 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
P.S. I like the idea to explicitly allow options longer than 255 bytes? 
- This seems useful for fragmentation and would be an easy addition, 
someone suggested using 0 option length to indicate a 16b length field, 
which could make total sense. As in:

https://mailarchive.ietf.org/arch/msg/tsvwg/B4oeZkpagdl4gkAMDCFW7F1A7_8

Gorry