Re: [Roll] [roll] #8: DIO Option Length
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



>>>>> "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.

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



Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.