[icnrg] ICNLoWPAN: Discussion on Extensibility and Name Compression Scheme

[Cenk Gündoğan <[e-mail]>]

Dear ICNRG,

in the last ICNRG meeting (Montreal), Thomas presented the current state
of the ICNLoWPAN [1] document. The conclusion of discussions during the
talk was to investigate whether a name compression scheme with relaxed
restrictions than the predefined one might be better suited. An idea
formed to support names with varying (but most frequently used) name
component types. For CCNx, these seem to be T_NAMESEGMENT, T_IPID, and
MAY include T_CHUNK [2] and T_VERSION [3]. For NDN, these seem to
include GenericNameComponent, TimestampNameComponent,
VersionNameComponent and SequenceNumberNameComponent [4]. Both lists are
by no means complete, as for both protocols new (frequently used) name
component types can still emerge.

As a reminder .. the currently defined name compression scheme as per
[1] has the following restrictions:

1) all name component types are elided and GenericNameComponent (NDN) /
T_NAMESEGMENT (CCNx) are assumed for all components. No other name
component types are expected.

2) name component lengths are restricted to 15 octets max, in order to
fit the length of two consecutive components into 1 octet.

Our initial motivation was to have a scheme that removes most of the TLV
overhead and our assumption was that IoT deployments usually use
machine-to-machine communications (which MAY carry less semantics in the
name).

To proceed with this discussion and to promote the progression of the
ICNLoWPAN document, we would like to propose the following:

In light of the flexibility and extensibility of CCNx / NDN, we would
also make the "compression octets" of ICNLoWPAN extensible. An example:
we would assign a bit in Figure 13+16 of [1] (respectively for CCNx) to
indicate a second, following octet to be part of the compression
algorithm. In this following octet, we can then allocate a number of
bits to (i) select a name compression algorithm (deviating from the
default) and (ii) define necessary compression parameters. Specific
definitions for (i) and (ii), and possible other things also, could then
be handled by future I-D documents as the need arises from new features
added to CCNx and NDN.

The questions I intend to provoke are:

(i) is the group O.K. with making ICNLoWPAN dispatches extensible?

(ii) should we think of a more elaborate name compression scheme as
default behaviour for ICNLoWPAN, or would the group be O.K. with keeping
the currently defined (highly restrictive, but very low-overhead) name
compression scheme provided in [1]? Other name compression algorithms
(e.g., static/dynamic dictionary-based approaches with proper dictionary
(re-)distribution; I believe Marc has some ideas on this) can then be
added to the ICNLoWPAN extension octet via new I-Ds once mature ideas
exist.

Best,
Cenk

[1] https://tools.ietf.org/html/draft-irtf-icnrg-icnlowpan-04
[2] https://tools.ietf.org/html/draft-mosko-icnrg-ccnxchunking-02
[3] https://tools.ietf.org/html/draft-mosko-icnrg-ccnxserialversion-00
[4] https://redmine.named-data.net/projects/ndn-tlv/wiki/NameComponentType

--
Cenk Gündoğan

Hamburg University of Applied Sciences
Dept. of Computer Science / Internet Technologies Group
Berliner Tor 7, 20099 Hamburg, Germany
Fon: [phone] - 8426
Mail: [e-mail]
Web: https://www.inet.haw-hamburg.de/