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

From: Cenk Gündoğan <[email-masked]>
Date: Fri, 4 Jan 2019 13:52:08 +0100

Hello all,

in light of the upcoming IETF104@Prague we want to point at the questions that
we raised in our slides [1] (page 9) during IETF103 to start discussions and
improve on the quality of the ICNLoWPAN document.

As a recap, the questions (and a little more) follow immediately:

1a) The ICNLoWPAN document defines a condensed TLV encoding for NDN and CCNx [2].
The trade-off is that smaller "type" and "length" numbers (in NDN both fields
are flexible) have a much more condensed representation, but larger numbers do
take up more. Until now, all "core" header fields have relatively small numbers
so that this trade-off is IMO justified. What are your opinions on this?

1b) Further, ICNLoWPAN redefines certain TLVs to hold fixed-length values, such
as the InterestLifetime (2 octets). This clearly limits the expressiveness and
messages with values larger than 2 octets must be sent uncompressed.
Are you detecting any problems with such restrictions, or do you prefer
condensed encodings other than just limiting to [2^0,2^16)?

1c) ICNLoWPAN further changes the name encoding in a way that component lengths
are restricted to [0,15). This way, the lengths of two components can be
encoded into only 1 octet. Messages with names that do not comply are sent
uncompressed.
What are your opinions on this name encoding? Are 15 bytes for a name component
good enough for typical (IoT) scenarios?

1d) The presented stateless compression for CCNx and NDN in sections 5.3+ and
6.3+ of the document has certain assumptions about how typical messages in an
IoT context may look. The stateless compression is designed to suit these
assumptions. Do you think we missed some assumptions, so that certain
Interest/Data representations should be encoded more effectively?

2a) Is anyone willing to take part in a joint implementation effort so that we
can work out issues that are not immediately apparent? Ideally, such
implementations should run on class 2 devices [3].

2b) Is anyone aware of another CCNx implementation (besides CCN-lite) that
might be able to run on such devices?

3) Is anything relevant missing or are there further ideas to improve
ICNLoWPAN?

We appreciate any feedback on above questions and on the document itself.

Cheers,
Cenk

[1] https://datatracker.ietf.org/meeting/103/materials/slides-103-icnrg-icn-6lopan-update-schmidt-00
[2] https://tools.ietf.org/html/draft-irtf-icnrg-icnlowpan-01#section-5.1
[3] https://tools.ietf.org/html/rfc7228#section-3

On 18-11-27 23:20:32, Cenk Gündoğan wrote:
> Dear ICNRG,
> 
> we have submitted a new version of the ICN LoWPAN document that includes the
> following changes:
> 
> 1. We revised the stateless compression for CCNx to use less dispatch octets
> than before.
> 
> 2. Stateful header compression is a separate section (sec. 7) now.
> We also changed the HopID encoding to support 127 distinct (ephemeral) HopIDs
> instead of formerly 64.
> 
> 3. We provide more figures (esp. Fig. 12, 15, 18, 22) to better visualize the
> stateless compression for NDN and CCNx.
> 
> 4. We adjusted the calculations for the estimated size reductions in the
> appendix.
> 
> Comments and feedback are welcome to improve the document, particularly for the
> NDN and CCNx stateless compression schemes.
> 
> Regards,
> Cenk
> 
> On 18-11-27 14:12:41, [email-masked] wrote:
> > 
> > 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-01.txt
> > 	Pages           : 40
> > 	Date            : 2018-11-27
> > 
> > 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-01
> > https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-icnlowpan-01
> > 
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-irtf-icnrg-icnlowpan-01
> > 
> > 
> > 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/
> > 
> > _______________________________________________
> > icnrg mailing list
> > [email-masked]
> > https://www.irtf.org/mailman/listinfo/icnrg
> 
> -- 
> 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/

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

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

---

From: "David R. Oran" <[email-masked]>
Date: Fri, 04 Jan 2019 14:09:42 -0600

> As a recap, the questions (and a little more) follow immediately:
With <ChairHatOff>

> so that this trade-off is IMO justified. What are your opinions on this?
This seems reasonable. Given that the core CCNx specs are currently undergoing conflict review and IANA review, this is probably the time to ensure there are no “bad” allocations, in the sense of either
(a) TLV numbers and allowed lengths for header fields that are always or almost always present don’t have unduly large numbers
(b) We don’t use up all the “small” values making it hard to add stuff that will be useful (or even just only useful) in low-bandwidth/low MTU environments.
So, let’s have folks if possible look at this NOW and offer changes if need be.

