Re: [Cbor] Review: draft-bormann-cbor-packed-00 & SUIT

Michael Richardson <> Thu, 03 September 2020 18:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A9B213A1141 for <>; Thu, 3 Sep 2020 11:44:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GBaYBbMTDhrj for <>; Thu, 3 Sep 2020 11:44:17 -0700 (PDT)
Received: from ( [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B542B3A0C6E for <>; Thu, 3 Sep 2020 11:44:17 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 71D78389C6; Thu, 3 Sep 2020 14:23:10 -0400 (EDT)
Received: from ([]) by localhost (localhost []) (amavisd-new, port 10024) with LMTP id iJyL2HVEdO5H; Thu, 3 Sep 2020 14:23:09 -0400 (EDT)
Received: from ( []) by (Postfix) with ESMTP id BCD77389C2; Thu, 3 Sep 2020 14:23:08 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 2202D86F; Thu, 3 Sep 2020 14:44:14 -0400 (EDT)
From: Michael Richardson <>
To: Brendan Moran <>, "cbor\" <>
In-Reply-To: <>
References: <> <01d901d66503$2bbd93c0$8338bb40$> <> <021e01d66535$57827d90$068778b0$> <> <24543.1596045216@localhost> <> <15800.1596569288@localhost> <>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Thu, 03 Sep 2020 14:44:14 -0400
Message-ID: <22182.1599158654@localhost>
Archived-At: <>
Subject: Re: [Cbor] Review: draft-bormann-cbor-packed-00 & SUIT
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 03 Sep 2020 18:44:20 -0000

Brendan Moran <> wrote:
    >> Brendan Moran <> wrote:
    >>>> Unless you mean that dictionaries should be sorted so that they always (can only)
    >>>> reference forward, and you can start at the current location in the current
    >>>> dictionary.
    >>> Possibly, but I’m not sure that’s universally advantageous. Remember
    >>> that we want high reference frequency items to be at the start. Suppose
    >>> that I have the prefixes [“https://“, “www.”, “files.”,
    >>> “”]. Clearly, I want to be able to compose these in one of
    >>> two ways:
    >> I agree that sorting by frequency of us has CPU advantages.
    >> I'm not sure that this is important enough ("premature optimization is the
    >> root of all evil").

    > Sorting by frequency of use only matters for the first handful of
    > elements. This is not for CPU usage. It’s for size. Simple 0-15 are
    > 1-byte references. Tag6(x) st. -24<x<24 are 2-byte references. -255 < x
    > < 255 are 3-byte references.

Point. I was not thinking some of it through.
BUT, there is an assumption that the dictionary will be created and stored as
an array.  That's a pretty logical way.

But it could be stored as an flattened alist (aka: "ordered map", aka "ordered multi-map").
(It is probably stupid to have duplicate keys though)
In which case the size of the key and the order do not have to be tied up.
Content could always point "forward".

    >> If you are saying that sometimes the compressor will be a constrained node,
    >> because CBOR is used outside of SUIT (who knew?), then I would like to
    >> retract my comment involving that five-letter word.

    > This comes back to the typical compression 3-way tradeoff: compression
    > complexity vs. compression ratio vs. decompression
    > complexity. Answering whether a constrained node will pack CBOR depends
    > on the goal. Recognising the power consumption profiles of wireless
    > sensor networks (e.g. LoRa) I think it’s reasonable to say that some

I think that LoRa is so incredibly constrained that it will have
pre-distributed dictionaries in which substrings are not discovered, but
which the code knows which key to use, by construction.
However, I recently learnt that there is some kind of point to point LoRA
which an support a mesh topology. Supposedly.  I am skeptical (unicast me)

    > For wireless sensor nodes, I think the real question is code size for
    > packing, not energy or memory. The really great thing about packed CBOR
    > is that the document format is identical, regardless of how complex the
    > encoder is. This will allow developers to tune packing algorithms for
    > code size vs packing ratio vs memory vs. energy.

Yes, I agree.  So in many cases some very stupid packers that get 90% of the
job done for the cases involved will be appropriate.  Someone will change
something and it will suddenly fail to work (using a lot more energy), but it
will be a local fault, which can be remedied with a local patch.

Michael Richardson <>ca>, Sandelman Software Works
-= IPv6 IoT consulting =-