Re: [6tsch] payload format for CoAP

Carsten Bormann <cabo@tzi.org> Sat, 05 October 2013 16:02 UTC

Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Content-Type: text/plain; charset="windows-1252"
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <2C3A8CAFDCAFCA41B8BF705CD9471C5B18609FCD@xmb-rcd-x04.cisco.com>
Date: Sat, 05 Oct 2013 18:02:43 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <C5D823CD-BBE8-473E-A0A0-42C8121EE500@tzi.org>
References: <2C3A8CAFDCAFCA41B8BF705CD9471C5B18609FCD@xmb-rcd-x04.cisco.com>
To: "Raghuram Sudhaakar (rsudhaak)" <rsudhaak@cisco.com>
Cc: "6tsch@ietf.org" <6tsch@ietf.org>
Subject: Re: [6tsch] payload format for CoAP
Precedence: list

On Oct 5, 2013, at 17:29, "Raghuram Sudhaakar (rsudhaak)" <rsudhaak@cisco.com> 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

[6tsch] payload format for CoAP Raghuram Sudhaakar (rsudhaak)
Re: [6tsch] payload format for CoAP Carsten Bormann
Re: [6tsch] payload format for CoAP Xavier Vilajosana Guillen