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

From: <[email-masked]>
Date: Thu, 18 Jul 2019 11:48:24 +0000

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:[email-masked]] De la part de Gorry Fairhurst
> Envoyé : jeudi 18 juillet 2019 12:22
> À : [email-masked]
> 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

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 18 Jul 2019 13:45:03 +0100

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, [email-masked] 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
>
>> De : Gorry Fairhurst [mailto:[email-masked]]
>> 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, [email-masked] 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).

---

From: Joe Touch <[email-masked]>
Date: Thu, 18 Jul 2019 07:03:54 -0700

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 <[email-masked]> wrote:
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 18 Jul 2019 07:27:54 -0700

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 <[email-masked]> wrote:
>

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 18 Jul 2019 15:29:17 +0100

> 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”)…
That would seem OK for me, and better than using "kind" :-)

Gorry
>> On Jul 18, 2019, at 7:03 AM, Joe Touch<[email-masked]>  wrote:
>>
>>> On Jul 18, 2019, at 5:45 AM, Gorry Fairhurst<[email-masked]>  wrote:
>>>

---

From: <[email-masked]>
Date: Thu, 18 Jul 2019 14:32:11 +0000

Joe, 

Kind extension is a distinct issue from length extension. I would dissociate how this is provided.

We don't need to extend the kind space to allow for larger options!

Cheers,
Med

> De : Joe Touch [mailto:[email-masked]]
> Envoyé : jeudi 18 juillet 2019 16:04
> À : Gorry (erg)
> Cc : BOUCADAIR Mohamed TGI/OLN; [email-masked]
> Objet : Re: [tsvwg] Options larger than 255 (was RE: draft-ietf-udp-

---

From: <[email-masked]>
Date: Thu, 18 Jul 2019 14:37:21 +0000

Deal!

Cheers,
Med

> Envoyé : jeudi 18 juillet 2019 16:28
> À : Gorry (erg)
> 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
>

---

From: Raffaele Zullo <[email-masked]>
Date: Thu, 18 Jul 2019 17:00:19 +0100

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
> 
>> It might be reasonable to use 255 for this purpose because it 
>> inherently extends the KIND space anyway.
>> 
>> Joe
>>

---

From: Tom Herbert <[email-masked]>
Date: Thu, 18 Jul 2019 09:13:06 -0700

> My wish was to systematically allow larger options to be possible.

Gorry,

This is a good example of how a variant/type field in the surplus
header allows the format to be extensible. If a large option length is
needed then a variant could be created for that. Since the format is
extensible we don't have to specify all possibilities for the protocol
up front.

Tom

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 18 Jul 2019 17:21:08 +0100

On 18/07/2019, 17:13, Tom Herbert wrote:
> On Thu, Jul 18, 2019 at 5:45 AM Gorry Fairhurst<[email-masked]>  wrote:
Yes, I see that as an option. In relaity though for this case we have a 
1 byte len or a 2 byte len. Personally, I would not be in favour of a 
longer length... that another story (see, 
draft-jones-6man-historic-rfc2675-00) ;-)

Gorry

---

From: Tom Herbert <[email-masked]>
Date: Thu, 18 Jul 2019 09:34:28 -0700

> draft-jones-6man-historic-rfc2675-00) ;-)

Probably not just length field that will be a target :-). For
instance, I could imagine the Geneve proponets might want longer type
fields (e.g. maybe they want to move some Geneve options into UDP
options for some reason).

I am curious though, how would options bigger than 255 bytes help? It
doesn't seem like this was ever an issue with other dataplane
protocols that have options.

Tom

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 18 Jul 2019 17:44:52 +0100

On 18/07/2019, 17:34, Tom Herbert wrote:
> On Thu, Jul 18, 2019 at 9:21 AM Gorry Fairhurst<[email-masked]>  wrote:
So one place where options > 255 help, is when you put a fragment 
payload (upto however big you can send in a PMTU) into an option to 
transport it, so that the fragment payload and header arrive and are 
processed together - likely this results in a zero-length UDP datagram 
and an option field.

Gorry