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

From: [email-masked]
Date: Mon, 08 Jul 2019 09:38:55 -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-03.txt
	Pages           : 42
	Date            : 2019-07-08

Abstract:
   In this document, a convergence layer for CCNx and NDN over IEEE
   802.15.4 LoWPAN networks is defined.  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-03
https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-icnlowpan-03

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

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: Mon, 08 Jul 2019 18:45:37 +0200

Dear ICNRG,

we have submitted a new version of the ICN LoWPAN document including the
following minor changes (besides editorial improvements):

1. we previously allocated 2 octets for a Time TLV, we went back to 1
   octet as published in RFC-5497

2. we simplified the NDN Interest/Data compression for TLVs that use the
   TimeTLV: InterestLifetime + FreshnessPeriod

As this document is about ready for RG last call, we urge for additional
reviews and comments.

Regards,
Cenk

On Mon, Jul 08 2019 at 18:38 +0200, [email-masked] wrote:

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

---

From: Junxiao Shi <[email-masked]>
Date: Mon, 8 Jul 2019 13:36:34 -0400

Hi Cenk

I only read section 5 regarding NDN packet compression.

Section 5.2 says "a length of 0 marks the end of the compressed Name TLV".
However, it is valid to have a NameComponent whose TLV-LENGTH is zero.

Section 5.3.2 step 2 says "all NameComponents are expected to be of type
GenericNameComponent", while Figure 13 defines a "DIG" flag that permits a
NameComponent type other than GenericNameComponent.

I feel concerned about the direction of "all NameComponents are expected to
be of type GenericNameComponent".
Typed name components are designed to improve the expressiveness of names.
In IoT environment, TimestampNameComponent and SequenceNumberNameComponent
are widely used. Not supporting them limits the usefulness of your protocol.

Section 5.3.2 Figure 12 shows the TLV-VALUE of ForwardingHint is not
further compressed. This is a missed opportunity, because the
ForwardingHint contains several names that can be effectively compressed.
Likewise, Section 5.4.2 Figure 15 could have compressed the name enclosed
in SignatureInfo.

Section 5.3.2 is incompatible with current version of NDN packet format.
Recent updates to NDN packet format specification include:

   - rename Parameters to ApplicationParameters
   - require ParametersSha256DigestComponent whenever the
   ApplicationParameters element is present
   - define Signed Interest

Figure 13 still mentions "Parameters TLV", but Parameters element is no
longer present in NDN packet format as it has been renamed.
Furthermore, step 2 mandates that a Name with a component other than
GenericNameComponent cannot be compressed. This implies every Interest
having ApplicationParameters or InterestSignature cannot be compressed,
since they would trigger the inclusion of a
ParametersSha256DigestComponent. Consequently, "PRM L PRM V" in Figure 12
and "PRM" in Figure 13 will never be used.

Section 5.4.2 Figure 16 has a "DIG" flag that does not make sense.
ImplicitSha256DigestComponent can only appear at the end of Interest name.
It can never appear in a Data name.

Section 5.4.2 Figure 16 has a "CON" flag that, when set to 1, means "Type
field is removed from the compressed message". This conflicts with Figure
15 that shows the TLV-LENGTH of ContentType element is also removed.
It's unclear how the TLV-LENGTH of ContentType element is expressed. One
solution is to use the same encoding as Section 5.1, and perform
compression only if ContentType TLV-VALUE were encoded as a
nonNegativeInteger of minimum length (note that nonNegativeInteger
specification generally does not require minimum length encoding).
Also, the presentation of Figure 15 is confusing in that it does not
distinguish whether a "V" is in original format (such as CONT V and SVal V)
or a transformed format (such as Name V or FrPr V). I'd suggest using Vu to
indicate original/uncompressed TLV-VALUE and Vc to indicate
transformed/compressed format.

Finally, Section 5 does not consider the guidelines in NDN packet format
"Considerations for Evolvability of TLV-Based Encoding" section.
If a packet contains unrecognized non-critical TLV element, it cannot be
compressed without these elements, or you'll break the security envelope.

P.S. https is now available for named-data.net website. You can update your
citation to use https.

Yours, Junxiao

---

From: Cenk Gündoğan <[email-masked]>
Date: Thu, 11 Jul 2019 15:42:40 +0200

Hello Junxiao,

thank you very much for your excellent feedback. My comments are inlined
below.

> However, it is valid to have a NameComponent whose TLV-LENGTH is zero.

According to the spec, NDN names can include zero-length name
components. Our proposed name compression cannot handle this. The
general idea was to keep the compression as simple as possible by
focusing on the most used features of the protocol. If we opt for a
compression that handles every single use case, then the compression
overhead increases for even the simplest use case.

