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

GQ Wang <gq.wang@huawei.com> Tue, 06 September 2016 01:08 UTC

Return-Path: <gq.wang@huawei.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 D608E12B0FA for <icnrg-harmonization@ietfa.amsl.com>; Mon, 5 Sep 2016 18:08:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.728
X-Spam-Level:
X-Spam-Status: No, score=-5.728 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, 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 zRWf13NNJTOr for <icnrg-harmonization@ietfa.amsl.com>; Mon, 5 Sep 2016 18:08:06 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD51012B0CF for <icnrg-harmonization@irtf.org>; Mon, 5 Sep 2016 18:08:05 -0700 (PDT)
Received: from 172.18.9.243 (EHLO DFWEML703-CAH.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BTV56988; Mon, 05 Sep 2016 20:05:50 -0500 (CDT)
Received: from SJCEML703-CHM.china.huawei.com (10.218.25.36) by DFWEML703-CAH.china.huawei.com (10.193.5.177) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 5 Sep 2016 18:05:49 -0700
Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.36]) by SJCEML703-CHM.china.huawei.com ([169.254.5.218]) with mapi id 14.03.0235.001; Mon, 5 Sep 2016 18:05:42 -0700
From: GQ Wang <gq.wang@huawei.com>
To: Lixia Zhang <lixia@cs.ucla.edu>, Ravi Ravindran <ravi.ravindran@huawei.com>
Thread-Topic: [Icnrg-harmonization] NDN use of nameless Data
Thread-Index: AQHSBGTUckNfPjJQ5026HaHPYKaunqBk8c4ggAch2QD//5S2wA==
Date: Tue, 6 Sep 2016 01:05:41 +0000
Message-ID: <6759D6D370C7024D9BB22CD5F92D2D3320FD3AD4@SJCEML701-CHM.china.huawei.com>
References: <92ABC834-3C47-4B3C-9D85-83493B8B9414@parc.com> <D96E28F4A22C864DBC6C871B5B1C4CC320CC5020@SJCEML701-CHM.china.huawei.com> <D3ECA763-0117-4F51-AEE6-7EEB50967C0A@cs.ucla.edu>
In-Reply-To: <D3ECA763-0117-4F51-AEE6-7EEB50967C0A@cs.ucla.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.212.245.42]
Content-Type: multipart/alternative; boundary="_000_6759D6D370C7024D9BB22CD5F92D2D3320FD3AD4SJCEML701CHMchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg-harmonization/9qSUVpBr5dtAFfmALS_SM9-1KtU>
Cc: "icnrg-harmonization@irtf.org" <icnrg-harmonization@irtf.org>, "Marc.Mosko@parc.com" <Marc.Mosko@parc.com>
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 01:08:09 -0000

From my understanding, the "link" in NDN represents a "domain", whether it is interpreted as ownership domain, routing domain or some else domain.
The domain has a container relationship with the named object. In NDN/CCN, the domain is used for navigating the reachability of a named object,
it is either representing a home server/network, a attachment point, a storage, etc, for the data acquiring operation.
Regards,
G.Q


From: Icnrg-harmonization [mailto:icnrg-harmonization-bounces@irtf.org] On Behalf Of Lixia Zhang
Sent: Monday, September 05, 2016 5:14 PM
To: Ravi Ravindran
Cc: icnrg-harmonization@irtf.org; Marc.Mosko@parc.com
Subject: Re: [Icnrg-harmonization] NDN use of nameless Data


On Sep 1, 2016, at 11:24 AM, Ravi Ravindran <ravi.ravindran@huawei.com<mailto:ravi.ravindran@huawei.com>> wrote:

But one big difference here with CCNx is that, in NDN is that all objects are named.

Yes, hence the name of the architecture: named data networking :-)


I think we should reconsider this notion of nameless objects in CCNx, and define a way to carry locator names in the Interest messages.

Regards,
Ravi

To me the so called "locator" is another misconception.

Lixia



From: Icnrg-harmonization [mailto:icnrg-harmonization-bounces@irtf.org] On Behalf Of Marc.Mosko@parc.com<mailto:Marc.Mosko@parc.com>
Sent: Thursday, September 01, 2016 8:24 AM
To: icnrg-harmonization@irtf.org
Subject: [Icnrg-harmonization] NDN use of nameless Data

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.

The NDN spec says a Name is zero or more NameComponent.  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