Re: [6tsch] payload format for CoAP

Carsten Bormann <> Sat, 05 October 2013 16:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 39CB921F90AC for <>; Sat, 5 Oct 2013 09:02:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rNftY36lm6Sm for <>; Sat, 5 Oct 2013 09:02:50 -0700 (PDT)
Received: from ( [IPv6:2001:638:708:30c9::12]) by (Postfix) with ESMTP id 23AED21F8D12 for <>; Sat, 5 Oct 2013 09:02:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id r95G2jEM008854; Sat, 5 Oct 2013 18:02:45 +0200 (CEST)
Received: from [] ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id BE235C94; Sat, 5 Oct 2013 18:02:44 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Content-Type: text/plain; charset=windows-1252
From: Carsten Bormann <>
In-Reply-To: <>
Date: Sat, 5 Oct 2013 18:02:43 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: "Raghuram Sudhaakar (rsudhaak)" <>
X-Mailer: Apple Mail (2.1510)
Cc: "" <>
Subject: Re: [6tsch] payload format for CoAP
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 05 Oct 2013 16:02:56 -0000

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