> condensed encodings other than just limiting to [2^0,2^16)?
No strong opinion here for the general case, but it may be worth revisiting (NOW!) any TLVs with potentially large dynamic range but no need for high resolution (Interest Lifetime may be one of those) to have a logarithmic rather than a linear encoding.

> good enough for typical (IoT) scenarios?
No opinion on this one.

> Interest/Data representations should be encoded more effectively?
No opinion.

>>> ftp://ftp.ietf.org/internet-drafts/

DaveO

---

From: Cenk Gündoğan <[email-masked]>
Date: Tue, 8 Jan 2019 19:23:01 +0100

Hello Dave, *,

thanks for the feedback. I left a few comments below.

> So, let’s have folks if possible look at this NOW and offer changes if need be.

I skimmed through the IANA considerations section in the CCNx doc [1].
IMO, there are no apparent red flags to raise, per se. I would like to
point out a few allocations, though, that might be worth discussing:

1) "T_PAD" [2] and "T_ORG" [3] are used in many places of a CCNX packet.
I cannot assess how frequently used those TLVs are in typical (IoT) CCNx
deployments. They both have very large type definitions.
"0x0FFE" for "T_PAD" and "0x0FFF" for "T_ORG".
Iff overall consesus is that these TLVs are used quite frequently, then
lower values (to fit into 1 octet) may be more sensible for compression
purposes.

2) Name segments [4] can be of type "Application Components" "T_APP"
with a type range of [0x1000,0x1FFF]. Here again, if "T_APP" is
frequently used, we could slice the range to include a few "T_APP" types
into the first octet.

[1] https://tools.ietf.org/html/draft-irtf-icnrg-ccnxmessages-08#section-4
[2] https://tools.ietf.org/html/draft-irtf-icnrg-ccnxmessages-08#section-3.3.1
[3] https://tools.ietf.org/html/draft-irtf-icnrg-ccnxmessages-08#section-3.3.2
[4] https://tools.ietf.org/html/draft-irtf-icnrg-ccnxmessages-08#section-4.5

> No strong opinion here for the general case, but it may be worth revisiting (NOW!) any TLVs with potentially large dynamic range but no need for high resolution (Interest Lifetime may be one of tho…

IMO high resolution for InterestLifetime is not necessary. Are there use
cases where it makes a difference whether an Interest stays open for
1000 or 1001 milliseconds? For measuring purposes maybe? I would be in
favor of losing precision and get a wider range, at least for IoT
deployments. However, using a dynamic range encoding scheme will
definitely affect the processing time for high-speed deployments. In
constrained IoT networks processing speed is not that important, since
media access and sending/receiving is usually much slower. So, we can
keep such transformations also in ICNLoWPAN and leave the CCNx encoding
as is. Then we would need best practices in the ICNLoWPAN document for
applications to use values that can benefit from these
transformations/compressions.

Just FYI: MANETs have a TimeTLV that can express durations with wider
range using 1 ocet [5].

[5] https://tools.ietf.org/html/rfc5497

Cheers,
Cenk

-- 
Cenk Gündoğan

---

From: "David R. Oran" <[email-masked]>
Date: Wed, 09 Jan 2019 10:44:30 -0500

Some stuff embedded, but I was mostly intrigued by Cenk’s digging up TimeTLV from MANET in https://tools.ietf.org/html/rfc5497

I wonder if we should use this in CCNx messages as opposed to the current integer linear encoding.

Now’s the time to do it if we ever want to! I’m particularly interested in whether Marc thinks this is a good idea.

> lower values (to fit into 1 octet) may be more sensible for compression
Well, PAD is for alignment optimization so it’s easy to just leave it out if you value size over alignment efficiency.

ORG is an escape mechanism so I guess it’s pretty hard to see how to make any decisions about size now.

So, I’d leave these alone.

> [4] https://tools.ietf.org/html/draft-irtf-icnrg-ccnxmessages-08#section-4.5
We don’t have enough data to judge, but my sense is that these may get used fairly frequently, so we should consider something like what you propose. What do others think?

> [5] https://tools.ietf.org/html/rfc5497
As noted above, I think we gout to seriously consider this. Thanks for digging it up.

DaveO