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

Junxiao Shi <shijunxiao@email.arizona.edu> Thu, 11 July 2019 20:24 UTC

Return-Path: <shijunxiao@email.arizona.edu>
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 B127A120121 for <icnrg@ietfa.amsl.com>; Thu, 11 Jul 2019 13:24:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.601
X-Spam-Level:
X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=email-arizona-edu.20150623.gappssmtp.com
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 uR-g8VTr1u51 for <icnrg@ietfa.amsl.com>; Thu, 11 Jul 2019 13:24:27 -0700 (PDT)
Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14E8312000F for <icnrg@irtf.org>; Thu, 11 Jul 2019 13:24:26 -0700 (PDT)
Received: by mail-oi1-x22e.google.com with SMTP id s184so5529733oie.9 for <icnrg@irtf.org>; Thu, 11 Jul 2019 13:24:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=email-arizona-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hPITrh1ZfpzBXDCVdBwsV/4j3Im7ssFkt9M2rPYZ5Wk=; b=YkzZYW4aw7i10AhCA0nzLmFOdGXbDWyhN4wuSOacZA45AGvQLLNYZt9OepFRFLLXPz ASpRQZDKqUHkxI0MnoLCOJVWpSldzs6ZddQo2p/3e2VzvX9CnIlyG4tEgoYxaxUw9WDT FDoGu3/+apsvPX10AGHMGycQbi3F4ggiMnTdkoSzmVyiBVxRHfAJfPKN5L2h+9tiqWG4 kYK+14KilAHz7WQFS8ZayTmUeHY/Z9ft6Uw6vefobSTj7wEfxqljZBIBJjYCyPA4suqN BttfeIuEwass48Ttmk5A0OK8FIaVwnq8q3LlrUEGKkgW/u/iJQmQv76wTX+vr9UVZpvi yLCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hPITrh1ZfpzBXDCVdBwsV/4j3Im7ssFkt9M2rPYZ5Wk=; b=HgkkESfMZg83jJNzcfxRUEeQ9JS+iuV6sYpA5u5xUv2U2rVIYh9e1RuidwDHUnMYdx gduMswwtR5ZEp5zGKfvCaLZgzV+lRdJMeeSthMBnnl88UyI/CVQnueIXLEViqdV5uHYA ql2TnVD9g3wo2vtOqraNs1znFYgX3wrJBeaUoERIX26Xc8pJXMAN34eBLWIvZtvIL5oY 4M2jJZcBpcXm6wyZjBDspjPfOsw5pPqkE1Jwl0YRnMP2jDjPpCj3tc/hgF7a/cwvAVl+ 8dkPhV6byXq+xtxKSrt/cwsL35EwWPqNTGe/kjNLbcComgxkD++sgTpCI6ehy6h1KWW9 i9CQ==
X-Gm-Message-State: APjAAAWEfAPgUa4jNsbke2/1s1Dsw23X7B3eJLzPvr2/gDmo4hom216y E0+gQJyfmEGCAJ8ZkvI8ldo9y2tUloBdyrYjx5MrQOuqkw==
X-Google-Smtp-Source: APXvYqwRBttO8MN2D6EwQTiqNN1pIRbDncQtG6KeoMiEpft535KmtQq9QyPgDK86mGPpl5Y/M8d11Vox3wQtIQ3Cv8o=
X-Received: by 2002:aca:75c2:: with SMTP id q185mr3792508oic.103.1562876665823; Thu, 11 Jul 2019 13:24:25 -0700 (PDT)
MIME-Version: 1.0
References: <156260393493.1051.11242685769343831174@ietfa.amsl.com> <8736jg4gr2.fsf@gundogan.net> <CAOFH+OYi+fb7tM5TvLgwb3noY2=zEvTsUeWnTnoFOgL5-crNsw@mail.gmail.com> <87k1coy9f3.fsf@gundogan.net>
In-Reply-To: <87k1coy9f3.fsf@gundogan.net>
From: Junxiao Shi <shijunxiao@email.arizona.edu>
Date: Thu, 11 Jul 2019 16:23:49 -0400
Message-ID: <CAOFH+OY+CVSjAhP9vrO9_Zw6y+2ZVodpnDAgsMMxLFVXBKGPCw@mail.gmail.com>
To: Cenk Gündoğan <mail=2Bietf=40gundogan.net@dmarc.ietf.org>
Cc: icnrg@irtf.org
Content-Type: multipart/alternative; boundary="0000000000007e99aa058d6d94c3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg/vlyMl0t2rKtSxq9kwiKpZurBskA>
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 20:24:30 -0000

Hi Cenk

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

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

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

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

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

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.


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

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.


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

Issue tracker for NDN protocols is at
https://redmine.named-data.net/projects/ndn-tlv/issues
I'm unaware of major upcoming 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?
>

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

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

Yes this is correct.


Yours, Junxiao