Re: [Icnrg-harmonization] NDN use of nameless Data

<Marc.Mosko@parc.com> Tue, 06 September 2016 00:51 UTC

Return-Path: <Marc.Mosko@parc.com>
X-Original-To: icnrg-harmonization@ietfa.amsl.com
Delivered-To: icnrg-harmonization@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E41812B096 for <icnrg-harmonization@ietfa.amsl.com>; Mon, 5 Sep 2016 17:51:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 txHtLertssc9 for <icnrg-harmonization@ietfa.amsl.com>; Mon, 5 Sep 2016 17:51:17 -0700 (PDT)
Received: from smtp.parc.xerox.com (alpha.Xerox.COM [13.1.64.93]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFB7612B006 for <icnrg-harmonization@irtf.org>; Mon, 5 Sep 2016 17:51:16 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.parc.xerox.com (Postfix) with ESMTP id 7DC5F6C009A; Mon, 5 Sep 2016 17:51:14 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at newalpha.parc.com
Received: from smtp.parc.xerox.com ([127.0.0.1]) by localhost (smtp.parc.xerox.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIUJFD09I88H; Mon, 5 Sep 2016 17:51:14 -0700 (PDT)
Received: from exchangehub.parc.xerox.com (e2010hub1.parc.xerox.com [13.2.12.22]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.parc.xerox.com (Postfix) with ESMTPS id 47EA86C00BD; Mon, 5 Sep 2016 17:51:14 -0700 (PDT)
Received: from E2010DAG5.corp.ad.parc.com ([fe80::3d0b:7158:aec4:e05e]) by e2010hub1.corp.ad.parc.com ([fe80::8945:a39d:8c92:373f%11]) with mapi id 14.03.0301.000; Mon, 5 Sep 2016 17:51:27 -0700
From: Marc.Mosko@parc.com
To: lixia@cs.ucla.edu
Thread-Topic: [Icnrg-harmonization] NDN use of nameless Data
Thread-Index: AQHSBGTUckNfPjJQ5026HaHPYKaunqBsEyOAgAAK7IA=
Date: Tue, 06 Sep 2016 00:51:27 +0000
Message-ID: <5AB13B86-DF40-430A-B666-1B0788D60267@parc.com>
References: <92ABC834-3C47-4B3C-9D85-83493B8B9414@parc.com> <E30DB839-01C8-42C0-BCE8-0381AFC2BC90@cs.ucla.edu>
In-Reply-To: <E30DB839-01C8-42C0-BCE8-0381AFC2BC90@cs.ucla.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [50.0.67.90]
Content-Type: multipart/alternative; boundary="_000_5AB13B86DF40430AB6661B0788D60267parccom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg-harmonization/X1hZOcsQeYW79KvIlR6EGrGVrsc>
Cc: icnrg-harmonization@irtf.org
Subject: Re: [Icnrg-harmonization] NDN use of nameless Data
X-BeenThere: icnrg-harmonization@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: ICN Harmonization Discussion <icnrg-harmonization.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg-harmonization>, <mailto:icnrg-harmonization-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/icnrg-harmonization/>
List-Post: <mailto:icnrg-harmonization@irtf.org>
List-Help: <mailto:icnrg-harmonization-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg-harmonization>, <mailto:icnrg-harmonization-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Sep 2016 00:51:19 -0000

On Sep 5, 2016, at 5:12 PM, Lixia Zhang <lixia@cs.ucla.edu<mailto:lixia@cs.ucla.edu>> wrote:

On Sep 1, 2016, at 8:23 AM, Marc.Mosko@parc.com<mailto:Marc.Mosko@parc.com> wrote:

There has been a bit of talk about CCNx making explicit the use of nameless objects, but I’d like to point out that one can do essentially the same thing in NDN using the Interest Link.  If CCNx were to adopt the Link approach to routing indirection, it could be done this way too (though using the ContentObjectHashRestriction field, not the implicit digest).

This is based on the 0.2-alpha-3 NDN packet format specification and the SNAMP-NDN-Scalability.pdf paper.  If I have misread something, please let me know.

Personal opinion: I am afraid that the above reflects a misunderstanding of NDN names and the role of LINK object.

It might not be in accordance with the intention, but I think it is allowed by the definitions.

Is it supposed to be illegal to use only hash-based naming in NDN?  We had talked about that usage some back in the early CCNx days, using only an implicit hash, or a name simply like “/objectstore/<implicithash>”.


The NDN spec says a Name is zero or more NameComponent.

I do not agree with the "nameless object" concept (in fact CCNx 1.x's nameless object indeed has a name, the content hash), and I do not believe NDN names allow zero component.

I just looked at the spec and did not see such statement; I searched the page, the only appearance of the word "zero" is in describing how to "unambiguously represent name components that would collide with the use of . and .. for relative URIs"

If I missed anything, please point out to me and we'll fix it.

From this page http://named-data.net/doc/ndn-tlv/name.html


Name ::= NAME-TYPE TLV-LENGTH NameComponent*



It’s my understanding that an * means zero or more, i.e. optional.  If you want it to be 1 or more, then change it to “+”, as I think your pages are using regex-like syntax not ABNF.

However, I don’t think that’s what you want to do, because you probably use a zero-component name to indicate the default route.  So, you probably need to either define a non-zero name and use that in the Data definition, or add some text in the paragraph that defines the name to say it cannot be a zero-length name.  I’d personally use the first approach as the regex/ABNF should be the authoritative definition, not the text.


Lixia

PS: there seems a huge conceptual confusion about names and locators, that we really to clean up someday soon.

Therefore, I can create a Data object with an empty name.  In an Interest, I can put one NameComponent of type ImplicitSha256DigestComponent and set Min/Max SuffixComponents to 0 and then include one or more Link objects in the Interest for routing.

My understanding of NDN is that because the ImplicitSha256DigestComponent is not in the FIB, a forwarder will forward via the Link.  The nameless Data Object – having 0 name components – will have a FullName of only its ImplicitSha256DigestComponent and that will match the name in the Interest.

I believe this use of NDN also maintains the property we were going after in CCNx nameless objects in that one cannot poison the cache by feting a Data object by hash that could then later be confused with a Data object being fetched by prefix or name (unless one put a 0 component name in the Interest with MaxSuffixComponents of at least 1 and used Link routing).

Marc
_______________________________________________
Icnrg-harmonization mailing list
Icnrg-harmonization@irtf.org<mailto:Icnrg-harmonization@irtf.org>
https://www.irtf.org/mailman/listinfo/icnrg-harmonization

_______________________________________________
Icnrg-harmonization mailing list
Icnrg-harmonization@irtf.org<mailto:Icnrg-harmonization@irtf.org>
https://www.irtf.org/mailman/listinfo/icnrg-harmonization