Subject: Re: [Roll] [roll] #8: DIO Option Length

From: Tim Winter <[email-masked]>
Date: Sun, 01 Nov 2009 18:21:47 -0500

Hi Julien, WG,

Yes, the draft-ietf-roll-routing-metrics-03 suggests that the metrics may
exceed 255 bytes, and so the DIO suboption for DAG Metric Container drives
the overall requirements for suboption length.

If we use 16bits for length, maybe 1 byte is `wasted' to specify a short ( <
255 bytes) option.

If we use 8bits for length in units of 8bytes, only one byte is used for
suboption length in all cases, so the second byte is saved.  But the
suboption itself must pad for [0-7] bytes to meet the 8 byte boundary.  In
the first case, 0 byte of padding is required, one byte is saved from
encoding the suboption length, and one byte is saved overall.  In the second
case, 1 byte of padding is used and one byte is saved from the suboption
length, breaking even.  In the 6 other cases, more bytes are used for
padding than are saved in encoding the suboption length.

We don't know anything yet about a typical distribution of lengths for
suboptions, in particular the DAG Metric Container.  So perhaps this
discussion could be premature.  But, given that in the 8byte encoding case
we use more bytes in 6/8 of the possible cases, my opinion is that it is
better to stick with a 16-bit suboption length in units of bytes.

Thoughts?

Did you have another architectural driver in mind?

-Tim

Julien Abeille (jabeille) wrote:
> Hi all,
>  
> do we expect DIO suboptions to be longer than 255 bytes? if yes would it
> be ok to spell the length in multiple of  8bytes instead of bytes (value
> of 1 means 8 bytes, like in ND). The target is to use 8 bits instead of 16.
>  
> Thank you,
> Julien
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Mon, 2 Nov 2009 10:29:33 +0100

Hi Tim,

Thanks for answering. I am not sure I get your point about padding.
Removing one byte does not necessarily mean that it will have to be
padded, e.g. if the option is padding 7 bytes with 2 bytes length, it
will not pad anything with one byte length. 

But I think you are correct that it may be a bit early to discuss all
this ;-)

Some suboptions should be moved to options (separate thread, DIO base
option is not optional hence should not be an option. Makes sense?).

General related question: for the cases where we need suboptions (metric
container), do we want suboptions to be 8 bytes aligned? Or only options
should be 8 bytes aligned?

Best,
Julien

> -----Original Message-----
> From: Tim Winter [mailto:[email-masked]] 
> Sent: lundi 2 novembre 2009 00:22
> To: Julien Abeille (jabeille)
> Cc: ROLL WG
> Subject: Re: [roll] #8: DIO Option Length
> 
> Hi Julien, WG,
> 
> Yes, the draft-ietf-roll-routing-metrics-03 suggests that the 
> metrics may exceed 255 bytes, and so the DIO suboption for 
> DAG Metric Container drives the overall requirements for 
> suboption length.
> 
> If we use 8bits for length in units of 8bytes, only one byte 
> is used for suboption length in all cases, so the second byte 
> is saved.  But the suboption itself must pad for [0-7] bytes 
> to meet the 8 byte boundary.  In the first case, 0 byte of 
> padding is required, one byte is saved from encoding the 
> suboption length, and one byte is saved overall.  In the 
> second case, 1 byte of padding is used and one byte is saved 
> from the suboption length, breaking even.  In the 6 other 
> cases, more bytes are used for padding than are saved in 
> encoding the suboption length.
> 
> We don't know anything yet about a typical distribution of 
> lengths for suboptions, in particular the DAG Metric 
> Container.  So perhaps this discussion could be premature.  
> But, given that in the 8byte encoding case we use more bytes 
> in 6/8 of the possible cases, my opinion is that it is better 
> to stick with a 16-bit suboption length in units of bytes.
> 
> Thoughts?
> 
> > do we expect DIO suboptions to be longer than 255 bytes? if 
> yes would 
> > it be ok to spell the length in multiple of  8bytes instead 
> of bytes 
> > (value of 1 means 8 bytes, like in ND). The target is to 
> use 8 bits instead of 16.
> >  
> > Thank you,
> > Julien
> > 
> > 
> >

---

From: JP Vasseur <[email-masked]>
Date: Mon, 2 Nov 2009 14:13:15 +0100

On Nov 2, 2009, at 12:21 AM, Tim Winter wrote:

> metrics may

+1

---

From: Michael Richardson <[email-masked]>
Date: Thu, 05 Nov 2009 13:36:56 -0500

>>>>> "Tim" == Tim Winter <[email-masked]> writes:
    Tim> Yes, the draft-ietf-roll-routing-metrics-03 suggests that the
    Tim> metrics may exceed 255 bytes, and so the DIO suboption for DAG
    Tim> Metric Container drives the overall requirements for suboption
    Tim> length.

    Tim> If we use 16bits for length, maybe 1 byte is `wasted' to
    Tim> specify a short ( < 255 bytes) option.

    Tim> If we use 8bits for length in units of 8bytes, only one byte is
    Tim> used for suboption length in all cases, so the second byte is
    Tim> saved.  But the suboption itself must pad for [0-7] bytes to
    Tim> meet the 8 byte boundary.  In the first case, 0 byte of padding
    Tim> is required, one byte is saved from encoding the suboption
    Tim> length, and one byte is saved overall.  In the second case, 1
    Tim> byte of padding is used and one byte is saved from the
    Tim> suboption length, breaking even.  In the 6 other cases, more
    Tim> bytes are used for padding than are saved in encoding the
    Tim> suboption length.

    Tim> We don't know anything yet about a typical distribution of
    Tim> lengths for suboptions, in particular the DAG Metric Container.
    Tim> So perhaps this discussion could be premature.  But, given that
    Tim> in the 8byte encoding case we use more bytes in 6/8 of the
    Tim> possible cases, my opinion is that it is better to stick with a
    Tim> 16-bit suboption length in units of bytes.

I say either 8bits in units of 8bytes, or 16 bits in byte units.

I somewhat favour the second one (16-bits). 
If the second, then one of the options that we should consider is the
"compress" option, which would contain many options.
Otherwise, we may want to consider use of the IPCOMP header in
constrained situations.

This may well simply solve the problem.    I propose that this is
premature optimization.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 05 Nov 2009 13:40:06 -0500

>>>>> "Julien" == Julien Abeille <(jabeille)" <[email-masked]>> writes:
    Julien> Some suboptions should be moved to options (separate thread,
    Julien> DIO base option is not optional hence should not be an
    Julien> option. Makes sense?).

    Julien> General related question: for the cases where we need
    Julien> suboptions (metric container), do we want suboptions to be 8
    Julien> bytes aligned? Or only options should be 8 bytes aligned?

  Our options and suboptions should be identical.
  We should also not re-invent the wheel.  It should either replicate
the IPv6 extension header (if that's what we want), or should replicate
another protocol, e.g. radius(RFC2865):

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                         Authenticator                         |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Attributes ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-

....

   A summary of the Attribute format is shown below.  The fields are
   transmitted from left to right.

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
   |     Type      |    Length     |  Value ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

---

From: Tim Winter <[email-masked]>
Date: Mon, 09 Nov 2009 07:25:00 -0500

Hi Michael, WG,

> This may well simply solve the problem.    I propose that this is

For now then we should leave the text unchanged for -05.  Perhaps we may
revisit this later when we have more basis to optimize.

Thanks,

-Tim