Could you please shed light on where and when zero-length name
components are actually used? Is it something an application would
normally do? Especially in IoT scenarios? Would this justify an increase
in compression overhead for all use cases?

> NameComponent type other than GenericNameComponent.

The digest is supposed be be present immediately after the name
octets. It is not really mentioned in the current version of the draft,
but the digest component can again be of the form [Length][Value]. What
do you think about that?

> are widely used. Not supporting them limits the usefulness of your protocol..
>

I guess this turns back to the previous discussion: How often would an
application use another name component type than genericnamecomponent?
I mean, messages can still be sent uncompressed if they deviate from the
compression rules.

If you think that component types, like, e.g., TimestampNameComponent
and SequenceNumberNameComponent are relevant in the IoT context, then we
could come up with a secondary name encoding scheme that is extensible
and compresses all known and yet-to-be-defined name component types. How
do you feel about this?

> Likewise, Section 5.4.2 Figure 15 could have compressed the name enclosed

That's a good point. I guess you were thinking about the KeyLocator
within a SignatureInfo TLV? I will have to think a little bit more about
how to apply the above name compression to nested names within these
constructs. At first sight, it shouldn't be a big problem.

Another side question here: Are ForwardingHints used in practice (in the
IoT)? The spec is a little bit silent on this topic. In fact, the spec
reads:

..
Specifics of the forwarding logic for Interests with
ForwardingHint will be defined in a separated document.
..

Is there a document for the specifics somewhere available?

> and "PRM" in Figure 13 will never be used.

I have to think more about how to incorporate these changes. I will come
back to you with some suggestions regarding this TLV.

BTW, are you aware of any upcoming changes to the NDN TLV spec? Or is
there maybe a roadmap that might point to further protocol changes?

In any case, a compression document that relies on a specific protocol
version works best for that specific protocol version. It's unfeasiable
to update this document every time NDN updates the packet
specification. How should we proceed with these changes in general
(@all)? Pin ICNLoWPAN to a specific version at first, and update
incrementally in case major changes to the NDN packet format happen?

> It can never appear in a Data name.

Ah yes, thank you! I misread that part of the spec. I will remove DIG
from the Data.

> transformed/compressed format.

Regarding the ContentType: I will change it to [Length][Value]. At least
this is what I intended at the beginning. Somehow the [Length]
disappeared from the figure. Thanks for pointing this out.

Regarding V vs Vc: looks like a good idea. I will try to incorporate
this into the figure.

> compressed without these elements, or you'll break the security envelope.

Do you think saying the following is sufficient and desired?
..
If an ICNLoWPAN compressor encounteres an unknown TLV, then the message
MUST be sent uncompressed?
..

> P.S. https is now available for named-data.net website. You can update your

Alright, thanks (:

Cheers,
Cenk

---

From: Junxiao Shi <[email-masked]>
Date: Thu, 11 Jul 2019 16:23:49 -0400

Hi Cenk

> in compression overhead for all use cases?

In practice, zero-length name components are rarely used.
You can simply declare "packets with zero-length name components must be
sent uncompressed".

> but the digest component can again be of the form [Length][Value]. What

The NDN packet format defines ImplicitSha256DigestComponent to be *part of*
the name, not *after* the name.
I was pointing of a conflict in your writing. Your protocol permits:
Name = *NameComponents [ImplicitSha256DigestComponent]
However, the statement "all NameComponents are expected to be of type
GenericNameComponent" indicates:
Name = *NameComponents

> and compresses all known and yet-to-be-defined name component types. How

Component types other than GenericNameComponent are expected to be
frequently used to indicate the semantics of name components.
Naming conventions document is already updated
https://gitlab.com/named-data/tr-ndn-0022-naming-conventions
It defines component types for timestamp, sequence number, version, and
segment.
These were previously encoded as GenericNameComponents with markers, but
they will become separate component types soon.
These are widely used in all application scenarios including IoT.

> ...
> ...

Forwarding behavior regarding ForwardingHint is only vaguely defined. Some
references are:
Alex's dissertation
https://irl.cs.ucla.edu/data/files/theses/afanasyev-thesis.pdf Section 6.3
SNAMP paper https://named-data.net/publications/snamp-ndn-scalability/
NFD Feature 3000 https://redmine.named-data.net/issues/3000
NFD Feature 3333 https://redmine.named-data.net/issues/3333

I'm unaware about ForwardingHint usage in IoT.

> there maybe a roadmap that might point to further protocol changes?

Issue tracker for NDN protocols is at
https://redmine.named-data.net/projects/ndn-tlv/issues
I'm unaware of major upcoming changes.

> incrementally in case major changes to the NDN packet format happen?

You may cite a specific version by referencing the git commit in this
repository:
https://github.com/named-data/NDN-packet-spec

> ...
> ...

Yes this is correct.

Yours, Junxiao