[core] OSCORE Header Compression

[Göran Selander]

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

--------------------------------------------------------------------------
-
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?
--------------------------------------------------------------------------
-

[Mališa Vučinić]

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

Post by Göran Selander
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
- 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

--------------------------------------------------------------------------
-
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?
--------------------------------------------------------------------------
-

_______________________________________________
core mailing list
https://www.ietf.org/mailman/listinfo/core