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

[Tim Winter <wintert at acm.org>]

Hi Michael, WG,

Michael Richardson wrote:
>>>>>> "Tim" == Tim Winter <wintert at acm.org> 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.
> 

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