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.