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

Ravi Ravindran <ravi.ravindran@huawei.com> Fri, 02 September 2016 16:50 UTC

Return-Path: <ravi.ravindran@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 88C4612D536 for <icnrg-harmonization@ietfa.amsl.com>; Fri, 2 Sep 2016 09:50:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.768
X-Spam-Level:
X-Spam-Status: No, score=-4.768 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=-0.548, 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 Bc2EnB5v2R6N for <icnrg-harmonization@ietfa.amsl.com>; Fri, 2 Sep 2016 09:50:19 -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 59AA212D190 for <icnrg-harmonization@irtf.org>; Fri, 2 Sep 2016 09:50:19 -0700 (PDT)
Received: from 172.18.9.243 (EHLO dfweml702-cah.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BTT38862; Fri, 02 Sep 2016 11:50:17 -0500 (CDT)
Received: from SJCEML703-CHM.china.huawei.com (10.218.25.36) by dfweml702-cah.china.huawei.com (10.193.5.176) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 2 Sep 2016 09:50:16 -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; Fri, 2 Sep 2016 09:50:14 -0700
From: Ravi Ravindran <ravi.ravindran@huawei.com>
To: "Marc.Mosko@parc.com" <Marc.Mosko@parc.com>, "icnrg-harmonization@irtf.org" <icnrg-harmonization@irtf.org>
Thread-Topic: NDN use of nameless Data
Thread-Index: AQHSBGTUckNfPjJQ5026HaHPYKaunqBk8c4ggABf/ICAARRr0A==
Date: Fri, 02 Sep 2016 16:50:13 +0000
Message-ID: <D96E28F4A22C864DBC6C871B5B1C4CC320CC6008@SJCEML701-CHM.china.huawei.com>
References: <92ABC834-3C47-4B3C-9D85-83493B8B9414@parc.com> <D96E28F4A22C864DBC6C871B5B1C4CC320CC5020@SJCEML701-CHM.china.huawei.com> <87A7A215-9145-4B1B-B240-213F0B1916B7@parc.com>
In-Reply-To: <87A7A215-9145-4B1B-B240-213F0B1916B7@parc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.212.246.82]
Content-Type: multipart/alternative; boundary="_000_D96E28F4A22C864DBC6C871B5B1C4CC320CC6008SJCEML701CHMchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg-harmonization/vWFFLU0D43RKPH6zPc53bHqV-Zk>
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: Fri, 02 Sep 2016 16:50:25 -0000

Hi Marc,

Few comments inline.

Regards,
Ravi

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 5:02 PM
To: Ravi Ravindran; icnrg-harmonization@irtf.org<mailto:icnrg-harmonization@irtf.org>
Subject: Re: [Icnrg-harmonization] NDN use of nameless Data

I think in a way that’s a distinction without much of a difference. If one uses the convention of putting an empty name in all the “nameless” Data Objects, the only way to retrieve them is by implicit hash + link.

Ravi> The point I was making is to treat Implicit hash restriction as a Name in the Interest message and not as a hash restriction, and have a separate TLV to handle locator names. To differentiate it from the exact match rule when one requests by a URI name, one has to identify it as a different type of name component in the Name TLV as in NDN. With this, the Interest processing rules don’t change ; except to calculate the hash digest of the content when it is requested by the implicit hash. This should hold good for both when a Content object is Named or Nameless (Nameless being a special type of named object as you indicate below).

In CCNx we made several definitions that basically lead to using no name instead of an empty name in nameless objects.  Because we use equality match on the name and do not append the implicit digest, it made more sense to not use a name at all than use an empty name.  In NDN, because the implicit digest is appended to the Data name, using an empty name does the same thing.

One could propose doing something similar to the NDN Interest link in ccnx too.  We could put a few slides together on that to see what it looks like and talk about it.

Ravi > Sure agree with this because as I see it now, one has to process the Interest packet with Implicit hash differently from the ones with URI names.

Marc

From: Ravi Ravindran <ravi.ravindran@huawei.com<mailto:ravi.ravindran@huawei.com>>
Date: Thursday, September 1, 2016 at 11:24 AM
To: Marc <Marc.Mosko@parc.com<mailto:Marc.Mosko@parc.com>>, "icnrg-harmonization@irtf.org<mailto:icnrg-harmonization@irtf.org>" <icnrg-harmonization@irtf.org<mailto:icnrg-harmonization@irtf.org>>
Subject: RE: NDN use of nameless Data

But one big difference here with CCNx is that, in NDN is that all objects are named. 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

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<mailto: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