Subject: [icnrg] I-D Action: draft-irtf-icnrg-icnlowpan-05.txt

From: [email-masked]
Date: Thu, 19 Sep 2019 10:27:08 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Information-Centric Networking RG of the IRTF.

        Title           : ICN Adaptation to LowPAN Networks (ICN LoWPAN)
        Authors         : Cenk Gundogan
                          Thomas C. Schmidt
                          Matthias Waehlisch
                          Christopher Scherb
                          Claudio Marxer
                          Christian Tschudin
	Filename        : draft-irtf-icnrg-icnlowpan-05.txt
	Pages           : 47
	Date            : 2019-09-19

Abstract:
   This document defines a convergence layer for CCNx and NDN over IEEE
   802.15.4 LoWPAN networks.  A new frame format is specified to adapt
   CCNx and NDN packets to the small MTU size of IEEE 802.15.4.  For
   that, syntactic and semantic changes to the TLV-based header formats
   are described.  To support compatibility with other LoWPAN
   technologies that may coexist on a wireless medium, the dispatching
   scheme provided by 6LoWPAN is extended to include new dispatch types
   for CCNx and NDN.  Additionally, the link fragmentation component of
   the 6LoWPAN dispatching framework is applied to ICN chunks.  In its
   second part, the document defines stateless and stateful compression
   schemes to improve efficiency on constrained links.  Stateless
   compression reduces TLV expressions to static header fields for
   common use cases.  Stateful compression schemes elide state local to
   the LoWPAN and replace names in data packets by short local
   identifiers.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-irtf-icnrg-icnlowpan/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-irtf-icnrg-icnlowpan-05
https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-icnlowpan-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-irtf-icnrg-icnlowpan-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Cenk Gündoğan <[email-masked]>
Date: Thu, 19 Sep 2019 19:32:43 +0200

Dear ICNRG,

this update adds an extensibility mechanism to the ICNLoWPAN dispatch
format. This allows future I-Ds to extend the compression rule set
and to react to changes in the CCNx and NDN packet format.

Further, I want to bring our last discussion on the name compression
topic into focus (former mail is attached). The very essence of this
discussion is:

* the current default name compression strategy in ICNLoWPAN is
  restrictive, but effective, if ((only generic-typed name components
  are used) && (all component lengths <= 15 octets)). Also note that
  this stateless compression is invoked hop-wise and mostly for
  Interests only, since returning name prefixes for Data messages are
  elided by the stateful compression and added by ICNLoWPAN before
  passing the Data packet to the CCNx/NDN network stack.

* do we want to keep the simple name compression (above) as default
  and work on more elaborate compression schemes (including
  static/dynamic dictionary-based approaches, e.g.) as part of future
  I-Ds? The new extensibility mechanism (in the last update) surely
  opens the door to future I-Ds that solely focus on the name
  compression and which simply integrate into ICNLoWPAN.

We will bring up this discussion again during the interim meeting in
Macau and a lively discussion on site or on the list is greatly
appreciated (:

Cheers,
Cenk

Subject: ICNLoWPAN: Discussion on Extensibility and Name Compression Scheme
From: Cenk Gündoğan <[email-masked]>
To: ICNRG <[email-masked]>
Date: Mon, 19 Aug 2019 14:46:50 +0200

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: +49 40 42875 - 8426
Mail: [email-masked]
Web: https://www.inet.haw-hamburg.de/

--
Cenk Gündoğan

Hamburg University of Applied Sciences
Dept. of Computer Science / Internet Technologies Group
Berliner Tor 7, 20099 Hamburg, Germany
Fon: +49 40 42875 - 8426
Mail: [email-masked]
Web: https://www.inet.haw-hamburg.de/

On Thu, Sep 19 2019 at 19:27 +0200, [email-masked] wrote:

> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg

---

From: Junxiao Shi <[email-masked]>
Date: Sun, 29 Sep 2019 08:08:55 -0400

Hi Cenk

I saw the interim meeting slides and the idea about allowing typed name
components: two bits to encode one of four frequently used name component
types, and six bits to encode TLV-LENGTH up to 63.
The types selected are: Generic, Timestamp, Version, SequenceNum. I wonder
what's the basis of this selection? Segment type has been used extensively
in many NDN protocols, including file transfer, NFD Management, and NLSR.
However, I can't say the same for IoT apps, despite my own building sensing
app has been using Segment type always set to zero "for consistency with
other NDN protocols".

One possibility is leaving this choice to the deployment. Parameters are:
(1) how many bits for TLV-TYPE and how many bits for TLV-LENGTH (2) the
TLV-TYPE table.
Either a network administrator needs to configure these parameters, or the
device could report its preference at startup time, to be associated with
ContextID as described in Section 8.1.
Once the parameters are configured or established through ContextID
mechanism, the compression format of Name is determined according to the
parameters.
The default state without parameters could be Generic only, because it's
unfair to pick a specific set of types and discriminate against apps trying
to use others.

P.S. typo in Section 8.2, (1...128) should be (1...127)

Yours, Junxiao