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

"Thompson, Jeff" <jefft0@remap.ucla.edu> Tue, 06 September 2016 16:01 UTC

Return-Path: <jefft0@remap.ucla.edu>
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 DC49A12B4F8 for <icnrg-harmonization@ietfa.amsl.com>; Tue, 6 Sep 2016 09:01:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.708
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rg_U2bBtfmGi for <icnrg-harmonization@ietfa.amsl.com>; Tue, 6 Sep 2016 09:01:27 -0700 (PDT)
Received: from EMHUB4.ad.ucla.edu (emhub4.ad.ucla.edu [169.232.42.122]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54B7712B6C2 for <icnrg-harmonization@irtf.org>; Tue, 6 Sep 2016 08:49:00 -0700 (PDT)
Received: from EM1A.ad.ucla.edu ([192.168.4.111]) by EMHUB4.ad.ucla.edu ([169.232.42.122]) with mapi id 14.03.0235.001; Tue, 6 Sep 2016 08:48:59 -0700
From: "Thompson, Jeff" <jefft0@remap.ucla.edu>
To: David Oran <daveoran@orandom.net>
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: <D3F43155.36D3C%jefft0@remap.ucla.edu>
References: <92ABC834-3C47-4B3C-9D85-83493B8B9414@parc.com> <D96E28F4A22C864DBC6C871B5B1C4CC320CC5020@SJCEML701-CHM.china.huawei.com> <D3ECA763-0117-4F51-AEE6-7EEB50967C0A@cs.ucla.edu> <D96E28F4A22C864DBC6C871B5B1C4CC320CC7853@SJCEML701-CHM.china.huawei.com> <B37BB9C3-85DB-4FC5-951C-C5774C6838B2@cs.ucla.edu> <D96E28F4A22C864DBC6C871B5B1C4CC320CC7A33@SJCEML701-CHM.china.huawei.com> <4F0AFDEA-D3A3-4436-99C3-0D7584FC33C3@orandom.net>
In-Reply-To: <4F0AFDEA-D3A3-4436-99C3-0D7584FC33C3@orandom.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.7.160722
x-originating-ip: [80.35.251.60]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <E9B3A0A3CEDDB349A70DCF6FAECF3655@em.ucla.edu>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg-harmonization/Gw1L2QXEhe3IrVpNwnMPC8cCpNU>
Cc: "icnrg-harmonization@irtf.org" <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 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"
<icnrg-harmonization-bounces@irtf.org on behalf of daveoran@orandom.net>
wrote:

>
>> On Sep 6, 2016, at 10:32 AM, Ravi Ravindran <ravi.ravindran@huawei.com>
>>wrote:
>> 
>> 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 [mailto:aa@cs.ucla.edu]
>> Sent: Monday, September 05, 2016 11:12 PM
>> To: Ravi Ravindran
>> Cc: Lixia Zhang; icnrg-harmonization@irtf.org; Marc.Mosko@parc.com
>> Subject: Re: [Icnrg-harmonization] NDN use of nameless Data
>> 
>> 
>>> On Sep 5, 2016, at 10:23 PM, Ravi Ravindran
>>><ravi.ravindran@huawei.com> 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 [mailto:lixia@cs.ucla.edu]
>>> Sent: Monday, September 05, 2016 5:14 PM
>>> To: Ravi Ravindran
>>> Cc: Marc.Mosko@parc.com; icnrg-harmonization@irtf.org
>>> Subject: Re: [Icnrg-harmonization] NDN use of nameless Data
>>> 
>>> 
>>> On Sep 1, 2016, at 11:24 AM, Ravi Ravindran
>>><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
>>> 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
>>> https://www.irtf.org/mailman/listinfo/icnrg-harmonization
>>> 
>>> _______________________________________________
>>> Icnrg-harmonization mailing list
>>> Icnrg-harmonization@irtf.org
>>> https://www.irtf.org/mailman/listinfo/icnrg-harmonization
>> 
>> _______________________________________________
>> Icnrg-harmonization mailing list
>> Icnrg-harmonization@irtf.org
>> https://www.irtf.org/mailman/listinfo/icnrg-harmonization
>
>_______________________________________________
>Icnrg-harmonization mailing list
>Icnrg-harmonization@irtf.org
>https://www.irtf.org/mailman/listinfo/icnrg-harmonization