Subject: [core] OSCORE Header Compression

From: Göran Selander <[email-masked]>
Date: Wed, 14 Mar 2018 14:37:57 +0000

All,

Another IESG review comment, see below. We certainly have discussed
message size optimisations on the CORE list, but I couldn’t recall if this
particular optimization was discussed so I forward the comment:

- Do you agree that this optimisation matters?

https://core-wg.github.io/oscoap/draft-ietf-core-object-security.html#rfc.s
ection.6

(As a comparison, DTLS 1.3 introduces a short header to save of the order
of 5 bytes.)

Regards,
Göran

On 2018-03-08 08:38, "Adam Roach" <[email-masked]> wrote:

>
>--------------------------------------------------------------------------
>-
>
>§6 and its subsections:
>
>The use of a bespoke profile of COSE adds implementation complexity to
>ostenstibly resource-limited device for what appears to be very little
>gain. In
>the examples given, savings of 4 to 7 bytes are demonstrated, which seems
>to
>hardly warrant the addition of this mechanism. These do not appear to be
>degenerate cases, so I can't imagine that compression performance under
>real-world conditions would be much better.  Was there an explicit
>discussion
>in the working group regarding this complexity/wire-size trade-off?
>
>--------------------------------------------------------------------------
>-

---

From: Mališa Vučinić <[email-masked]>
Date: Wed, 14 Mar 2018 18:53:11 +0100

Hi Göran,

IIRC, the proposal for the OSCORE header compression came from 6TiSCH where we are limited to 127-byte frames and often we do not support fragmentation of IP packets.

As we use OSCORE to transport network parameters needed by a new node (i.e. pledge) to join the network (see draft-ietf-6tisch-minimal-security), the OSCORE message (i.e. Join Response) needs to fit into a single 127-byte frame, together with CoAP/UDP+IPv6+6LoWPAN/802.15.4 headers. The packet carrying this message is additionally source routed (RFC6554) down the RPL DODAG, where each hop with the compression mechanism of RFC6554 adds typically around 2 bytes, IIRC, as the longest-matching prefix between subsequent addresses can be elided.

How deep the 6TiSCH network (without fragmentation) can be is determined by the size of the resulting OSCORE message (Join Response). The savings of 4-7 bytes by OSCORE allow us to extend the physical range of the network from 2 to 4 hops more, at a cost of ~30 lines of highly unoptimized C code. With that compression performed, we can currently form 6TiSCH networks up to 6 hops deep (results from the plugtest from Prague in July 2017), and without we would be limited to 4 to 2 hops.

I apologize for the imprecision in my figures, as I am writing from memory based on the experience we gathered during the plugtests, but I hope this illustrates the benefits and the involved implementation complexity.

Regards,
Mališa

> On 14 Mar 2018, at 15:37, Göran Selander <[email-masked]> wrote:
> 
> All,
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core