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

Cenk Gündoğan <mail+ietf@gundogan.net> Thu, 11 July 2019 13:42 UTC

Return-Path: <mail+ietf@gundogan.net>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 846A6120111 for <icnrg@ietfa.amsl.com>; Thu, 11 Jul 2019 06:42:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level:
X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, FROM_EXCESS_BASE64=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (bad RSA signature)" header.d=gundogan.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UG4pBX8PQONR for <icnrg@ietfa.amsl.com>; Thu, 11 Jul 2019 06:42:43 -0700 (PDT)
Received: from mail.localdomain (trantor.gundogan.net [37.120.167.193]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CBE5120077 for <icnrg@irtf.org>; Thu, 11 Jul 2019 06:42:43 -0700 (PDT)
Received: from localhost (unknown [141.22.28.154]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by mail.localdomain (Postfix) with ESMTPSA id AF2771F274 for <icnrg@irtf.org>; Thu, 11 Jul 2019 15:32:06 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gundogan.net; s=201712; t=1562851926; bh=H78oQMVErd5yms8MdoaFTUBCrJEPvOmdU1wEiJP1UrY=; h=References:From:To:Subject:In-reply-to:Date:From; b=Z/GCWNj4OMvsi+JFvoB/MnxiKy8p4pFxEoF55UttghPTzBbUqJCVhinMmt9IWh8jh cCO66lZIhnoLqO6MpSuWt8IBaGOOk0D8RQtuHCy4ZPqngclWwGj28cwteo5geUs/1D UHn41Td9yL34iUhuE6MVntRL0+CVHvhUKGf+aWhRPyd9Jh/AxiCWpW10BncJJVJqGX WOb0WiaP/1y3cgcKH0XrtUzgdmhVBdQ7VWehFXzK9VN+ZhtAuk+wT1ltDj6CtyeB1T /P978U/HXjN26f1pIFIkMOhxmmReeba1wnNsyRmifrE1lDClRnULsigdtqQnyYl9d+ XVtlUAeWfclbg==
References: <156260393493.1051.11242685769343831174@ietfa.amsl.com> <8736jg4gr2.fsf@gundogan.net> <CAOFH+OYi+fb7tM5TvLgwb3noY2=zEvTsUeWnTnoFOgL5-crNsw@mail.gmail.com>
User-agent: mu4e 1.2.0; emacs 26.2
From: Cenk Gündoğan <mail+ietf@gundogan.net>
To: icnrg@irtf.org
In-reply-to: <CAOFH+OYi+fb7tM5TvLgwb3noY2=zEvTsUeWnTnoFOgL5-crNsw@mail.gmail.com>
Date: Thu, 11 Jul 2019 15:42:40 +0200
Message-ID: <87k1coy9f3.fsf@gundogan.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/JxPQywy27Mm-chBxbQfTBlKDRyw>
Subject: Re: [icnrg] Fwd: I-D Action: draft-irtf-icnrg-icnlowpan-03.txt
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Information-Centric Networking research group discussion list <icnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg>, <mailto:icnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/icnrg/>
List-Post: <mailto:icnrg@irtf.org>
List-Help: <mailto:icnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg>, <mailto:icnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Jul 2019 13:42:47 -0000

Hello Junxiao,

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

On Mon, Jul 08 2019 at 19:36 +0200, Junxiao Shi wrote:

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

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?

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

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?

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

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?

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

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?

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

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?

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

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

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

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.

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

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
> citation to use https.

Alright, thanks (:

Cheers,
Cenk

>
> Yours, Junxiao
>
> On Mon, Jul 8, 2019 at 12:46 PM Cenk Gündoğan <mail=2Bietf=
> 40gundogan.net@dmarc.ietf.org> wrote:
>
>> 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, internet-drafts@ietf.org wrote:
>>
>> > 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
>>
>>
> _______________________________________________
> icnrg mailing list
> icnrg@irtf.org
> https://www.irtf.org/mailman/listinfo/icnrg