[Nfd-dev] Please review the update of NDN-TLV spec, introducing implicit digest name component

[Alex Afanasyev]

Hi Dave,

On Oct 10, 2014, at 5:35 AM, Dave Oran (oran) <oran at cisco.com> wrote:

> Here’s a silly question.
> If the hash is now explicitly in the packet as a name component, isn’t is no long implicit but explicit?

Junxiao has already answered this question, but I'll try to do it in slightly different words.

This digest component is still "implicit", since it represents the hash of the Data packet.  It is not (and physically cannot be) present in the Data packet name, but is, logically, a last component of the Data packet's name.  The spec update just makes it explicit that this component represents this digest (so, forwarders don't need to guess) and explicitly defines the digest algorithm (sha256 for now, which can be easily rolled to a new one later if needed).

The primary, and I would say the only, reason to explicitly "mark" the implicit digest component in the Interest name is to allow simpler logic while implementing optimized version of NDN packet forwarding (I'll try to elaborate this in reply to Lan's question).

I can say for myself, but others would probably agree with me, that putting things directly in the name provides unification of the processing logic.  In other words, all selectors: right/left most child, exclude, and any other component-based selectors (the existing and/or new ones in the future) apply universally to any name components.  For example, however controversial it is, the exclude filter provides the client an ultimate ability to re-request a different data packet with the same name---when the first packet have wrong signature, is corrupted, or for any other reason the consumer decided that it got the wrong data.

Yes, the parc's proposal introduces hash restriction (aka selector).  As I understand correctly, this restriction is based on "content hash", rather than "data packet hash".   This is very different thing from the implicit hash and has very different use case:  content hash identifies "content", while implicit digest identifies specific Data packet (which is the atomic unit in NDN sense).  With just content hash it is impossible to "exclude" wrong data, since it is not really known whether the content is wrong or signature is wrong.  It also has implications while requesting Data: what you would get back is "content", which can have any name.  This may be acceptable in some cases, while not so in others where name is used by the application (e.g., if app needs to know which segment this returned piece of content belongs).

---
Alex

> On Oct 9, 2014, at 9:02 PM, Alex Afanasyev <alexander.afanasyev at UCLA.EDU> wrote:
> 
>> Hi all,
>> 
>> Quick background.  After many discussions, we concluded that it is important to amend current Name TLV definition,  to allow implicit digest component.  After this change, Interest that specify implicit digest, must use implicit digest component at the end of the Name in order for the forwarder/applications to consider it as implicit digest.  This explicit knowledge would allow us to simplify implementation of on-demand implicit digest calculation in NFD (with the old definition, there are several problems that prevented to implement this/significantly complicate implementation logic).
>> 
>> * * *
>> 
>> Please review the change to NDN-TLV spec: http://gerrit.named-data.net/#/c/1289/.  You can either leave comment in gerrit (+1 / -1) or give your feedback in this mailing list.
>> 
>> * * *
>> 
>> The change slightly redefines what NameComponent TLV is:
>> 
>> 
>>   Name ::= NAME-TYPE TLV-LENGTH NameComponent*
>> 
>>   NameComponent ::= GenericNameComponent |
>>                     ImplicitSha256DigestComponent
>> 
>>   GenericNameComponent ::= NAME-COMPONENT-TYPE TLV-LENGTH BYTE*
>> 
>>   ImplicitSha256DigestComponent ::= IMPLICIT-SHA256-DIGEST-COMPONENT-TYPE TLV-LENGTH(=32)
>>                                       BYTE{32}
>> 
>> 
>> - ``GenericNameComponent`` is a generic name component, without any restrictions on the content of the value.
>> 
>> - ``ImplicitSha256DigestComponent`` is an implicit SHA256 digest component and it is required to contain a value of 32 octets.
>> 
>> 
>> ---
>> Alex
>> 
>> 
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>