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

[Raffaele Zullo <[e-mail]>]

Hello,
I agree.
I proposed LEN+0 just because 0 and 1 were not usable Length values,
but 255 may be a better choice.

Cheers,
Raffaele Zullo



On 2019-07-18 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
> 
>> 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
>>> 
>>