Subject: Re: [icnrg] draft-irtf-icnrg-icnlowpan-08.txt

From: Carsten Bormann <[email-masked]>
Date: Wed, 12 Aug 2020 20:54:01 +0200

Hi,

I am currently looking at draft-irtf-icnrg-icnlowpan-08.
I have a number of editorial comments I will send you when I have completed my review, but there also is a technical comment that I think needs to be fixed before this is going forward.

Section 12 has this table of allocations desired:

    +=============+======+===========================================+
    | Bit Pattern | Page | Header Type                               |
    +=============+======+===========================================+
    |  00 0xxxxx  | TBD1 | Uncompressed NDN Interest messages        |
    +-------------+------+-------------------------------------------+
    |  00 1xxxxx  | TBD1 | Uncompressed NDN Data messages            |
    +-------------+------+-------------------------------------------+
    |  01 0xxxxx  | TBD1 | Compressed NDN Interest messages          |
    +-------------+------+-------------------------------------------+
    |  01 1xxxxx  | TBD1 | Compressed NDN Data messages              |
    +-------------+------+-------------------------------------------+
    |  10 0xxxxx  | TBD1 | Uncompressed CCNx Interest messages       |
    +-------------+------+-------------------------------------------+
    |  10 1xxxxx  | TBD1 | Uncompressed CCNx Content Object messages |
    +-------------+------+-------------------------------------------+
    |  11 0xxxxx  | TBD1 | Compressed CCNx Interest messages         |
    +-------------+------+-------------------------------------------+
    |  11 1xxxxx  | TBD1 | Compressed CCNx Content Object messages   |
    +-------------+------+-------------------------------------------+

         Table 1: Dispatch types for NDN and CCNx with page TBD1.

Compare the registry at https://www.iana.org/assignments/_6lowpan-parameters/_6lowpan-parameters.txt :

   11 11xxxx   0-15 Page switch             [RFC8025]

So none of the free pages (TBD1 values) can fulfill this request.

It seems to me that this can easily be repaired by using two half pages instead of a full page, e.g. by indicating NDN vs. CCNx in the page number instead of the P bit (the most significant bit, which is now the P bit, would always be 0).

What have you been using in the existing experiments?

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 15 Aug 2020 14:42:45 +0200

> It seems to me that this can easily be repaired by using two half pages instead of a full page, e.g. by indicating NDN vs. CCNx in the page number instead of the P bit (the most significant bit, wh…

Having completed my initial review (and having sent a set of editorial comments to the authors), I now have a slightly different proposal:
Since there are only really 4 code points for uncompressed, put these at 0x80..0x83, and put the compressed ones at 0x00..0x7f.

So the (now inverted) C-bit would be bit 0, and NDN/CCNx and Interest/Data could be bit 6 and 7.

This also enables to put the whole 132 code points into page 15, which might be more appropriate for an experiment (and wouldn’t require an IANA allocation), but that is certainly a change that would require more attention from other participants of the experiment that might have other experimental code points out in the same experiment.  (Alternatively, this RFC could ask for allocating page 14 to experimental, as well, and suggest a page 14 mapping for ICNLOWPAN, leaving 108 code points in page 14 free and not impinging on other experiments.)

Since this draft is consuming space that ultimately belongs to 6lo, it may be appropriate to talk to that WG on how they see the evolution of that space.

It will probably help with that if a cogent statement can be made what the actual experiment is that this experimental RFC supports.  Although I sure can imagine what that might be, there is little information in the current draft.

Grüße, Carsten

---

From: Colin Perkins <[email-masked]>
Date: Mon, 17 Aug 2020 11:34:26 +0100

Hi,

I’m adding Pascal Thubert to the cc list, since we did an early review of this for IANA. There was some previous discussion of how to do these assignments to reduce the number of code points needed.

Colin

> On 15 Aug 2020, at 13:42, Carsten Bormann <[email-masked]> wrote:
> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 26 Aug 2020 00:26:19 +0200

While we are resolving the code point issues, below are a few more questions I had.

Grüße, Carsten

# Major

An experimental RFC might want to specify a bit more about the experiment(s) that are planned to be made based on the protocol being defined.

In 5.3.2, how do I know that a Nonce is present?
(Optional in https://named-data.net/doc/NDN-packet-spec/0.3/interest.html)

8.1: What do these conceptual contexts do?
I find nothing about that in here.
(RFC 6775 Section 7.2 has rules about context state evolution that probably are needed here as well.)
8.3: The meaning of Context ID chaining is not explained.

# Minor

The term “time-value” is used for what appears to be a duration, not an absolute time.  (Also, Figure 29 is highly misleading.)

The discussion in Section 4.2 (as well as the Security Considerations for that) might benefit from a reference to
draft-ietf-6lo-minimal-fragment, in RFC editor queue.
Does icnlowpan have any opinion on fragment forwarding?

The term “link fragmentation” might more properly called “adaptation layer fragmentation”.

The neat unary encoding for NDN types assumes that type numbers stay low.
In uncompressed NDN, all numbers between 253 and 65535 have the same cost (three
bytes); here they have very different cost.
NDN might go ahead and allocate higher numbers without knowledge of the damage inflicted to the unary coding approach.
Looking at
https://named-data.net/doc/NDN-packet-spec/0.3/types.html
it seems that only the range 800-1000 has been allocated at a (still
small) detriment to this unary scheme.
(I don’t think the design is wrong, I’m just thinking about ways to communicate the importance of small type numbers into the greater NDN space.)

5.2: Only the example says (implies) that the nibbles are used MSN first.

# Editorial

Define byte and nibble at the outset and simplify some of the text.

---

From: Martine Sophie Lenders <[email-masked]>
Date: Wed, 26 Aug 2020 09:36:37 +0200

Hello Carsten,

Am 26.08.20 um 00:26 schrieb Carsten Bormann:
> [...]

We (Cenk, Matthias, Thomas, and I) just got a short paper accepted at
ACM ICN 2020, that visits ICNLoWPAN in combination with
draft-ietf-6lo-fragment-recovery. Many of the findings there, are also
applicable for draft-ietf-6lo-minimal-fragment.

The paper will be publicly accessible soon, but to give a short preview:
The problem with fragment forwarding is that it effectively bypasses
en-route caching, as the fragmented data chunks are never presented to
the ICN layer. In our short paper we present a simple cross-layer
extension to 6LoWPAN Selective Fragment Recovery that allows to have
both fragment forwarding and en-route caching.

> [...]

Best regards,
Martine