[Ndn-interest] NDN protocol principles: name discovery

Tue Apr 5 19:15:36 PDT 2016

(apology for delay in reply; time during weekdays always a challenge)
My msg text was quoted below, but as I read the question it's not about my reply (I changed the subject line too to reflect real question).  
Anyway let me throw in my 2 cents.

this principle only says that the network should be able to take incomplete name and return a relevant data; from returned data the consumer learns more specifics about the existing data and may be able to construct complete name for future interests (following some clearly defined naming conventions). 

(one cannot say that the sequence of actions listed below completely wrong, though clearly it didn't use any naming conventions, therefore lines  3 and 5 issued interest with the same prefix--as if one knew nothing about the naming structure, without making use of any info one might have been derived from receiving the data packet from line 2)

I dont think that the principle by itself defines the exact mechanisms.
e.g. I feel naming conventions could play an important role here.  I believe we are still in early stage understanding the best way to define naming conventions. 

There is also a separate/separable question of what's the best way (least round trip) to get latest version; save that one for different discussion.

I dont know what kind of naming convention is assumed in this particular app, I am not sure I can follow the reasoning of the sequence of exchanges...

Lixia

> On Apr 3, 2016, at 5:47 PM, Marc.Mosko at parc.com wrote:
> 
> So that I am clear on this, to use the in-network discovery approach and find the latest version of data, one would need to:
> 
> 1) Issue an interest for /foo, right most child
> 2) Get back some /foo/ver=5/segment=0/hash=123
> 3) Issue an interest for /foo, excluding up to and including ver=5, right most child
> 4) Get back some /foo/ver=6/segment=0/hash=444
> 5) issue an interest for /foo excluding up to and including ver = 6
> 6) get back a NACK (or timeout)
> 7) issue an interest for /foo/ver=6/segment=0 excluding last seen hash (e.g. 444)
> 8) get back either a duplicate name with different hash (go to 7 and add another exclusion) or get back a NACK (or timeout)
> 
> one would then need to make some sort of decision (e.g. keyid or something intrinsic in the data) to determine which version 6 to use (or maybe all).
> 
> I’m not clear who issues the NACK in steps 6 and 8. I assume it would be an authoritative source (which might not exist in my connected component of the network, in which case they would be timeouts).
> 
> Is that correct or did I miss something?
> 
> Marc
> 
>> On Apr 3, 2016, at 9:00 PM, Lixia Zhang <lixia at CS.UCLA.EDU <mailto:lixia at cs.ucla.edu>> wrote:
>> 
>>> 
>>> On Apr 3, 2016, at 12:56 PM, Dave Oran (oran) <oran at cisco.com <mailto:oran at cisco.com>> wrote:
>>> 
>>>> 
>>>> On Apr 3, 2016, at 3:06 PM, Lixia Zhang <lixia at CS.UCLA.EDU <mailto:lixia at cs.ucla.edu>> wrote:
>>>> 
>>>>> 
>>>>> On Apr 3, 2016, at 6:21 AM, Ralph Droms (rdroms) <rdroms at cisco.com <mailto:rdroms at cisco.com>> wrote:
>>>>> 
>>>>> In the icnrg meeting, we didn't have time to discuss this sub-bullet of principle 2:
>>>>> 
>>>>> Although data packets are immutable, applications can make changes to the communicated content by creating new versions of immutable data packets.
>>>>> 
>>>>> I need help understanding how the phrase "new versions of immutable data packets" makes sense.  "new version" and "immutable" seem contradictory. Jeff promised get me some help, here, if I moved the discussion to the mailing list.
>>>>> 
>>>>> - Ralph
>>>> 
>>>> I can see how the wording could lead to confusion.
>>>> my understanding of what it is meant to say is this:
>>>> • /foo/bar/ICNslides/v1 is immutable data
>>>> •  (for simplicity lets assume it's just one data packet here)
>>>> • When I make changes to the slides, I produce /foo/bar/ICNslides/v2
>>>> Lixia
>>>> 
>>> What if I have a stateless producer that does not remember enough to maintain a monotonic (or worse, a sequential) counter, or if I have a distributed producer and it’s inconvenient/infeasible to run an agreement protocol to maintain the version number? Is it in fact considered an “epic fail” for a producer to create two different bags of bits (and hence different hashes) that have identical names?
>> 
>> I just used a simple example to mean 
>> - data is immutable
>> - updated name should have a different name.
>> 
>> yes name collision may occur in distributed production scenario. The ultimate way to distinguish different data packets is by their full name (i.e. name with implicit digest).
>> 
>>> In the same vein, is the following legal:
>>> 
>>> At time T0, I create object with name a/b/c and bits “dsfasdfasdfadsfadfa”, and expiration time T0+deltaT.
>>> Then, At time T1=T0+deltaT+epsilon, I create object a/b/c with bits “fgsdfgsfgsdfgsfgfg” and expiration time T1+deltaT.
>>> 
>>> If not, why not?
>> 
>> Personal view:
>> - as far as application development is concerned: one should use different names for different data to the extend possible.
>> - the last resort to distinguish different data is by name with digest.
>> 
>> Lixia
>> 
>>>>>> On Mar 15, 2016, at 1:01 AM 3/15/16, Marc.Mosko at parc.com <mailto:Marc.Mosko at parc.com> wrote:
>>>>>> 
>>>>>> 
>>>>>>> On Mar 14, 2016, at 8:44 PM, Tai-Lin Chu <tailinchu at gmail.com <mailto:tailinchu at gmail.com>> wrote:
>>>>>>> 
>>>>>>>> sure - I don't want to expose names that identify me, or expose my communication activities. given that, the "network" doesn't have the job of finding things for me by partial names - I only want to expose the details of my communication to a service that I have authenticated, and only when those details are encrypted. the "names" visible to the network in that sort of world just get the packets moving - and the only LPM needed is LPM in the FIB to get me to one or more instances of a service.
>>>>>>> 
>>>>>>> Immutability is related to in-network discovery with LPM.  If all packets are immutable, and there is no in-network discovery, ndn must rely on some other protocol that cannot not build on top of ndn for discovery (we should all agree that randomly guessing a version number or a certain name is not going to work well as “discovery”). This devalues ndn as an “universal" protocol.
>>>>>> 
>>>>>> Could you please define immutable?  Do you mean that a single publisher will never use the same name for different contents?  Is that mandatory or enforceable?  Or do you mean that there is some cryptographic function possible on a packet such that one can detect if it changes? Are those cryptographic primitives mandatory in each packet?
>>>>>> 
>>>>>> I disagree that it is a necessary condition that one have name suffix completion matching of a data object to an interest to facilitate discovery.  One can build a discovery protocol over exact name matching. I usually build these where the cache returns a chunked table of contents listing possible matches instead of the CCNx 0.x / NDN approach of having to return a (potentially very large) data object and walk a tree which is really only efficient if you expect what you want to be left-most or right-most child and not require iteration.
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> On Mar 14, 2016, at 12:10 PM, Mark Stapp <mjs at cisco.com <mailto:mjs at cisco.com>> wrote:
>>>>>>>> 
>>>>>>>> interesting -
>>>>>>>> 
>>>>>>>> On 3/14/16 11:27 AM, Burke, Jeff wrote:
>>>>>>>>> 
>>>>>>>> [...]
>>>>>>>> RFC 6973 takes a nice approach, for example, by offering
>>>>>>>>>> definitions of some technical properties and mechanisms, but not trying
>>>>>>>>>> to formulate an overall definition of "privacy".
>>>>>>>>> 
>>>>>>>>> So I can try to understand your point here - do you agree with the
>>>>>>>> authors that the primary privacy concerns are those of individuals? (Or,
>>>>>>>> more generally, are corporations people here for this discussion - a
>>>>>>>> more generic "data owner"?)
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> hmm - well, I don't think corporations are people, in the citizens united sense, but I think there's lots of commercial communication that needs to have the best possible protection, whether it's B2C or B2B?
>>>>>>>> 
>>>>>>>>>> The editors there say
>>>>>>>>>> that the body of the document, the discussion of the tradeoffs and
>>>>>>>>>> alternatives, is the best way they could come up with to approach that
>>>>>>>>>> abstraction. in practical terms, as you know well I think there's been
>>>>>>>>>> an over-reliance on opportunistic caching in ICN generally, and as a
>>>>>>>>>> result observability and correlation are defined to be positive
>>>>>>>>>> properties of ICN communication rather than harmful ones.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Would I be correct to parse your concerns into two pieces that may
>>>>>>>> have different implications:
>>>>>>>>> 
>>>>>>>>> - Confidentiality of request (e.g., the consumer side)
>>>>>>>>> - Confidentiality of publication (e.g., the publisher side)
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> I think I have a mental image of "confidential request" - where an observer cannot see much beyond the routeable prefix needed to reach an instance of the service I want to communicate with. I'm not sure what "confidential publication" means, though? I think I want the replies to my requests to be encrypted with ephemeral, forward-secure key material, I don't want the names in the replies to expose any more than the names in the requests, and I want to be able to authenticate the service before I expose anything about my own identity or intentions. is that what you meant by "the publisher side"?
>>>>>>>> 
>>>>>>>> [...]
>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> most of these six "principles" sounded like "mechanisms" to me - the
>>>>>>>>>> list felt like the end of a discussion about alternatives and the best
>>>>>>>>>> ways to implement an architecture, rather than the start of one. it
>>>>>>>>>> sounded like "we're tired of questions about LPM in the PIT, so we're
>>>>>>>>>> going to stop calling that a possible mechanism and start calling it an
>>>>>>>>>> inevitable, immutable, unquestionable 'principle'".
>>>>>>>>> 
>>>>>>>>> Well, to take LPM for an example - it's actually not mentioned in
>>>>>>>>> the
>>>>>>>> principle doc that Alex sent. The principle I suspect that you are
>>>>>>>> referring to is:
>>>>>>>>> 
>>>>>>>>> [5] In-Network Name Discovery: Interests should be able use
>>>>>>>>> incomplete
>>>>>>>> names to retrieve data packets.
>>>>>>>>> A consumer may not know the complete network-level name for data, as
>>>>>>>> some parts of the name cannot be guessed, computed, or inferred
>>>>>>>> beforehand. Once initial data is received, naming conventions can help
>>>>>>>> determine complete names of other related data:
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> * majority of interests will carry complete names
>>>>>>>>> 
>>>>>>>>> * in-network name discovery expected to be used to bootstrap
>>>>>>>> communication)
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> Can you explain your objection in these terms?
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> sure - I don't want to expose names that identify me, or expose my communication activities. given that, the "network" doesn't have the job of finding things for me by partial names - I only want to expose the details of my communication to a service that I have authenticated, and only when those details are encrypted. the "names" visible to the network in that sort of world just get the packets moving - and the only LPM needed is LPM in the FIB to get me to one or more instances of a service.
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Mark
>>>>>>>> _______________________________________________
>>>>>>>> Ndn-interest mailing list
>>>>>>>> Ndn-interest at lists.cs.ucla.edu <mailto:Ndn-interest at lists.cs.ucla.edu>
>>>>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> Ndn-interest mailing list
>>>>>>> Ndn-interest at lists.cs.ucla.edu <mailto:Ndn-interest at lists.cs.ucla.edu>
>>>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> Ndn-interest mailing list
>>>>>> Ndn-interest at lists.cs.ucla.edu <mailto:Ndn-interest at lists.cs.ucla.edu>
>>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>>>> 
>>>>> _______________________________________________
>>>>> Ndn-interest mailing list
>>>>> Ndn-interest at lists.cs.ucla.edu <mailto:Ndn-interest at lists.cs.ucla.edu>
>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>>> 
>>>> _______________________________________________
>>>> Ndn-interest mailing list
>>>> Ndn-interest at lists.cs.ucla.edu <mailto:Ndn-interest at lists.cs.ucla.edu>
>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>> 
>> 
>> _______________________________________________
>> Ndn-interest mailing list
>> Ndn-interest at lists.cs.ucla.edu <mailto:Ndn-interest at lists.cs.ucla.edu>
>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest <http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160405/38ed172b/attachment.html>