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

David Oran <daveoran@orandom.net> Tue, 06 September 2016 18:50 UTC

Return-Path: <daveoran@orandom.net>
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 CB37812B374 for <icnrg-harmonization@ietfa.amsl.com>; Tue, 6 Sep 2016 11:50:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 3B3uaQLzDTKe for <icnrg-harmonization@ietfa.amsl.com>; Tue, 6 Sep 2016 11:50:20 -0700 (PDT)
Received: from spark.crystalorb.net (spark.crystalorb.net [IPv6:2607:fca8:1530::c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF89812B26D for <icnrg-harmonization@irtf.org>; Tue, 6 Sep 2016 11:50:20 -0700 (PDT)
Received: from [10.131.118.58] ([173.38.117.89]) (authenticated bits=0) by spark.crystalorb.net (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id u86IoDpk032444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 6 Sep 2016 11:50:15 -0700
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3225\))
From: David Oran <daveoran@orandom.net>
In-Reply-To: <D96E28F4A22C864DBC6C871B5B1C4CC320CC7D8C@SJCEML701-CHM.china.huawei.com>
Date: Tue, 06 Sep 2016 14:50:07 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <0DD0C66E-8594-421C-A4E7-999F8D4A5CE9@orandom.net>
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> <D96E28F4A22C864DBC6C871B5B1C4CC320CC7D37@SJCEML701-CHM.china.huawei.com> <F4C4FD0E-93D9-4BBD-BEBD-79802202CAF7@orandom.net> <D96E28F4A22C864DBC6C871B5B1C4CC320CC7D8C@SJCEML701-CHM.china.huawei.com>
To: Ravi Ravindran <ravi.ravindran@huawei.com>
X-Mailer: Apple Mail (2.3225)
Archived-At: <https://mailarchive.ietf.org/arch/msg/icnrg-harmonization/-8n0Jdo2bHRWLwHqWSFcpTcfigs>
Cc: "icnrg-harmonization@irtf.org" <icnrg-harmonization@irtf.org>, Lixia Zhang <lixia@cs.ucla.edu>, Mark Mosko <Marc.Mosko@parc.com>, Alex Afanasyev <aa@cs.ucla.edu>
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 18:50:23 -0000

> On Sep 6, 2016, at 2:31 PM, Ravi Ravindran <ravi.ravindran@huawei.com> wrote:
> 
> The difference is, if the network has knowledge of a resource, and explicitly knows how to reach it via a link that encodes a named storage service, host, or a border node that takes the interest to another domain.
Why isn’t that just a FIB entry? What am I missing?

> Then the network should be able to mark it (also insert such a link if required) so that the forwarder uses the link to route the Interest to that name,
that’s an interesting design point, independent of the whole locator thing. Should forwarders be allowed to insert routing hints, or only consumers? What kind of on-path attacks get opened by this? Can forwarding paths be diagnosed better/worse if this is allowed? Who is responsible for checking the signature on such routing information? Is am I ok with the Russian ISP checking signatures on links purporting to point to the U.S. but signed by the North Koreans?

> instead of working with an assumption that finding the resource with the Interest name and the link is equally likely.
The “likeliness” is usually represented by routing metrics. Why invent something special?

> 
> Regards,
> Ravi
> 
> -----Original Message-----
> From: David Oran [mailto:daveoran@orandom.net] 
> Sent: Tuesday, September 06, 2016 11:20 AM
> To: Ravi Ravindran
> Cc: icnrg-harmonization@irtf.org; Lixia Zhang; Mark Mosko; Alex Afanasyev
> Subject: Re: [Icnrg-harmonization] NDN use of nameless Data
> 
> 
>> On Sep 6, 2016, at 2:17 PM, Ravi Ravindran <ravi.ravindran@huawei.com> wrote:
>> 
>> I'm OK with using the terms Link or Hints, its use as a locator is a special case, considering the scope of the Link Alex mentioned. But the forwarder should be able to distinguish these two behavior, i.e. use it as a hint or use it as explicit locator considering different network contexts.
>> 
> What do you think the difference is? I don’t see any.
> 
>> Regards,
>> Ravi  
>> 
>> -----Original Message-----
>> From: David Oran [mailto:daveoran@orandom.net] 
>> Sent: Tuesday, September 06, 2016 7:53 AM
>> To: Ravi Ravindran
>> Cc: Alex Afanasyev; icnrg-harmonization@irtf.org; Mark Mosko; Lixia Zhang
>> Subject: Re: [Icnrg-harmonization] NDN use of nameless Data
>> 
>> 
>>> 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
> 
> _______________________________________________
> Icnrg-harmonization mailing list
> Icnrg-harmonization@irtf.org
> https://www.irtf.org/mailman/listinfo/icnrg-harmonization