Re: [tsvwg] Options larger than 255 (was RE: draft-ietf-udp-options issues from IETF 104)

[Gorry Fairhurst <[e-mail]>]

On 18/07/2019, 15:27, Joe Touch wrote:
> Oh - catching up, using LEN as a flag seems a lot simpler (I thought the proposal was to reuse one of the KIND values).
>
> I personally like the use of LEN=255 for this purpose rather than LEN=0; it seems more meaningful (the highest value means “go longer”)…
>
> Joe
That would seem OK for me, and better than using "kind" :-)

Gorry
>> On Jul 18, 2019, at 7:03 AM, Joe Touch<[e-mail]>  wrote:
>>
>> We can - there are a few ways to do this:
>> - pick one KIND and let it say that the next 3 bytes indicate the next KIND and 2-byte length
>> - use a subset of the range of KINDs, reserved in advance, for this purpose
>>
>> Note that code points are already assigned to mimic TCP:
>> 0 is already in use
>> 254 is already reserved for experiments
>> 255 is already reserved, likely to extend the KIND space itself
>>
>> It might be reasonable to use 255 for this purpose because it inherently extends the KIND space anyway.
>>
>> Joe
>>
>>> On Jul 18, 2019, at 5:45 AM, Gorry Fairhurst<[e-mail]>  wrote:
>>>
>>> Ah so, I guess the document editors canm work out what is best to do.
>>>
>>> My wish was to systematically allow larger options to be possible.
>>>
>>> Gorry
>>>
>>> On 18/07/2019, 13:41, [e-mail] wrote:
>>>> Re-,
>>>>
>>>> 0/1 are illegal values. These values MUST NOT be used. A receiver will discard them systematically.
>>>>
>>>> With the proposed approach: 254/255 are legal values... but with a special meaning.
>>>>
>>>> Cheers,
>>>> Med
>>>>
>>>>> -----Message d'origine-----
>>>>> De : Gorry Fairhurst [mailto:[e-mail]]
>>>>> Envoyé : jeudi 18 juillet 2019 14:26
>>>>> À : BOUCADAIR Mohamed TGI/OLN
>>>>> Objet : Re: Options larger than 255 (was RE: [tsvwg] draft-ietf-udp-
>>>>> options issues from IETF 104)
>>>>>
>>>>> I don't mind the choice of codepoint, my understaning was zero was an
>>>>> invalid length, and an easy thing to test in code. Choosing 254 or 255
>>>>> seems less obvious to me, but if there are good reasons, just say...
>>>>>
>>>>> Gorry
>>>>>
>>>>> On 18/07/2019, 12:48, [e-mail] wrote:
>>>>>> Re-,
>>>>>>
>>>>>> Associating a meaning with Len=0 as proposed by Joe may not be
>>>>> intuitive. An alternate approach would be:
>>>>>> * 'Len' only covers the option data field (that is, 'kind' and 'Len'
>>>>> fields are not covered. The overall option length can be easily inferred).
>>>>>> * Associate a meaning with one of the two values we grabbed:
>>>>>>   - 254 or 255: a 16-bit extended length field follows
>>>>>>
>>>>>> Cheers,
>>>>>> Med
>>>>>>
>>>>>>> -----Message d'origine-----
>>>>>>> De : tsvwg [mailto:[e-mail]] De la part de Gorry
>>>>> Fairhurst
>>>>>>> Envoyé : jeudi 18 juillet 2019 12:22
>>>>>>> À : [e-mail]
>>>>>>> Cc : tsvwg
>>>>>>> Objet : Re: [tsvwg] draft-ietf-udp-options issues from IETF 104
>>>>>>>
>>>>>>>> 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