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

[Alex Afanasyev <[e-mail]>]

> On Sep 5, 2016, at 9:59 PM, [e-mail] wrote:
> 
> 
>> On Sep 5, 2016, at 9:21 PM, Alex Afanasyev <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>>> 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.
>> 
>> The fact that generic definition of the name allows zero component is not related to the fact that ALL data packets have name.  Name is the identifier of the data.  (What Lixia is arguing is that Interest packet must not have an empty name, as Interest should ask for something.  This part is an oversight in the current spec.)
> 
> I would say the full name (including the implicit hash) is the unique identifier of the data.  The prefix is for routing and the application data (version, segment, etc.) is for application conventions and in some cases discovery.  If I’m willing to route on hashes and have some other means of discovery, I don’t think it should be illegal to do that.
> 
> An Interest packet would have the implicit hash, so it would have a non-empty name field.

The point I was making is that there are no "nameless" data.  Each data packet has a name (full name), which identifies this specific data packet at the networking level.

>> In my opinion, there is no "nameless" Data in NDN.  I would like to say it even more generally, that in ICN there could not be "nameless" data, as name is data's identifier.  I understand that in CCNx 1.x spec you redefined the concept of the name, which creates a lot of confusion.
>> 
> 
> Really, we went back to the ability of CCNx 0.7 (and earlier) to use only hash-based naming, which was an ability that CCNx 1.0 lost when we split the hash restriction out of a name component and put it in a distinguished field.  If you go back and look at the old CCNx specs, you’ll see they permitted empty names too (https://github.com/ProjectCCNx/ccnx/blob/master/doc/technical/Name.txt <https://github.com/ProjectCCNx/ccnx/blob/master/doc/technical/Name.txt>).  You could also look at the old ccnx.dtd and ccnx.xsd, they specifically allow zero component names.
> 
> What we added was a rule about not matching the Interest name if the ContentObject had no name field, which is different from the CCNx 0.x days and introduced a locator.
> 
>> I would like also to reiterate my opinion that not properly naming each individual data packet is a serious limitation.  Yes, manifest and etc. can provide contexts to verify data, but it is really limitings.  Data packet by itself is worthless, as there is neither application context to which this packet belong nor security context to verify it.
> 
> Most data packets, by them self, are worthless; a single data packet is usually only a small fraction of some larger whole.  There are a small number of data packets that must be discoverable because those will lead one to knowing how to retrieve the remainder of the data.

Discoverable is for cases when exact name is not known.  I would agree that there is a small number of those.  There is a way greater amount of packets which are not yet generated, but the consumer would want to send interest to retrieve them (real time pipeline as an example here, but there are other cases such as IoT/DTN).

>> 
>> And additional point.  I would like to bring back the conversation we had last week, where we pointed out that there are many cases where consumer inherently cannot know neither the full nor exact name.  Therefore, I'm not quite sure where are we going with this conversation.  In general, each Data packet should have a unique name.  And in many cases, such as real-time data retrieval, the name should use predictable naming conventions, at the very least to allow pipelining of interests.
> 
> I am not making the point that all data or apps must do it this way.  I understand there are cases when one wants predictable names and discoverable names.
> 
> Not in general, but in specific, all data packets do have unique names via the implicit hash.  I think what you want to mandate is that all data packets have unique exact names (up to but not including the implicit hash).  You can have a recommendation that a producer not generate duplicate names, but there’s no way to enforce that in the system.
> 
> Would you completely rule out a NDN-based system that uses implicit hash names without some other prefix, even if those implicit hash names were in the FIB?

What I said does not rule this out.  In my opinion, this type of usage is possible, while applicable only to certain cases.

--
Alex

>> 
>>> 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] <mailto:[e-mail]>
>> https://www.irtf.org/mailman/listinfo/icnrg-harmonization
>