Subject: [core] header option encoding

From: Peter Bigot <[email-masked]>
Date: Thu, 22 Jul 2010 10:55:11 -0500

Out of curiosity, I just wrote stub C routines to encode and decode options
and measured the size of space-optimized MSP430 object code.

Between delta management, fencepost processing for large deltas, and
variable option lengths, the code sizes are 66 bytes to process the options,
and 190 to encode them.

In contrast, an encoding that uses one byte for the option code, one byte
for the length, and the value requires 28 bytes to process and 44 bytes to
encode them.

Of course, this is strongly affected by what "process" means: for the
purposes of this test I simply summed the observed option types and lengths,
to ensure the values were correctly decoded.  My code may be poor or wrong,
since I only compiled it and didn't run it; attached for anybody who wants
to optimize it.

Are we locked to the current option encoding?  OK if we are, but a 135%
space penalty for decoding and a 330% penalty for encoding is high for
something that saves at most one byte per encoded option per message.

00000000 g     F .text  0000003e process_options
00000086 g     F .text  000000be encode_option
0000003e g     F .text  0000001c alt_process_options
0000005a g     F .text  0000002c alt_encode_option

Peter

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 22 Jul 2010 18:03:21 +0200

Peter,

this is great input!

Nice to have a number on that.

Spending 184 bytes of code to save a couple bytes per message sounds like a good tradeoff to me.
6LoWPAN HC-07 is probably more expensive :-)
(In simple nodes, the number will be slightly smaller as you don't need to do fencepost processing.)

Gruesse, Carsten

---

From: Peter Bigot <[email-masked]>
Date: Thu, 22 Jul 2010 11:22:46 -0500

Why do you think small devices won't need to do fencepost processing?
Doesn't that depend on the options they need to process, and what's in the
packets they get sent?

Peter

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 22 Jul 2010 18:39:16 +0200

> Why do you think small devices won't need to do fencepost processing?  

Because all the options they need to send will be numbered 15 or less.

> Doesn't that depend on the options they need to process, and what's in the packets they get sent?

Yes (for sending).
No (for receiving, as 14/28/etc. are just elective options that are ignored, so the fencepost processing is zero code on reception).

Gruesse, Carsten

---

From: Peter Bigot <[email-masked]>
Date: Tue, 27 Jul 2010 07:46:29 -0500

I've seen no argument that supports the position that all options needed by
small device will be numbered 15 or less.  We have not yet defined all
options, and have not yet formalized the need for application-specific
options which will probably not be within this range.

Peter

On Thu, Jul 22, 2010 at 11:39 AM, Carsten Bormann <[email-masked]>wrote:

> No (for receiving, as 14/28/etc. are just elective options that are
> ignored, so the fencepost processing is zero code on reception).
>
> Gruesse, Carsten
>
>

---

From: Peter Bigot <[email-masked]>
Date: Tue, 27 Jul 2010 07:46:34 -0500

So far, only Carsten and I have weighed in on this publicly, and I've been
re-sensitized to the presence of what I believe to be unnecessary complexity
in CoAP as currently drafted.  I'd like a consensus measure on the question
of whether options should be encoded as:

   - a single octet encoding a delta and a length, with longer lengths
   indicated by a flag value;
   - two octets encoding the option value and the length

Comments in the WG, or a hum measure at the CoAP session (accepting the
disenfranchisement of those who cannot be physically present: chime in here
if so), would help settle the question.

Peter

---

From: Peter Bigot <[email-masked]>
Date: Tue, 27 Jul 2010 08:03:54 -0500

That for consensus; for "running code" I'll undertake to provide, later
today, a variant of my Python system which supports the alternative option
encoding.  I'll also add support for larger option type codes, so others can
evaluate the fencepost processing and other issues.  I suspect that hasn't
been adequately tested.

Peter

On Tue, Jul 27, 2010 at 7:46 AM, Peter Bigot <[email-masked]> wrote:

> On Thu, Jul 22, 2010 at 10:55 AM, Peter Bigot <[email-masked]>wrote:
>
>> Out of curiosity, I just wrote stub C routines to encode and decode
>> options and measured the size of space-optimized MSP430 object code.
>>
>> to ensure the values were correctly decoded.  My code may be poor or
>> wrong, since I only compiled it and didn't run it; attached for anybody who
>> wants to optimize it.
>>