Re: [icnrg] CCNx drafts

[Ravi Ravindran <[e-mail]>]

Please see inline for  my comments…

From: [e-mail] [mailto:[e-mail]]
Sent: Wednesday, April 06, 2016 3:28 PM
To: Ravi Ravindran; [e-mail]
Subject: Re: [icnrg] CCNx drafts

On 4/6/16, 3:07 PM, "icnrg on behalf of Ravi Ravindran" <[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> wrote:

I think that’s where I differ that we don’t simply define “Names as simply Network names”. In ICN, any base protocol definition has to define the source of the name, its features (being topological or not,  flat-names (self-certified), URI etc), particularly now when we are differentiating the producer of the content objects from the distributors.

I’m fine if you (or somebody else) wants to define a larger architecture scope document.  The documents we’ve been working on at ICNRG are a specific protocol definition.
They define:
- a data packet that has a “name” (optional), signature (optional) and an implicit hash.
- a request packet that has a “name” (required for forwarding), a keyId restriction (optional) and a hash restriction (optional).
- a request/response protocol based on these attributes.

Ravi> My issue is with the definition of a name in the Interest, which can be a locator and a application identifier as well; a forwarder  should distinguish these two cases.

I would’ve no problem, if the base protocol scope was only limited to named content objects, and explicitly state that  only those names are be used in the Interest as well. In this case we are only talking about names coming from application space. However, this discussion will eventually surface, when Manifests are formalized in which we callout for ID and locators and how they will be used in the base protocol.

Note that the hash in the documents does not depend on there being a name.  Any message has a hash that can be calculated. For manifests, the hash (that you call ID) and the name (that you call locator) work in the exact same way as the protocol describes now.

Ravi > I don’t think so,  a CCNx forwarder will have to process Interests differently now that the names are not only application IDs but multiplexed with locator names too. So one has to always first look if there is a ContentHashId first, if not use the name in the Interest to index into the PIT. Instead using name always for application ID (ContentHashId is a implicit object ID by defintition, so why use it as a hash restriction ?) and introducing a locator for locator names can avoid this confusion.

My comment on having a new type for nameless content object was if, producer inadvertently produce a named content object without a name, and publish it, this is a error scenario which the forwarder can reject immediately. The main point here was that in the future there may  be more considerations towards a nameless objects (considering for example, computation efficiency  or other security concerns) where this clear distinction will help.

How/why would a producer _inadvertently_ produce a named content object without a name?  In the future there may also be considerations on name length or number of segments, and we may want to limit the name (architecturally) . When that day comes, we can consider those issues.

Right now, I don’t see a competing case for this.  It’s pretty easy to determine if the message has a name or not.

Do note that you will _still_ have to calculate hashes (if that’s what you’re doing) whether there is a name or not. There can always be a hash restriction on the interest independently of whether the content object has a name or no name.


Ravi > The case is a corner case, just as discussions have pointed out that same names can be reused making contentobjects muteable. Architecturally IMO, the distribution of nameless content objects have implications on the control and the forwarding plane. For e.g. named objects can be distributed over a routing plane, but a  nameless objects have to use something like a manifest, which has bearing on how a producer or the distributing mechanism has to handle these two kinds of content objects.

Nacho





From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]
Sent: Wednesday, April 06, 2016 2:06 PM
To: Ravi Ravindran; [e-mail]<mailto:[e-mail]>
Subject: Re: [icnrg] CCNx drafts

On 4/6/16, 1:04 PM, "icnrg on behalf of Ravi Ravindran" <[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>> wrote:

Hi Nacho,

Can you clarify if Nameless Objects are within the scope of these draft ?. I tried looking for its reference and couldn’t find it in the drafts. These are some of my concerns if nameless objects are in scope:

Yes, Nameless Objects are within the scope of the drafts.



1.      With Nameless Objects the Interest names are locators and Contentobject hash digest which serve as an identifier is part of the hash restriction. Though at this point the protocol doesn’t  separate the ID/locator name space explicitly in the protocol, it will be good to clarify that names can also be locators when nameless objects are requested. Towards this, I would suggest to define locator names as another namespace  in the semantics document and differentiate it from the names assigned by applications i.e. the producers. This would also be in line with the Manifest proposal which distinguishes Hash IDs and Locators in its definition. This ID/Locator name space separation is what we have been arguing for through the forwarding-label draft.  To complement the nameless object proposal, we also updated the draft with the use case of using Content HashIDs with forwarding-labels in Section 9.2 of the draft https://tools.ietf.org/html/draft-ravi-ccn-forwarding-label-02

Names are network names.  Their use is for forwarding.  The documents should not describe where these names come from, just like they don’t describe how you fill in your FIBs.

In the semantics document the only place the mentions applications is in the application name components. These are reserved name segment types that the applications can use.  In the messages document applications are mentioned in how they have space reserved in a few of the fields.

The current spec does not prevent the use that you describe in your draft.  As a matter of fact, it enables it.


2.      Also I would suggest to introduce nameless objects as a new type of content object itself, instead of it being defined as a regular content object which doesn’t have a name TLV for two reasons: Firstly, producers may choose to publish named and nameless version at the same time, explicitly distinguishing them would help forwarders to apply appropriate processing; Second, this differentiates from the case of a malformed named object for which the router may end up computing its hash unnecessarily.

This is an interesting consideration, but it doesn’t work very well for us, it adds complexity.  Right now, as things are defined, the hash is computed over the message. This allows us to have a way to calculated the message hash independently of the message.  We can calculate the hash of nameless objects as well as regular objects.  This means we can do manifests and nameless objects, as well as secure retrieval of named objects (like the manifests themselves).

For the first case, named and nameless versions of the same object are allowed. The spec does not prohibit that. We don’t need 2 different content types for this.  The same processing would apply to both.

For the second case, I don’t understand what you mean. How are you improving the way that we detect that something is malformed by having a second content type?

Nacho





From: icnrg [mailto:[e-mail]] On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Wednesday, April 06, 2016 2:00 PM
To: [e-mail]<mailto:[e-mail]>
Subject: [icnrg] CCNx drafts

Hi folks.

We are interested in moving the CCNx documents forward. The base docs, moving them towards publication. The ccnx:// one adopting it and moving it towards publication.

https://tools.ietf.org/html/draft-irtf-icnrg-ccnxmessages-02
https://tools.ietf.org/html/draft-irtf-icnrg-ccnxsemantics-02
https://tools.ietf.org/html/draft-mosko-icnrg-ccnxurischeme-00

The drafts have been pretty stable for a while. We made some minor updates to the documents with the Paris feedback and we will be discussing these tomorrow. We know this can be a lengthy process and we wanted to start the discussion on the list.

Please start voicing feedback and concerns.  The base documents are group documents and we would like the group to be ok with what they say.

Cheers,

Nacho

--
Nacho (Ignacio) Solis
Protocol Architect
Principal Scientist
Palo Alto Research Center (PARC)
[phone]
[e-mail]<mailto:[e-mail]>