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

["Thompson, Jeff" <[e-mail]>]

> 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"
<[e-mail] on behalf of [e-mail]>
wrote:

>
>> On Sep 6, 2016, at 10:32 AM, Ravi Ravindran <[e-mail]>
>>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:[e-mail]]
>> Sent: Monday, September 05, 2016 11:12 PM
>> To: Ravi Ravindran
>> Cc: Lixia Zhang; [e-mail]; [e-mail]
>> Subject: Re: [Icnrg-harmonization] NDN use of nameless Data
>> 
>> 
>>> On Sep 5, 2016, at 10:23 PM, Ravi Ravindran
>>><[e-mail]> 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:[e-mail]]
>>> Sent: Monday, September 05, 2016 5:14 PM
>>> To: Ravi Ravindran
>>> Cc: [e-mail]; [e-mail]
>>> Subject: Re: [Icnrg-harmonization] NDN use of nameless Data
>>> 
>>> 
>>> On Sep 1, 2016, at 11:24 AM, Ravi Ravindran
>>><[e-mail]> 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:[e-mail]] On Behalf Of
>>>[e-mail]
>>> Sent: Thursday, September 01, 2016 8:24 AM
>>> To: [e-mail]
>>> 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
>>> [e-mail]
>>> https://www.irtf.org/mailman/listinfo/icnrg-harmonization
>>> 
>>> _______________________________________________
>>> Icnrg-harmonization mailing list
>>> [e-mail]
>>> https://www.irtf.org/mailman/listinfo/icnrg-harmonization
>> 
>> _______________________________________________
>> Icnrg-harmonization mailing list
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/icnrg-harmonization
>
>_______________________________________________
>Icnrg-harmonization mailing list
>[e-mail]
>https://www.irtf.org/mailman/listinfo/icnrg-harmonization