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

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 03 September 2020 18:44 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9B213A1141 for <cbor@ietfa.amsl.com>; Thu, 3 Sep 2020 11:44:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GBaYBbMTDhrj for <cbor@ietfa.amsl.com>; Thu, 3 Sep 2020 11:44:17 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [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 ietfa.amsl.com (Postfix) with ESMTPS id B542B3A0C6E for <cbor@ietf.org>; Thu, 3 Sep 2020 11:44:17 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 71D78389C6; Thu, 3 Sep 2020 14:23:10 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id iJyL2HVEdO5H; Thu, 3 Sep 2020 14:23:09 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id BCD77389C2; Thu, 3 Sep 2020 14:23:08 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2202D86F; Thu, 3 Sep 2020 14:44:14 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Brendan Moran <Brendan.Moran@arm.com>, "cbor\@ietf.org" <cbor@ietf.org>
In-Reply-To: <C8842D1C-27EE-4E47-BFED-6BDF467C7038@arm.com>
References: <5E28C6E2-DFEC-4AF5-96CE-75E8F0927818@arm.com> <01d901d66503$2bbd93c0$8338bb40$@augustcellars.com> <7216D806-3473-463E-B6F2-AD8724AC56C6@tzi.org> <021e01d66535$57827d90$068778b0$@augustcellars.com> <406B6702-3045-4490-8CD0-8E352F924714@arm.com> <24543.1596045216@localhost> <AEB72DC9-76BF-49CB-BE70-7ABE2E4D9C39@arm.com> <15800.1596569288@localhost> <C8842D1C-27EE-4E47-BFED-6BDF467C7038@arm.com>
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: <https://mailarchive.ietf.org/arch/msg/cbor/MGI_swl8DUSQMZPmG4l3kWisAc8>
Subject: Re: [Cbor] Review: draft-bormann-cbor-packed-00 & SUIT
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Sep 2020 18:44:20 -0000

Brendan Moran <Brendan.Moran@arm.com> wrote:
    >> Brendan Moran <Brendan.Moran@arm.com> 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.”,
    >>> “domain.com”]. 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 <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
-= IPv6 IoT consulting =-