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

[Alex Afanasyev]

On Oct 10, 2014, at 2:42 PM, Ignacio.Solis at parc.com wrote:

> On 10/10/14, 1:01 PM, "Alex Afanasyev" <alexander.afanasyev at ucla.edu>
> wrote:
> 
>> On Oct 10, 2014, at 12:48 PM, <Ignacio.Solis at parc.com>
>> <Ignacio.Solis at parc.com> wrote:
>>>>> 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).
>>> 
>>> The ContentObjectHash restriction in CCN is over the Content Object (as
>>> the name implies).  This includes the name and signature (if present).
>> 
>> Sorry. I misunderstood then.  So, this basically exactly the same thing,
>> covering Name, meta parts of the data packet, Content, and signature
>> parts?
> 
> Basically yes.  It just doesn’t cover the static header and optional
> headers (which you don’t have in NDN).
> 
> 
> 
>>> It is the same as the implicit hash in the sense that the hash is
>>> implicit
>>> in the content object.  This is calculated over the message. The static
>>> headers and the optional headers are NOT part of the message.
>>> 
>>> We don¹t exclude data, so that is, effectively, impossible for CCN.
>>> Having said that, if you followed the SelectorProtocol described in the
>>> NDN-interest list this ContentObjectHash would be able to be used for
>>> excludes just like the ones on NDN.  It servers the same purpose but
>>> it¹s
>>> not part of a name.
>>> 
>>> It is NOT true that the content you get can have any name.  The content
>>> has either a) the exact same name as the interest (after all, we do
>>> exact
>>> matching), or b) no name at all.
>>> 
>>> Also, I don¹t understand why you say that the app needs to know what
>>> segment you¹re getting.  Didn¹t you request the content with a name
>>> anyway?  Use that name.  Also, if you have a ContentObjectHash, that
>>> means
>>> somebody gave you that hash, did they not tell you what this hash was
>>> for?
>> 
>> I just gave an example of what can go wrong with this.  Yes, you're
>> requesting by hash.  But if the only thing you know is the hash, how
>> would you reliably reconstruct the whole thing without relying on
>> something extra (like the order in manifest).
> 
> You still need a name, otherwise the Interest would not have been
> forwarded.
> 
> Also, I’m not sure where you would get a hash only.  If you did get the
> hash (and some potentially uninformative name) from the manifest, then you
> already have that info, it’s in the manifest.

Yes, manifest can have such information, which in such a hypothetical case would need to be remembered somewhere.  However, I think it is important to keep all relevant information in the Name, so it can be (to some extent) used on its own (less things to remember in the app/library).

>> In any case, this is a separate discussion and the primary goal for my
>> original email is to move the NDN spec forward.
> 
> I was just clearing up the CCN methods. Even if you don’t do the same
> thing in NDN, at least it would hopefully inform you of what we’re doing
> in CCN so you can make good architectural choices.

Sure, you're always welcome.  Thanks for the comments and corrections.

---
Alex


> Nacho
> 
> 
> --
> Nacho (Ignacio) Solis
> Protocol Architect
> Principal Scientist
> Palo Alto Research Center (PARC)
> +1(650)812-4458
> Ignacio.Solis at parc.com