Subject: [6tsch] payload format for CoAP

From: "Raghuram Sudhaakar (rsudhaak)" <[email-masked]>
Date: Sat, 5 Oct 2013 15:29:36 +0000

During our call on 4/10 we suggested Name-Value pairs (NVP) and CBOR as the possible CoAP payload formats.

The line of discussion was

  1.  Obvious advantages of CBOR are related to control overhead. However the percentage advantage of CBOR over NVP is not established.
  2.  Constrained devices may not be able to handle the additional overhead of a CBOR parser. NVPs are easy to parse.
  3.  But, the CoAP messages are typically layer 5 transactions and the processing constraint may not be applicable.
  4.  There is a clear tradeoff w.r.t simplicity vs efficiency in making the choice.

I would like to call upon the group for more discussion on this topic so we can reach a consensus.

-raghuram

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 5 Oct 2013 18:02:43 +0200

On Oct 5, 2013, at 17:29, "Raghuram Sudhaakar (rsudhaak)" <[email-masked]> wrote:

> 	• the additional overhead of a CBOR parser. NVPs are easy to parse.

CBOR is easy to parse, too.

To inject some data here, if you are talking about code size overhead:
size -m cn-cbor.o
	Section (__TEXT, __text): 880

If all you need is name-value pairs, a tailored CBOR parser will be even less than those 880 bytes, which is armv7 code for a fully generic parser (for instance, this code includes an implementation of half-precision floating point.).

For every single application, it is of course easy to come up with a bespoke format that has some advantages over CBOR but only works for this application, and we engineers of course like doing that :-).
Your node may need to do other things in addition to exchanging 6tisch data.
So you already may have a CBOR parser in your constrained device, which could make the incremental cost for using it with 6tisch near zero.

Grüße, Carsten

---

From: Xavier Vilajosana Guillen <[email-masked]>
Date: Sat, 5 Oct 2013 13:45:01 -0700

Hi Carsten

can we have access to a cbor parser implementation to do some testing in a
very small microcontroller (e.g msp430).

thanks!
Xavi

On Sat, Oct 5, 2013 at 9:02 AM, Carsten Bormann <[email-masked]> wrote:

> If all you need is name-value pairs, a tailored CBOR parser will be even
> less than those 880 bytes, which is armv7 code for a fully generic parser
> (for instance, this code includes an implementation of half-precision
> floating point.).
>
> For every single application, it is of course easy to come up with a
> bespoke format that has some advantages over CBOR but only works for this
> application, and we engineers of course like doing that :-).
> So you already may have a CBOR parser in your constrained device, which
> could make the incremental cost for using it with 6tisch near zero.
>
> Grüße, Carsten
>
> _______________________________________________
> 6tsch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch
>