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

"Thompson, Jeff" <> Tue, 06 September 2016 16:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DC49A12B4F8 for <>; Tue, 6 Sep 2016 09:01:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.708
X-Spam-Status: No, score=-5.708 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rg_U2bBtfmGi for <>; Tue, 6 Sep 2016 09:01:27 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 54B7712B6C2 for <>; Tue, 6 Sep 2016 08:49:00 -0700 (PDT)
Received: from ([]) by ([]) with mapi id 14.03.0235.001; Tue, 6 Sep 2016 08:48:59 -0700
From: "Thompson, Jeff" <>
To: David Oran <>
Thread-Topic: [Icnrg-harmonization] NDN use of nameless Data
Thread-Index: AQHSBGTUckNfPjJQ5026HaHPYKaunqBk8c4ggAch2QD//90pkIAAhseAgAASyzCAAH8GgP//migA
Date: Tue, 6 Sep 2016 15:48:58 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>
Subject: Re: [Icnrg-harmonization] NDN use of nameless Data
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: ICN Harmonization Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 06 Sep 2016 16:01:32 -0000

> b) how does a forwarder decide where to forward the interest if (a)
>above returns ³not found².

The forwarder has to decide where to forward the interest to get a data
packet which not only has a matching name, but has a signature that the
consumer will trust (since it is the consumer who verifies the packet). In
a future Internet with a billion producers, most of them mobile, there
could be many packets floating around with a matching name, but only one
with a signature that the consumer will trust. I had always assumed that
this is why the consumer has to put something in the interest - not to
tell the network where to find a data packet with a matching name (too
easy), but where to find a producer who will cough up a data packet with a
signature that the consumer will trust.

- Jeff T

On 2016/9/6, 7:53:27, "Icnrg-harmonization on behalf of David Oran"
< on behalf of>

>> On Sep 6, 2016, at 10:32 AM, Ravi Ravindran <>
>> I agree with the distinction between link and locator, but in
>>administered domains 'links' will most likely will  be used as locators,
>>as you have absolute knowledge of the cache/storage, or the attachment
>>point of the device etc. In this case, links can be given priority over
>>the names in the Interest packet, and avoid trying to route on both
>>these names simultaneously.
>This to me illustrates very well why the term ³locator² is really
>problematic in the context of ICN. Let¹s get rid of it.
>There are two related but separate functions:
>a) how does a forwarder match an interest to either a local application
>or a cached copy of the data object.
>b) how does a forwarder decide where to forward the interest if (a) above
>returns ³not found².
>Neither of these requires anything like a locator.
>A forwarder can use any information it has at its disposal to figure (b)
>out. It could have a useful LPM entry in its FIB matching a prefix of the
>name in the interest. It could consult an oracle. It could send the
>Interest to the CIA (who knows where the data is). If could send the
>interest to the NSA, who undoubtedly already has it. It could us a hint
>in the Interest message (e.g. a Link). None of these is a ³locators². Or
>perhaps they all are, in which case the term is equally usless.
>> Regards,
>> Ravi
>> -----Original Message-----
>> From: Alex Afanasyev []
>> Sent: Monday, September 05, 2016 11:12 PM
>> To: Ravi Ravindran
>> Cc: Lixia Zhang;;
>> Subject: Re: [Icnrg-harmonization] NDN use of nameless Data
>>> On Sep 5, 2016, at 10:23 PM, Ravi Ravindran
>>><> wrote:
>>> I¹m not sure if there is any disagreement about this that, there are
>>>two types of names in ICN, one what application binds to, and managed
>>>by the application providers, called identifiers. And the names that
>>>are relevant to the network layer to identify networks, routers, border
>>>nodes, hosts etc, managed by the infrastructure provider, hence
>>>topological and can be used for routing, late binding etc, which we
>>>call locators.
>> I don't fully agree with the distinction.  Some names will be managed
>>by the operators.  However, it does not mean that only those names can
>>be used to forward Interests.  While I cannot predict future for real, I
>>can see that prefixes for the "popular data" (e.g., from google, amazon,
>>netflix, etc.) will be reachable directly.
>> If we still have routing system similar to what we have today (I'm
>>leaving the door open here), then not-so-popular application data would
>>need to be mapped to other names that can guide the interests.
>>> Isn¹t the link defined in SNAMP paper same as locators ?
>> I think this is a continuation of the discussion we had a few meetings
>>back.  There is similarity, but there is also semantical differences
>>from what word "locator" implies:
>> - (1) The link from SNAMP paper is a hint for the routers on where the
>>data may be available.
>> - (2) The link does not imply that interests must be forwarded to a
>>specific "location" to retrieve data, e.g., data can be retrieved from
>>without using the link or on the way(s) pointed by the link.
>> - (3) The name in the link might not be even a "location", just a
>>direction(s) or way(s) to follow to have a chance to meet the data.
>>Here I would like to highlight the fact that some name prefixes would be
>>announced from different places, i.e., the way(s) to meet the data is
>>not pre-determined.
>> --
>> Alex
>>> Regards,
>>> Ravi
>>> From: Lixia Zhang []
>>> Sent: Monday, September 05, 2016 5:14 PM
>>> To: Ravi Ravindran
>>> Cc:;
>>> Subject: Re: [Icnrg-harmonization] NDN use of nameless Data
>>> On Sep 1, 2016, at 11:24 AM, Ravi Ravindran
>>><> 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
>>>[] On Behalf Of
>>> Sent: Thursday, September 01, 2016 8:24 AM
>>> To:
>>> 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
>>> 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
>>> 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 mailing list
>> _______________________________________________
>> Icnrg-harmonization mailing list
>Icnrg-harmonization mailing list