From rdroms at cisco.com  Sun Apr  3 06:21:40 2016
From: rdroms at cisco.com (Ralph Droms (rdroms))
Date: Sun, 3 Apr 2016 13:21:40 +0000
Subject: [Ndn-interest] NDN protocol principles: no privacy?
In-Reply-To: <C040108A-16E8-4D2C-B135-AEA5D8735C46@parc.com>
References: <56E42E81.3060407@cisco.com> <56E49873.9090806@ics.uci.edu>
	<56E58A40.9090704@cisco.com>
	<F9C67E19-D956-415D-822D-07FFE654D4EE@remap.ucla.edu>
	<56E70CA2.1080905@cisco.com>
	<1870C141-6751-4065-9377-8FE8E104C477@gmail.com>
	<C040108A-16E8-4D2C-B135-AEA5D8735C46@parc.com>
Message-ID: <8149253A-E347-432A-9E92-E737F663AA1E@cisco.com>

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

> On Mar 15, 2016, at 1:01 AM 3/15/16, Marc.Mosko at parc.com wrote:
> 
> 
>> On Mar 14, 2016, at 8:44 PM, Tai-Lin Chu <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> 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
>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>> 
>> 
>> _______________________________________________
>> Ndn-interest mailing list
>> 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
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160403/04d718cb/attachment.bin>

From lixia at CS.UCLA.EDU  Sun Apr  3 11:06:57 2016
From: lixia at CS.UCLA.EDU (Lixia Zhang)
Date: Sun, 3 Apr 2016 11:06:57 -0700
Subject: [Ndn-interest] NDN protocol principles: no privacy?
In-Reply-To: <8149253A-E347-432A-9E92-E737F663AA1E@cisco.com>
References: <56E42E81.3060407@cisco.com> <56E49873.9090806@ics.uci.edu>
	<56E58A40.9090704@cisco.com>
	<F9C67E19-D956-415D-822D-07FFE654D4EE@remap.ucla.edu>
	<56E70CA2.1080905@cisco.com>
	<1870C141-6751-4065-9377-8FE8E104C477@gmail.com>
	<C040108A-16E8-4D2C-B135-AEA5D8735C46@parc.com>
	<8149253A-E347-432A-9E92-E737F663AA1E@cisco.com>
Message-ID: <40BD7781-7CEE-4710-A819-C528C39AE5E1@cs.ucla.edu>


> On Apr 3, 2016, at 6:21 AM, Ralph Droms (rdroms) <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

>> On Mar 15, 2016, at 1:01 AM 3/15/16, Marc.Mosko at parc.com wrote:
>> 
>> 
>>> On Mar 14, 2016, at 8:44 PM, Tai-Lin Chu <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> 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
>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>> 
>>> 
>>> _______________________________________________
>>> Ndn-interest mailing list
>>> 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
>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
> 
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> 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/20160403/32cfe177/attachment.html>

From oran at cisco.com  Sun Apr  3 12:56:17 2016
From: oran at cisco.com (Dave Oran (oran))
Date: Sun, 3 Apr 2016 19:56:17 +0000
Subject: [Ndn-interest] NDN protocol principles: no privacy?
In-Reply-To: <40BD7781-7CEE-4710-A819-C528C39AE5E1@cs.ucla.edu>
References: <56E42E81.3060407@cisco.com> <56E49873.9090806@ics.uci.edu>
	<56E58A40.9090704@cisco.com>
	<F9C67E19-D956-415D-822D-07FFE654D4EE@remap.ucla.edu>
	<56E70CA2.1080905@cisco.com>
	<1870C141-6751-4065-9377-8FE8E104C477@gmail.com>
	<C040108A-16E8-4D2C-B135-AEA5D8735C46@parc.com>
	<8149253A-E347-432A-9E92-E737F663AA1E@cisco.com>
	<40BD7781-7CEE-4710-A819-C528C39AE5E1@cs.ucla.edu>
Message-ID: <03C09735-E6E6-41D5-8445-7AEBECFF435F@cisco.com>


> On Apr 3, 2016, at 3:06 PM, Lixia Zhang <lixia at CS.UCLA.EDU> wrote:
> 
>> 
>> On Apr 3, 2016, at 6:21 AM, Ralph Droms (rdroms) <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?

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?

DaveO.

>>> On Mar 15, 2016, at 1:01 AM 3/15/16, Marc.Mosko at parc.com wrote:
>>> 
>>> 
>>>> On Mar 14, 2016, at 8:44 PM, Tai-Lin Chu <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> 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
>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Ndn-interest mailing list
>>>> 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
>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>> 
>> _______________________________________________
>> Ndn-interest mailing list
>> 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
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest




From lixia at CS.UCLA.EDU  Sun Apr  3 17:00:57 2016
From: lixia at CS.UCLA.EDU (Lixia Zhang)
Date: Sun, 3 Apr 2016 17:00:57 -0700
Subject: [Ndn-interest] NDN protocol principles: no privacy?
In-Reply-To: <03C09735-E6E6-41D5-8445-7AEBECFF435F@cisco.com>
References: <56E42E81.3060407@cisco.com> <56E49873.9090806@ics.uci.edu>
	<56E58A40.9090704@cisco.com>
	<F9C67E19-D956-415D-822D-07FFE654D4EE@remap.ucla.edu>
	<56E70CA2.1080905@cisco.com>
	<1870C141-6751-4065-9377-8FE8E104C477@gmail.com>
	<C040108A-16E8-4D2C-B135-AEA5D8735C46@parc.com>
	<8149253A-E347-432A-9E92-E737F663AA1E@cisco.com>
	<40BD7781-7CEE-4710-A819-C528C39AE5E1@cs.ucla.edu>
	<03C09735-E6E6-41D5-8445-7AEBECFF435F@cisco.com>
Message-ID: <71B7601B-0A0B-435D-81FF-F6B6367CCC13@cs.ucla.edu>


> On Apr 3, 2016, at 12:56 PM, Dave Oran (oran) <oran at cisco.com> wrote:
> 
>> 
>> On Apr 3, 2016, at 3:06 PM, Lixia Zhang <lixia at CS.UCLA.EDU> wrote:
>> 
>>> 
>>> On Apr 3, 2016, at 6:21 AM, Ralph Droms (rdroms) <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 wrote:
>>>> 
>>>> 
>>>>> On Mar 14, 2016, at 8:44 PM, Tai-Lin Chu <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> 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
>>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Ndn-interest mailing list
>>>>> 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
>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>> 
>>> _______________________________________________
>>> Ndn-interest mailing list
>>> 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
>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest




From lixia at CS.UCLA.EDU  Sun Apr  3 17:02:23 2016
From: lixia at CS.UCLA.EDU (Lixia Zhang)
Date: Sun, 3 Apr 2016 17:02:23 -0700
Subject: [Ndn-interest] NDN protocol principles: no privacy?
In-Reply-To: <71B7601B-0A0B-435D-81FF-F6B6367CCC13@cs.ucla.edu>
References: <56E42E81.3060407@cisco.com> <56E49873.9090806@ics.uci.edu>
	<56E58A40.9090704@cisco.com>
	<F9C67E19-D956-415D-822D-07FFE654D4EE@remap.ucla.edu>
	<56E70CA2.1080905@cisco.com>
	<1870C141-6751-4065-9377-8FE8E104C477@gmail.com>
	<C040108A-16E8-4D2C-B135-AEA5D8735C46@parc.com>
	<8149253A-E347-432A-9E92-E737F663AA1E@cisco.com>
	<40BD7781-7CEE-4710-A819-C528C39AE5E1@cs.ucla.edu>
	<03C09735-E6E6-41D5-8445-7AEBECFF435F@cisco.com>
	<71B7601B-0A0B-435D-81FF-F6B6367CCC13@cs.ucla.edu>
Message-ID: <F9A922AA-3247-4591-96FC-3948346C0685@cs.ucla.edu>


> On Apr 3, 2016, at 5:00 PM, Lixia Zhang <lixia at CS.UCLA.EDU> wrote:
> 
>> 
>> On Apr 3, 2016, at 12:56 PM, Dave Oran (oran) <oran at cisco.com> wrote:
>> 
>>> 
>>> On Apr 3, 2016, at 3:06 PM, Lixia Zhang <lixia at CS.UCLA.EDU> wrote:
>>> 
>>>> 
>>>> On Apr 3, 2016, at 6:21 AM, Ralph Droms (rdroms) <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.

I meant to say update data 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 wrote:
>>>>> 
>>>>> 
>>>>>> On Mar 14, 2016, at 8:44 PM, Tai-Lin Chu <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> 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
>>>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> Ndn-interest mailing list
>>>>>> 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
>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>>>> 
>>>> _______________________________________________
>>>> Ndn-interest mailing list
>>>> 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
>>> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
> 
> 
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest




From Marc.Mosko at parc.com  Sun Apr  3 17:47:55 2016
From: Marc.Mosko at parc.com (Marc.Mosko at parc.com)
Date: Mon, 4 Apr 2016 00:47:55 +0000
Subject: [Ndn-interest] NDN protocol principles: no privacy?
In-Reply-To: <71B7601B-0A0B-435D-81FF-F6B6367CCC13@cs.ucla.edu>
References: <56E42E81.3060407@cisco.com> <56E49873.9090806@ics.uci.edu>
	<56E58A40.9090704@cisco.com>
	<F9C67E19-D956-415D-822D-07FFE654D4EE@remap.ucla.edu>
	<56E70CA2.1080905@cisco.com>
	<1870C141-6751-4065-9377-8FE8E104C477@gmail.com>
	<C040108A-16E8-4D2C-B135-AEA5D8735C46@parc.com>
	<8149253A-E347-432A-9E92-E737F663AA1E@cisco.com>
	<40BD7781-7CEE-4710-A819-C528C39AE5E1@cs.ucla.edu>
	<03C09735-E6E6-41D5-8445-7AEBECFF435F@cisco.com>
	<71B7601B-0A0B-435D-81FF-F6B6367CCC13@cs.ucla.edu>
Message-ID: <AC704AC0-5A68-43F5-AB0F-00AB4FB84098@parc.com>

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

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

From Navdeep.Uniyal at neclab.eu  Mon Apr  4 01:57:53 2016
From: Navdeep.Uniyal at neclab.eu (Navdeep Uniyal)
Date: Mon, 4 Apr 2016 08:57:53 +0000
Subject: [Ndn-interest] Data not received from NDN traffic generator
In-Reply-To: <CAOFH+OZQWGC=DRc0q4GiDjKMesQcX3V6fjRPh9f1W7-JgsiswQ@mail.gmail.com>
References: <15421E67B274CD4AB5F6AEA46A684C3708AB280C@PALLENE.office.hd>
	<CAOFH+OZQWGC=DRc0q4GiDjKMesQcX3V6fjRPh9f1W7-JgsiswQ@mail.gmail.com>
Message-ID: <15421E67B274CD4AB5F6AEA46A684C3708AB2B1A@PALLENE.office.hd>

Hi Junxiao,

I used digest signing to generate data packets using NDN traffic generator.Also, I have increased the InterestLifetime. Still I find all interests are not being satisfied.
I am using CS store size to be zero so that all interests can reach the end server. And onInterestLoop is happening as I am testing the forwarding with 4 types of interests using ndn traffic client and sometime same interest is generated back to back.

The issue remains the same as interests are not getting satisfied after certain time. Also, I found a few errors in the log file. I suspect the issue is due to the below errors but I have no clue about the error type:

1459757352.193370 ERROR: [EthernetTransport] [id=264,local=dev://sa-eth0,remote=ether://[01:00:5e:00:17:aa]] pcap_next_ex failed: The interface went down
1459757352.213168 ERROR: [EthernetTransport] [id=263,local=dev://sa-eth1,remote=ether://[01:00:5e:00:17:aa]] pcap_next_ex failed: The interface went down
1459757352.229184 ERROR: [EthernetTransport] [id=262,local=dev://sa-eth2,remote=ether://[01:00:5e:00:17:aa]] pcap_next_ex failed: The interface went down


Attached is the recent log file. Please advise.

Regards,
Navdeep Uniyal

From: Junxiao Shi [mailto:shijunxiao at email.arizona.edu]
Sent: Mittwoch, 30. M?rz 2016 19:31
To: Navdeep Uniyal
Cc: ndn-interest at lists.cs.ucla.edu
Subject: Re: [Ndn-interest] Data not received from NDN traffic generator

Hi Navdeep

I'm looking at the last few lines of the log file.
It appears that there's some loop going on in the network. It's particularly strange that face 262 receives an Interest with duplicate Nonce within 0.2ms of sending it.
InterestLifetime is set to 200ms, but the producer spends 500ms to generate Data. A longer InterestLifetime is needed; the consumer needs to send Interests at a slower rate; the producer needs to generate Data faster (eg. set digest signing instead of RSA).
Also, you mentioned there are 2500 Interests, but I only see a small number of distinct names.

1459335670.181340 DEBUG: [Forwarder] onIncomingInterest face=258 interest=/ndn/nle/file3
1459335670.181630 DEBUG: [Forwarder] onContentStoreMiss interest=/ndn/nle/file3
1459335670.181672 DEBUG: [Forwarder] onOutgoingInterest face=262 interest=/ndn/nle/file3
1459335670.181898 DEBUG: [Forwarder] onIncomingInterest face=262 interest=/ndn/nle/file3
1459335670.182178 DEBUG: [Forwarder] onInterestLoop face=262 interest=/ndn/nle/file3
1459335670.201832 DEBUG: [Forwarder] onInterestUnsatisfied interest=/ndn/nle/file5
1459335670.201911 DEBUG: [Forwarder] onInterestFinalize interest=/ndn/nle/file5 unsatisfied
1459335670.231633 DEBUG: [Forwarder] onIncomingInterest face=259 interest=/ndn/nle/file5
1459335670.231972 DEBUG: [Forwarder] onContentStoreMiss interest=/ndn/nle/file5
1459335670.232011 DEBUG: [Forwarder] onOutgoingInterest face=263 interest=/ndn/nle/file5
1459335670.271813 DEBUG: [Forwarder] onInterestUnsatisfied interest=/ndn/nle/file1
1459335670.271889 DEBUG: [Forwarder] onInterestFinalize interest=/ndn/nle/file1 unsatisfied
1459335670.281172 DEBUG: [Forwarder] onIncomingInterest face=259 interest=/ndn/nle/file1
1459335670.281512 DEBUG: [Forwarder] onContentStoreMiss interest=/ndn/nle/file1
1459335670.281551 DEBUG: [Forwarder] onOutgoingInterest face=263 interest=/ndn/nle/file1
1459335670.381690 DEBUG: [Forwarder] onIncomingInterest face=259 interest=/ndn/nle/file7
1459335670.382148 DEBUG: [Forwarder] onContentStoreMiss interest=/ndn/nle/file7
1459335670.382193 DEBUG: [Forwarder] onOutgoingData face=259 data=/ndn/nle/file7
1459335670.382362 DEBUG: [Forwarder] onInterestUnsatisfied interest=/ndn/nle/file3
1459335670.382447 DEBUG: [Forwarder] onInterestFinalize interest=/ndn/nle/file3 unsatisfied
1459335670.432216 DEBUG: [Forwarder] onInterestUnsatisfied interest=/ndn/nle/file5
1459335670.432315 DEBUG: [Forwarder] onInterestFinalize interest=/ndn/nle/file5 unsatisfied
1459335670.481765 DEBUG: [Forwarder] onInterestUnsatisfied interest=/ndn/nle/file1
1459335670.481840 DEBUG: [Forwarder] onInterestFinalize interest=/ndn/nle/file1 unsatisfied
1459335670.482383 DEBUG: [Forwarder] onInterestFinalize interest=/ndn/nle/file7 satisfied
1459335685.781128 DEBUG: [Forwarder] onIncomingData face=263 data=/ndn/nle/file3
1459335685.781423 DEBUG: [Forwarder] onDataUnsolicited face=263 data=/ndn/nle/file3 cached
1459335685.782137 DEBUG: [Forwarder] onIncomingData face=263 data=/ndn/nle/file1
1459335685.782378 DEBUG: [Forwarder] onDataUnsolicited face=263 data=/ndn/nle/file1 cached


Yours, Junxiao

On Wed, Mar 30, 2016 at 5:42 AM, Navdeep Uniyal <Navdeep.Uniyal at neclab.eu<mailto:Navdeep.Uniyal at neclab.eu>> wrote:
Hi All,

I am facing an issue. In my setup I am using a simple topology with one client, one server and with 3 different paths having one intermediate host on each path. All the generated interests are not getting satisfied while using best-route strategy. As per logs I can see, after satisfying a few interests, the server(NDN traffic generator) is not responding to the further requests and only the ones at CS store are getting satisfied. I am unable to find the reason for such a behavior. Although the number of interests generated are 2500 and there is no limit on max number of interests the traffic generator can satisfy ( although I also tried with max limit of 20000 interests). Attached are the NFD logs for the server generating data. Please, if someone can help in this regard.



Regards,
Navdeep Uniyal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160404/601af90e/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: server Log.txt
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160404/601af90e/attachment.txt>

From Navdeep.Uniyal at neclab.eu  Tue Apr  5 00:35:29 2016
From: Navdeep.Uniyal at neclab.eu (Navdeep Uniyal)
Date: Tue, 5 Apr 2016 07:35:29 +0000
Subject: [Ndn-interest] Data not received from NDN traffic generator
In-Reply-To: <15421E67B274CD4AB5F6AEA46A684C3708AB2B1A@PALLENE.office.hd>
References: <15421E67B274CD4AB5F6AEA46A684C3708AB280C@PALLENE.office.hd>
	<CAOFH+OZQWGC=DRc0q4GiDjKMesQcX3V6fjRPh9f1W7-JgsiswQ@mail.gmail.com>
	<15421E67B274CD4AB5F6AEA46A684C3708AB2B1A@PALLENE.office.hd>
Message-ID: <15421E67B274CD4AB5F6AEA46A684C3708AB2BCB@PALLENE.office.hd>

Hi

Please if someone can help resolving the below mentioned issue.

Regards,
Navdeep Uniyal

From: Ndn-interest [mailto:ndn-interest-bounces at lists.cs.ucla.edu] On Behalf Of Navdeep Uniyal
Sent: Montag, 4. April 2016 10:58
To: Junxiao Shi
Cc: nfd-dev at lists.cs.ucla.edu; ndn-interest at lists.cs.ucla.edu
Subject: Re: [Ndn-interest] Data not received from NDN traffic generator

Hi Junxiao,

I used digest signing to generate data packets using NDN traffic generator.Also, I have increased the InterestLifetime. Still I find all interests are not being satisfied.
I am using CS store size to be zero so that all interests can reach the end server. And onInterestLoop is happening as I am testing the forwarding with 4 types of interests using ndn traffic client and sometime same interest is generated back to back.

The issue remains the same as interests are not getting satisfied after certain time. Also, I found a few errors in the log file. I suspect the issue is due to the below errors but I have no clue about the error type:

1459757352.193370 ERROR: [EthernetTransport] [id=264,local=dev://sa-eth0,remote=ether://[01:00:5e:00:17:aa]] pcap_next_ex failed: The interface went down
1459757352.213168 ERROR: [EthernetTransport] [id=263,local=dev://sa-eth1,remote=ether://[01:00:5e:00:17:aa]] pcap_next_ex failed: The interface went down
1459757352.229184 ERROR: [EthernetTransport] [id=262,local=dev://sa-eth2,remote=ether://[01:00:5e:00:17:aa]] pcap_next_ex failed: The interface went down


Attached is the recent log file. Please advise.

Regards,
Navdeep Uniyal

From: Junxiao Shi [mailto:shijunxiao at email.arizona.edu]
Sent: Mittwoch, 30. M?rz 2016 19:31
To: Navdeep Uniyal
Cc: ndn-interest at lists.cs.ucla.edu<mailto:ndn-interest at lists.cs.ucla.edu>
Subject: Re: [Ndn-interest] Data not received from NDN traffic generator

Hi Navdeep

I'm looking at the last few lines of the log file.
It appears that there's some loop going on in the network. It's particularly strange that face 262 receives an Interest with duplicate Nonce within 0.2ms of sending it.
InterestLifetime is set to 200ms, but the producer spends 500ms to generate Data. A longer InterestLifetime is needed; the consumer needs to send Interests at a slower rate; the producer needs to generate Data faster (eg. set digest signing instead of RSA).
Also, you mentioned there are 2500 Interests, but I only see a small number of distinct names.

1459335670.181340 DEBUG: [Forwarder] onIncomingInterest face=258 interest=/ndn/nle/file3
1459335670.181630 DEBUG: [Forwarder] onContentStoreMiss interest=/ndn/nle/file3
1459335670.181672 DEBUG: [Forwarder] onOutgoingInterest face=262 interest=/ndn/nle/file3
1459335670.181898 DEBUG: [Forwarder] onIncomingInterest face=262 interest=/ndn/nle/file3
1459335670.182178 DEBUG: [Forwarder] onInterestLoop face=262 interest=/ndn/nle/file3
1459335670.201832 DEBUG: [Forwarder] onInterestUnsatisfied interest=/ndn/nle/file5
1459335670.201911 DEBUG: [Forwarder] onInterestFinalize interest=/ndn/nle/file5 unsatisfied
1459335670.231633 DEBUG: [Forwarder] onIncomingInterest face=259 interest=/ndn/nle/file5
1459335670.231972 DEBUG: [Forwarder] onContentStoreMiss interest=/ndn/nle/file5
1459335670.232011 DEBUG: [Forwarder] onOutgoingInterest face=263 interest=/ndn/nle/file5
1459335670.271813 DEBUG: [Forwarder] onInterestUnsatisfied interest=/ndn/nle/file1
1459335670.271889 DEBUG: [Forwarder] onInterestFinalize interest=/ndn/nle/file1 unsatisfied
1459335670.281172 DEBUG: [Forwarder] onIncomingInterest face=259 interest=/ndn/nle/file1
1459335670.281512 DEBUG: [Forwarder] onContentStoreMiss interest=/ndn/nle/file1
1459335670.281551 DEBUG: [Forwarder] onOutgoingInterest face=263 interest=/ndn/nle/file1
1459335670.381690 DEBUG: [Forwarder] onIncomingInterest face=259 interest=/ndn/nle/file7
1459335670.382148 DEBUG: [Forwarder] onContentStoreMiss interest=/ndn/nle/file7
1459335670.382193 DEBUG: [Forwarder] onOutgoingData face=259 data=/ndn/nle/file7
1459335670.382362 DEBUG: [Forwarder] onInterestUnsatisfied interest=/ndn/nle/file3
1459335670.382447 DEBUG: [Forwarder] onInterestFinalize interest=/ndn/nle/file3 unsatisfied
1459335670.432216 DEBUG: [Forwarder] onInterestUnsatisfied interest=/ndn/nle/file5
1459335670.432315 DEBUG: [Forwarder] onInterestFinalize interest=/ndn/nle/file5 unsatisfied
1459335670.481765 DEBUG: [Forwarder] onInterestUnsatisfied interest=/ndn/nle/file1
1459335670.481840 DEBUG: [Forwarder] onInterestFinalize interest=/ndn/nle/file1 unsatisfied
1459335670.482383 DEBUG: [Forwarder] onInterestFinalize interest=/ndn/nle/file7 satisfied
1459335685.781128 DEBUG: [Forwarder] onIncomingData face=263 data=/ndn/nle/file3
1459335685.781423 DEBUG: [Forwarder] onDataUnsolicited face=263 data=/ndn/nle/file3 cached
1459335685.782137 DEBUG: [Forwarder] onIncomingData face=263 data=/ndn/nle/file1
1459335685.782378 DEBUG: [Forwarder] onDataUnsolicited face=263 data=/ndn/nle/file1 cached


Yours, Junxiao

On Wed, Mar 30, 2016 at 5:42 AM, Navdeep Uniyal <Navdeep.Uniyal at neclab.eu<mailto:Navdeep.Uniyal at neclab.eu>> wrote:
Hi All,

I am facing an issue. In my setup I am using a simple topology with one client, one server and with 3 different paths having one intermediate host on each path. All the generated interests are not getting satisfied while using best-route strategy. As per logs I can see, after satisfying a few interests, the server(NDN traffic generator) is not responding to the further requests and only the ones at CS store are getting satisfied. I am unable to find the reason for such a behavior. Although the number of interests generated are 2500 and there is no limit on max number of interests the traffic generator can satisfy ( although I also tried with max limit of 20000 interests). Attached are the NFD logs for the server generating data. Please, if someone can help in this regard.



Regards,
Navdeep Uniyal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160405/7620f46c/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: server Log.txt
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160405/7620f46c/attachment.txt>

From 121049189 at qq.com  Tue Apr  5 06:43:35 2016
From: 121049189 at qq.com (=?gb18030?B?1dTWvs6w?=)
Date: Tue, 5 Apr 2016 21:43:35 +0800
Subject: [Ndn-interest] congestion control
Message-ID: <tencent_3929F4230C0D2AFF5CB57385@qq.com>

Dear all,
    Recently, I read the NFD, I  would like to know if there are something about congestion control.
Like TCP/IP, there are AIMD windows mechanism. I really don't see congestion control in
https://github.com/named-data/ndn-tools/tree/master/tools/chunks


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

From lixia at CS.UCLA.EDU  Tue Apr  5 19:15:36 2016
From: lixia at CS.UCLA.EDU (Lixia Zhang)
Date: Tue, 5 Apr 2016 19:15:36 -0700
Subject: [Ndn-interest] NDN protocol principles: name discovery
In-Reply-To: <AC704AC0-5A68-43F5-AB0F-00AB4FB84098@parc.com>
References: <56E42E81.3060407@cisco.com> <56E49873.9090806@ics.uci.edu>
	<56E58A40.9090704@cisco.com>
	<F9C67E19-D956-415D-822D-07FFE654D4EE@remap.ucla.edu>
	<56E70CA2.1080905@cisco.com>
	<1870C141-6751-4065-9377-8FE8E104C477@gmail.com>
	<C040108A-16E8-4D2C-B135-AEA5D8735C46@parc.com>
	<8149253A-E347-432A-9E92-E737F663AA1E@cisco.com>
	<40BD7781-7CEE-4710-A819-C528C39AE5E1@cs.ucla.edu>
	<03C09735-E6E6-41D5-8445-7AEBECFF435F@cisco.com>
	<71B7601B-0A0B-435D-81FF-F6B6367CCC13@cs.ucla.edu>
	<AC704AC0-5A68-43F5-AB0F-00AB4FB84098@parc.com>
Message-ID: <3279F45E-CF92-4994-9EAC-19856F5D33B9@cs.ucla.edu>

(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>

From lixia at CS.UCLA.EDU  Tue Apr  5 19:20:16 2016
From: lixia at CS.UCLA.EDU (Lixia Zhang)
Date: Tue, 5 Apr 2016 19:20:16 -0700
Subject: [Ndn-interest] congestion control
In-Reply-To: <tencent_3929F4230C0D2AFF5CB57385@qq.com>
References: <tencent_3929F4230C0D2AFF5CB57385@qq.com>
Message-ID: <6A72A256-6DA0-476A-8769-3CDAB48D8F25@cs.ucla.edu>


> On Apr 5, 2016, at 6:43 AM, ??? <121049189 at qq.com> wrote:
> 
> Dear all,
>     Recently, I read the NFD, I  would like to know if there are something about congestion control.
> Like TCP/IP, there are AIMD windows mechanism. I really don't see congestion control in
> https://github.com/named-data/ndn-tools/tree/master/tools/chunks <https://github.com/named-data/ndn-tools/tree/master/tools/chunks>
1/ the current code in github does not have congestion control yet
(last year Ilya Moiseenko did some NDN API work which incorporated a simple congestion control, but that code is not included in the NFD release--I'm pretty sure he's on this list if you want to ask him)

2/ some students in the NDN project team are actively working on the topic, so we do hope to be able to add some simple congestion function into NFD in near future.

3/ FYI there have been quite some number of published papers on NDN congestion control, if you are interested in this topic.

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

From 121049189 at qq.com  Wed Apr  6 01:38:02 2016
From: 121049189 at qq.com (=?gb18030?B?1dTWvs6w?=)
Date: Wed, 6 Apr 2016 16:38:02 +0800
Subject: [Ndn-interest] Ilya Moiseenko's congestion control
Message-ID: <tencent_5C92FAF02B830FB807819EA4@qq.com>

Dear Ilya Moiseenko,
       as professor Zhang mentioned,(last year Ilya Moiseenko did some NDN API work which incorporated a simple congestion control, but that code is not included in the NFD release--I'm pretty sure he's on this list if you want to ask him)
       I would like to know how do you do about congestion control last year.


------------------
???
?????????????
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160406/01e94242/attachment.html>

From Marc.Mosko at parc.com  Wed Apr  6 06:25:34 2016
From: Marc.Mosko at parc.com (Marc.Mosko at parc.com)
Date: Wed, 6 Apr 2016 13:25:34 +0000
Subject: [Ndn-interest] Naming conventions (was Re: NDN protocol principles:
 name discovery)
In-Reply-To: <3279F45E-CF92-4994-9EAC-19856F5D33B9@cs.ucla.edu>
References: <56E42E81.3060407@cisco.com> <56E49873.9090806@ics.uci.edu>
	<56E58A40.9090704@cisco.com>
	<F9C67E19-D956-415D-822D-07FFE654D4EE@remap.ucla.edu>
	<56E70CA2.1080905@cisco.com>
	<1870C141-6751-4065-9377-8FE8E104C477@gmail.com>
	<C040108A-16E8-4D2C-B135-AEA5D8735C46@parc.com>
	<8149253A-E347-432A-9E92-E737F663AA1E@cisco.com>
	<40BD7781-7CEE-4710-A819-C528C39AE5E1@cs.ucla.edu>
	<03C09735-E6E6-41D5-8445-7AEBECFF435F@cisco.com>
	<71B7601B-0A0B-435D-81FF-F6B6367CCC13@cs.ucla.edu>
	<AC704AC0-5A68-43F5-AB0F-00AB4FB84098@parc.com>
	<3279F45E-CF92-4994-9EAC-19856F5D33B9@cs.ucla.edu>
Message-ID: <17AD1693-D3A8-4346-9BEE-000185420AF0@parc.com>

Ok, that?s fair to say that I am not up on current NDN naming conventions.

Is there a specification on this that I could read?  There was some material on this in http://named-data.net/project/archoverview.  Is there a newer or more specific reference?

I do have a problem with basic functions like in-network discovery and data transport being based on conventions and not specifications (like the packet format).  I am of the position that there is no one ?application? for the consumer/producer.  Data will want to be shared between many applications by many implementers.  If each application must know how the source application named its data in order to fetch it, then I think that will lead to an n^2 problem of needing to know naming conventions and transports.  Applications already need to handle many data types (e.g. png, jpg, rtf, doc, html) and if they also need to handle many transport / naming conventions, I think that is adding a lot of complexity; especially if they have to guess the naming convention based on name format without a specification.

If there is a common convention, then I would make that explicit in the name somehow (there are many ways).  For example, if one scheme uses version and segment and other scheme uses nonces and hash chains in the name, they are not compatible at the transport layer.  If you need a different mechanism to retrieve data, then I think there needs to be something to identify that without needing to heuristically guess it based on the format of the name.  And there needs to be a specification on how that transport naming works.

In CCNx, we allocated specific name segment types to mean a specific protocol is operating at that level of the name.  For example, a version has a specific type and a segment number (chunk number) has a specific type.  Is there  a similar mechanism in NDN?

Thank you,
Marc

On Apr 5, 2016, at 11:15 PM, Lixia Zhang <lixia at cs.ucla.edu<mailto:lixia at cs.ucla.edu>> wrote:

(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<mailto: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



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

From Marc.Mosko at parc.com  Wed Apr  6 06:27:05 2016
From: Marc.Mosko at parc.com (Marc.Mosko at parc.com)
Date: Wed, 6 Apr 2016 13:27:05 +0000
Subject: [Ndn-interest] In-network discovery (was Re: NDN protocol
 principles: name discovery)
In-Reply-To: <3279F45E-CF92-4994-9EAC-19856F5D33B9@cs.ucla.edu>
References: <56E42E81.3060407@cisco.com> <56E49873.9090806@ics.uci.edu>
	<56E58A40.9090704@cisco.com>
	<F9C67E19-D956-415D-822D-07FFE654D4EE@remap.ucla.edu>
	<56E70CA2.1080905@cisco.com>
	<1870C141-6751-4065-9377-8FE8E104C477@gmail.com>
	<C040108A-16E8-4D2C-B135-AEA5D8735C46@parc.com>
	<8149253A-E347-432A-9E92-E737F663AA1E@cisco.com>
	<40BD7781-7CEE-4710-A819-C528C39AE5E1@cs.ucla.edu>
	<03C09735-E6E6-41D5-8445-7AEBECFF435F@cisco.com>
	<71B7601B-0A0B-435D-81FF-F6B6367CCC13@cs.ucla.edu>
	<AC704AC0-5A68-43F5-AB0F-00AB4FB84098@parc.com>
	<3279F45E-CF92-4994-9EAC-19856F5D33B9@cs.ucla.edu>
Message-ID: <A5DA1DAA-2E0B-4168-9E06-F08FEE9ABFE5@parc.com>

Is there a specification or algorithm on how to get latest version that I could read for the NDN naming convention?

Thank you,
Marc


On Apr 5, 2016, at 11:15 PM, Lixia Zhang <lixia at cs.ucla.edu<mailto:lixia at cs.ucla.edu>> wrote:

(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<mailto: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



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

From iliamo at mailbox.org  Wed Apr  6 07:16:03 2016
From: iliamo at mailbox.org (Ilya Moiseenko)
Date: Wed, 6 Apr 2016 10:16:03 -0400
Subject: [Ndn-interest] Ilya Moiseenko's congestion control
In-Reply-To: <tencent_5C92FAF02B830FB807819EA4@qq.com>
References: <tencent_5C92FAF02B830FB807819EA4@qq.com>
Message-ID: <98912817-17C0-434C-89A3-75733FC0FE4A@mailbox.org>

Hi,
Just take a look at this paper http://escholarship.org/uc/item/17c660bp <http://escholarship.org/uc/item/17c660bp>
Sections 3.6 and 4.3.

Ilya


> On Apr 6, 2016, at 4:38 AM, ??? <121049189 at qq.com> wrote:
> 
> Dear Ilya Moiseenko,
>        as professor Zhang mentioned,(last year Ilya Moiseenko did some NDN API work which incorporated a simple congestion control, but that code is not included in the NFD release--I'm pretty sure he's on this list if you want to ask him)
>        I would like to know how do you do about congestion control last year.
> 
> ------------------
> ???
> ?????????????
>  
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> 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/20160406/3fba0371/attachment.html>

From jburke at remap.UCLA.edu  Wed Apr  6 07:31:52 2016
From: jburke at remap.UCLA.edu (Burke, Jeff)
Date: Wed, 6 Apr 2016 14:31:52 +0000
Subject: [Ndn-interest] NIST Workshop on NDN, May 31-June 1, 2016
Message-ID: <8E7F0868-B753-4B84-995F-DFA84170DAB2@remap.ucla.edu>


Please join us for this workshop on NDN @ NIST: 

http://www.nist.gov/itl/antd/named-data-networking.cfm

Note that the website will be updated regularly with new details, as we assemble the agenda and speakers. 

---

Workshop on Named Data Networking
National Institute of Standards & Technology

Start Date: Tuesday, May 31, 2016 
End Date: Wednesday, June 1, 2016 
Location: NIST, 100 Bureau Drive, Gaithersburg, Maryland 20899


Purpose:


A two-day Named Data Networking (NDN) Workshop will take place on the NIST campus in Gaithersburg, MD on May 31-June 1, 2016. NIST has ongoing efforts in Cyber-Physical Systems / Internet of Things and Big Data. This workshop will gather representatives from industry, government, and academia to discuss the role that the NDN future internet architecture can play in support of these two critical network environments, as well as future content delivery over mobile networks (e.g., augmented reality).

Future internet architectures based on the information-centric networking (ICN) paradigm propose to address ongoing challenges in supporting modern applications with IP, especially in networks of diverse and intermittent links. To do so, they effectively bring Web-like semantics to the network layer, directly supporting dissemination of named, signed data. Named Data Networking (NDN) <http://named-data.net/> is one such architecture that has a growing community of interest.

Given the increasing interest in the Internet of Things (IoT), Big Data, and VR/AR, which is driven by their potential for a strong economic impact across sectors, this workshop will examine NDN as an alternative networking approach in these areas. The first day of the workshop is focused on IoT and will feature keynotes by invited speakers as well as presentations and panels. It will explore how ICN/NDN addresses some of the key challenges in security, multi-party communication models, stack and application complexity, efficient resource utilization, and scalability faced by emerging IoT applications. The second day will have a similar format focused on the themes of Big Data and Mobile AR. The following draft agenda will be updated with the complete list of speakers and presentations.







From klaus at email.arizona.edu  Wed Apr  6 16:25:22 2016
From: klaus at email.arizona.edu (Klaus Schneider)
Date: Wed, 6 Apr 2016 16:25:22 -0700
Subject: [Ndn-interest] Hop-by-Hop Flow Balance
Message-ID: <57059AE2.8000607@email.arizona.edu>

Dear Dr. Solis,

I agree that there are some missing pieces to the Hop-by-Hop flow 
balance. Can you give us some pointers to the "other ways to do 
flow-balance and flow-control" ?

Can they solve the problem that the data packet size is essentially 
unknown to routers and can be huge?

Best regards,
Klaus Schneider


> Message: 2
> Date: Mon, 14 Mar 2016 23:09:34 +0000
> From: <Ignacio.Solis at parc.com>
> To: <aa at CS.UCLA.EDU>, <ndn-interest at lists.cs.ucla.edu>
> Subject: [Ndn-interest] Hop-by-Hop Flow Balance
> Message-ID: <F7A301F8-CE16-42EC-855E-CB8CB1472A00 at parc.com>
> Content-Type: text/plain; charset="utf-8"
>
> [ Disclaimer: CCN currently uses flow balance as well ]
>
> The current Hop-by-Hop Flow Balance is nonsense.
>
>
>
>
>
> On 3/10/16, 11:46 PM, "Ndn-interest on behalf of Alex Afanasyev" <ndn-interest-bounces at lists.cs.ucla.edu on behalf of aa at CS.UCLA.EDU> wrote:
>> [6] **Hop-by-Hop Flow Balance**:
>>    Over each link, one interest packet should bring back no more than one data packet.
>
> Seriously, who thinks this actually works?
>
> Let me quote the webpage ( http://named-data.net/project/ndn-design-principles/ ):
> "[6] Hop-by-Hop Flow Balancing: Over each link, one interest packet should bring back no more than one data packet.
> Hop-by-hop flow balancing enables each node to control load over its links. By deciding to sending interest over a link, router commits bandwidth for the returned data. By limiting the number of interests sent, each router and client node in the network control how much data it will receive.
> "
>
> Either there is a lot of information missing here to justify why this is so, or this is very na?ve.
>
> First, if what you want to do is limit the number of content objects (or packets) returned, you don?t need to send one interest.  _Specially_ for NDN, which has prefix matching, you could send one interest with a count number (10) and expect to receive 10 content objects back.  There is no reason why I need to send 10 exact copies of the same interest.   Even if the interests had small variations, why send 10? Why not send 1 + the 10 deltas?   I guess it?s possible you may call that part of the ?network adaptation layer?, who knows.
>
> Also by requiring 1-to-1, you are always requiring an overhead (on the requester side) that is quite high. If you think of today?s type of networks, where a packet (internet sized) is around 1500 bytes, that means that even if we send interests of 30 bytes, we are incurring quite a bit of overhead in the upstream. This becomes considerable when doing high bandwidth video.
>
> Please explain why the 1-to-1 is good.
>
> Second, NDN allows very large packet sizes.  So, when I send 1 interest, I don?t now if what I?m going to get back is 1 byte or 18 exabytes.  How do routers use this information to control how much data they?re going to receive? Are they going to reserve 18 exabytes of traffic time?
>
> If this principle were to be re-written as:
> ?Allow network nodes to participate in flow control? then the actual engineering solution might be able to achieve this.
>
> Finally, at least we should acknowledge the limitations this type of approach requires; like symmetrical forwarding.
>
> It would be awkward if the only way for NDN to work over Satellite links would be to break the principles.
>
> Nacho
>
>
> PS. Yes, there are people in this community who have looked at other ways to do flow-balance and flow-control. Maybe we should be learning from those and not just claiming as principle what we do today because we don?t want it questioned.
>
> --
> Nacho (Ignacio) Solis
> Protocol Architect
> Principal Scientist
> Palo Alto Research Center (PARC)
> +1(650)812-4458
> Ignacio.Solis at parc.com
>


From pedrofigueiredoc at gmail.com  Mon Apr 11 07:26:29 2016
From: pedrofigueiredoc at gmail.com (Pedro Figueiredo)
Date: Mon, 11 Apr 2016 11:26:29 -0300
Subject: [Ndn-interest] Measurements Table
Message-ID: <CA+ud=jvLgueWRFgbqg4RPe2wzu1CzJsm9wCLvJ0-sCHZsw2NyA@mail.gmail.com>

Hi everyone,

Is there any way (on current NFD implementation) that one can list the
Measurements Table entries using something as nfd-status? Or just accessing
via code methods get/setEntry ?

I also have questions about how it is used by the forwarding strategies. On
NFD-dev guide it states that the strategies use the table to store
arbitrary information (can be delay, jitter, RTT, etc.), but on
http://named-data.net/doc/NFD/current/overview.html it says that the
strategies stores past performance results. How "past" is that? How often
does strategies update this table?

I am guessing that what you would like to store varies from each forwarding
strategy, but is there any common frequency of updates that the strategies
use to input entries on the table (e.g. every successful interest-data
retrieval)?

Thanks in advance,

Pedro.

--
------------------------------------------
*Pedro H. C. Figueiredo Soares*
Computer Engineering - UFPA (ITEC/FCT)
Laboratory of Signal Processing - LaPS
pedro.figueiredo at itec.ufpa.br | p.h.c at ieee.org
-------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160411/09024430/attachment.html>

From omarilias.elmimouni at nist.gov  Mon Apr 11 13:56:24 2016
From: omarilias.elmimouni at nist.gov (El Mimouni, Omar Ilias (IntlAssoc))
Date: Mon, 11 Apr 2016 20:56:24 +0000
Subject: [Ndn-interest] FW: [jndn] Send multiple interests
Message-ID: <BN3PR09MB0545C95D80CC4DF6C509D14396940@BN3PR09MB0545.namprd09.prod.outlook.com>

Hi all,

I am working with the java implementation of NDN (testing a simple consumer-producer application), and I am wondering if it is possible to send multiple interests at the same time.
For example:

Consumer                           Producer
========                           =======

Send 5 interests:
1----->
2----->
3----->
4----->
5----->
Then, receive data
                                                1<-------
2<-------
3<-------
4<-------
5<-------

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

From 121049189 at qq.com  Tue Apr 12 00:25:10 2016
From: 121049189 at qq.com (=?gb18030?B?1dTWvs6w?=)
Date: Tue, 12 Apr 2016 15:25:10 +0800
Subject: [Ndn-interest] NDN in GENI
Message-ID: <tencent_3C9E835814D557B025929427@qq.com>

Dear all,
    I want to run nfd in GENI. I just know about GENI yesterday. If  I run nfd in GENI, how large the scale is. 
My teacher want to have a experimental network in China , he said he could have lots machine in China. 
if we use GENI, we don't  need  really machine in life.
I wander how long could I finish my work. and now, I apply a GENI account, but I can't apply it successfuly.


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

From Navdeep.Uniyal at neclab.eu  Wed Apr 13 04:12:33 2016
From: Navdeep.Uniyal at neclab.eu (Navdeep Uniyal)
Date: Wed, 13 Apr 2016 11:12:33 +0000
Subject: [Ndn-interest] [Mini-NDN] Interfaces went down in minindn
In-Reply-To: <15421E67B274CD4AB5F6AEA46A684C3708AB30DB@PALLENE.office.hd>
References: <15421E67B274CD4AB5F6AEA46A684C3708AB2D2C@PALLENE.office.hd>
	<BY1PR0401MB16101C04E0AEE1B8034D995BD99F0@BY1PR0401MB1610.namprd04.prod.outlook.com>
	<15421E67B274CD4AB5F6AEA46A684C3708AB2DAE@PALLENE.office.hd>
	<C322DB29-2543-49C8-AC04-A2E1CBFD3C77@memphis.edu>,
	<15421E67B274CD4AB5F6AEA46A684C3708AB2E4F@PALLENE.office.hd>,
	<BY1PR0401MB1610F54F21AF6481BEB1D174D9900@BY1PR0401MB1610.namprd04.prod.outlook.com>
	<BY1PR0401MB16101EE6F8FB09A0C685AAC5D9900@BY1PR0401MB1610.namprd04.prod.outlook.com>
	,<15421E67B274CD4AB5F6AEA46A684C3708AB3037@PALLENE.office.hd>
	<BY1PR0401MB1610B2421818E4B72E30A18DD9940@BY1PR0401MB1610.namprd04.prod.outlook.com>
	<15421E67B274CD4AB5F6AEA46A684C3708AB30DB@PALLENE.office.hd>
Message-ID: <15421E67B274CD4AB5F6AEA46A684C3708AB31C2@PALLENE.office.hd>

Hi Junxiao,

Please if you can advise me on this. This issue is blocking our testing for a long time now and I am not able to rectify it.


Best Regards,
Navdeep Uniyal

From: Mini-NDN [mailto:mini-ndn-bounces at lists.cs.ucla.edu] On Behalf Of Navdeep Uniyal
Sent: Dienstag, 12. April 2016 12:29
To: Ashlesh Gawande (agawande); mini-ndn at lists.cs.ucla.edu; nfd-dev at lists.cs.ucla.edu
Subject: Re: [Mini-NDN] Interfaces went down in minindn

Hi Ashlesh,

Thank you for your help. I changed the experiment as you suggested and tested it again.


1.       I found interests moving from the host to the server but data not coming in.

2.       Yes the occurrence of error is after quitting minindn as you said and only after quitting miniNDN, requested data is coming in and is marked as unsolicited.

I could not find the issue why data generation suddenly stops as ndn dump and nfd logs could not provide proper clue.

I am attaching my configuration files, logs and dump files. Also, adding nfd-dev list to this mail if someone could help in this regard.

Steps to redo the experiment:

1.       Install experiment nletest.py on minindn using "install.sh -i"

2.       Copy topology file nectopo.conf to /{path to minindn}/ndn_utils/topologies

3.       Copy traffic generator server and client files "ndn-traffic-client.conf" and "ndn-traffic-server.conf" to /{path to ndn traffic generator}/ndn-traffic-generator/build.

4.       Run sudo minindn --experiment=icnle nectopo.conf

5.       On Mininet CLI> ga ndn-traffic -c 1000 -i 100 /home/mininet/mini-ndn/ndn-traffic-generator/build/ndn-traffic-client.conf



Best Regards,
Navdeep Uniyal


From: Ashlesh Gawande (agawande) [mailto:agawande at memphis.edu]
Sent: Montag, 11. April 2016 22:08
To: Navdeep Uniyal; mini-ndn at lists.cs.ucla.edu<mailto:mini-ndn at lists.cs.ucla.edu>
Subject: Re: [Mini-NDN] Interfaces went down in minindn


Some observations:



1) I think the "interface went down" error appears when you quit Mini-NDN and NFD is killed.



2) When I tried interval as 1ms (count: 1000) - no loss for the first 4 tries,  on the 5th time I see the same problem.



3) I turned on ndndump and found that sa suddenly stops responding with data - not sure why. For some time, it seems, interest do reach sa without it responding.



Can you modify your experiment as below and trace interest/data and see if you can find where it fails:


    def setup(self):
       for host in self.net.hosts:
                for intf in host.intfNames():
                        ndnDumpOutputFile = "dump.%s_%s" % (intf, str(host.intf(intf).IP()))
                        host.cmd("sudo ndndump -f '.*nle.*' -i %s > %s &" % (intf, ndnDumpOutputFile))
                if host.name == 'ca':

Ashlesh
________________________________
From: Navdeep Uniyal <Navdeep.Uniyal at neclab.eu<mailto:Navdeep.Uniyal at neclab.eu>>
Sent: Monday, April 11, 2016 7:37:37 AM
To: Ashlesh Gawande (agawande)
Subject: RE: [Mini-NDN] Interfaces went down in minindn


Hi Ashlesh,



Please do let me know if there are some updates on the issue.



Best Regards,

Navdeep Uniyal



From: Navdeep Uniyal
Sent: Freitag, 8. April 2016 09:48
To: 'Ashlesh Gawande (agawande)'
Cc: mini-ndn at lists.cs.ucla.edu<mailto:mini-ndn at lists.cs.ucla.edu>
Subject: RE: [Mini-NDN] Interfaces went down in minindn



Thank You Ashlesh,



The results are similar for me.



Best Regards,

Navdeep Uniyal



From: Ashlesh Gawande (agawande) [mailto:agawande at memphis.edu]
Sent: Freitag, 8. April 2016 00:52
To: Navdeep Uniyal
Cc: mini-ndn at lists.cs.ucla.edu<mailto:mini-ndn at lists.cs.ucla.edu>
Subject: Re: [Mini-NDN] Interfaces went down in minindn



Okay I looked at your experiment and modified my ndn-traffic-client/server appropriately.



Initially all the interest are answered correctly.

Then you start to see some timeouts.

Then all interests time out.

My total interest loss was ~25%.



I am looking into it further.



Ashlesh

________________________________

From: Mini-NDN <mini-ndn-bounces at lists.cs.ucla.edu<mailto:mini-ndn-bounces at lists.cs.ucla.edu>> on behalf of Ashlesh Gawande (agawande) <agawande at memphis.edu<mailto:agawande at memphis.edu>>
Sent: Thursday, April 7, 2016 5:12 PM
To: Navdeep Uniyal
Cc: mini-ndn at lists.cs.ucla.edu<mailto:mini-ndn at lists.cs.ucla.edu>
Subject: Re: [Mini-NDN] Interfaces went down in minindn



Is this ndn-traffic-client.conf the default one?

Ashlesh

________________________________

From: Navdeep Uniyal <Navdeep.Uniyal at neclab.eu<mailto:Navdeep.Uniyal at neclab.eu>>
Sent: Thursday, April 7, 2016 2:58 AM
To: Ashlesh Gawande (agawande)
Cc: mini-ndn at lists.cs.ucla.edu<mailto:mini-ndn at lists.cs.ucla.edu>; Lan Wang (lanwang)
Subject: RE: [Mini-NDN] Interfaces went down in minindn



Hi Ashlesh,



PFA the attached files I used for experiments.

"nectopo.conf" is the topology file

"nletest.py" is the experiment file





sudo minindn --experiment=icnle nectopo.conf

On Mininet CLI > ga ndn-traffic -c 1000 -i 10 /home/mininet/mini-ndn/ndn-traffic-generator/build/ndn-traffic-client.conf







Best Regards,

Navdeep Uniyal



From: Lan Wang (lanwang) [mailto:lanwang at memphis.edu]
Sent: Donnerstag, 7. April 2016 01:22
To: Navdeep Uniyal
Cc: Ashlesh Gawande (agawande); mini-ndn at lists.cs.ucla.edu<mailto:mini-ndn at lists.cs.ucla.edu>
Subject: Re: [Mini-NDN] Interfaces went down in minindn



Ashlesh,



Maybe Navdeep can give you his setup files and you repeat his experiment?

Lan



On Apr 6, 2016, at 10:32 AM, Navdeep Uniyal <navdeep.uniyal at neclab.eu<mailto:navdeep.uniyal at neclab.eu>> wrote:



Hi Ashlesh,



Thank you for the reply. The interest sending rate is 100/sec although I checked it with 10/sec. In both the cases I found similar results. Interesting is the data generation and arrival time. The data transfer behaves perfectly fine for initial few interests while after a certain time it just stops and the requested data then is arrives just after the interfaces goes down(I guess mostly when I am stopping the Mininet topology) and are marked as unsolicited data.

I could not get this behavior if it is because of link issues, NFD issue or NDN Traffic generator issue. I tried asking the solution on the other nfd-dev mailing list but could not get any response.





Best Regards,

Navdeep Uniyal



From: Ashlesh Gawande (agawande) [mailto:agawande at memphis.edu]
Sent: Mittwoch, 6. April 2016 16:40
To: Navdeep Uniyal; mini-ndn at lists.cs.ucla.edu<mailto:mini-ndn at lists.cs.ucla.edu>
Subject: Re: Interfaces went down in minindn



What is the rate of sending interests?

Can you try lowering it and see if interest drops are decreased?

Ashlesh

________________________________

From: Mini-NDN <mini-ndn-bounces at lists.cs.ucla.edu<mailto:mini-ndn-bounces at lists.cs.ucla.edu>> on behalf of Navdeep Uniyal <Navdeep.Uniyal at neclab.eu<mailto:Navdeep.Uniyal at neclab.eu>>
Sent: Wednesday, April 6, 2016 3:52 AM
To: mini-ndn at lists.cs.ucla.edu<mailto:mini-ndn at lists.cs.ucla.edu>
Subject: [Mini-NDN] Interfaces went down in minindn



Hi everyone,



I have been running some experiments using minindn using NDN traffic generator for interest and data generation. I am facing a few issues as I am unable to get the data packets in response after a certain period of time. In my configuration I am making cs store size to be zero so that all interests can reach the producer. While investigating the issue of interest drops I found few errors in the nfd logs. Below are the few errors which I am getting in the log file:



1459932297.745268 ERROR: [EthernetTransport] [id=264,local=dev://sa-eth0,remote=ether://[01:00:5e:00:17:aa]] pcap_next_ex failed: The interface went down

1459932297.761311 ERROR: [EthernetTransport] [id=263,local=dev://sa-eth1,remote=ether://[01:00:5e:00:17:aa]] pcap_next_ex failed: The interface went down

1459932297.777269 ERROR: [EthernetTransport] [id=262,local=dev://sa-eth2,remote=ether://[01:00:5e:00:17:aa]] pcap_next_ex failed: The interface went down



Due to this, the interests are not getting satisfied. Attached are the nfd logs of the producer(similar errors are being observed on the other nodes as well). Please if someone can help me resolving the issue.







Best Regards,

Navdeep Uniyal



_______________________________________________
Mini-NDN mailing list
Mini-NDN at lists.cs.ucla.edu<mailto:Mini-NDN at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/mini-ndn


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

From mastorakis at CS.UCLA.EDU  Thu Apr 14 10:13:52 2016
From: mastorakis at CS.UCLA.EDU (Spyridon (Spyros) Mastorakis)
Date: Thu, 14 Apr 2016 10:13:52 -0700
Subject: [Ndn-interest] IDE suggestion
In-Reply-To: <712FE4E7257849499414892DD92704BC77C55FB6@INFRAEX02.oxia.corp>
References: <712FE4E7257849499414892DD92704BC77C55FB6@INFRAEX02.oxia.corp>
Message-ID: <B7BD4DE0-B8E3-45B8-9E93-5599A09B4AB2@cs.ucla.edu>

Hi,

personally, I have been using Atom for the last couple of months and I am quite happy with it:

https://atom.io <https://atom.io/>

Alex has been using a fully customized version of emacs:

https://www.gnu.org/software/emacs/ <https://www.gnu.org/software/emacs/>

Spyridon (Spyros) Mastorakis
Personal Website: http://cs.ucla.edu/~mastorakis/ <http://cs.ucla.edu/~mastorakis/>
Internet Research Laboratory
Computer Science Department
UCLA


> On Apr 14, 2016, at 5:53 AM, Nour El Houda Ben Youssef <NourElHouda.BenYoussef at wevioo.com> wrote:
> 
> Dear ndnSimers
>  
> Which IDE do you suggest while adding new features to ndnSIM?
>  
> Best regards
>  
> <image002.png>
> Nour El Houda BEN YOUSSEF|Doctorante
> Technopark El Ghazela 2088 Tunis- Tunisia
> Phone: +216 31 34 00 14
> Mobile: +216 24 54 24 54 
> www.wevioo.com <http://www.wevioo.com/>
> Paris ? Tunis - Dubai ? Alger

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

From klaus at email.arizona.edu  Thu Apr 14 13:00:55 2016
From: klaus at email.arizona.edu (Klaus Schneider)
Date: Thu, 14 Apr 2016 13:00:55 -0700
Subject: [Ndn-interest] IDE suggestion
In-Reply-To: <B7BD4DE0-B8E3-45B8-9E93-5599A09B4AB2@cs.ucla.edu>
References: <712FE4E7257849499414892DD92704BC77C55FB6@INFRAEX02.oxia.corp>
	<B7BD4DE0-B8E3-45B8-9E93-5599A09B4AB2@cs.ucla.edu>
Message-ID: <570FF6F7.9020401@email.arizona.edu>

I'm using Eclipse CDT. The C++ Indexer is quite helpful, but requires 
some tuning (you don't want to index the whole ns3 folder).

Best regards,
Klaus

On 04/14/2016 10:13 AM, Spyridon (Spyros) Mastorakis wrote:
> Hi,
>
> personally, I have been using Atom for the last couple of months and I
> am quite happy with it:
>
> https://atom.io
>
> Alex has been using a fully customized version of emacs:
>
> https://www.gnu.org/software/emacs/
>
> Spyridon (Spyros) Mastorakis
> Personal Website: http://cs.ucla.edu/~mastorakis/
> <http://cs.ucla.edu/%7Emastorakis/>
> Internet Research Laboratory
> Computer Science Department
> UCLA
>
>
>> On Apr 14, 2016, at 5:53 AM, Nour El Houda Ben Youssef
>> <NourElHouda.BenYoussef at wevioo.com
>> <mailto:NourElHouda.BenYoussef at wevioo.com>> wrote:
>>
>> Dear ndnSimers
>> Which IDE do you suggest while adding new features to ndnSIM?
>> Best regards
>> *<image002.png>*
>> 	
>> *Nour El Houda BEN YOUSSEF*|Doctorante
>> Technopark El Ghazela 2088 Tunis- Tunisia
>> Phone: +216 31 34 00 14
>> Mobile: +216 24 54 24 54
>> www.wevioo.com <http://www.wevioo.com/>
>> Paris ? Tunis - Dubai ? Alger
>>
>
>
>
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>


From M.AbdollahiSabet at mail.sbu.ac.ir  Thu Apr 14 22:06:57 2016
From: M.AbdollahiSabet at mail.sbu.ac.ir (Muhammad Hosain Abdollahi Sabet)
Date: Fri, 15 Apr 2016 09:36:57 +0430
Subject: [Ndn-interest] IDE suggestion
References: <712FE4E7257849499414892DD92704BC77C55FB6@INFRAEX02.oxia.corp><B7BD4DE0-B8E3-45B8-9E93-5599A09B4AB2@cs.ucla.edu>
	<570FF6F7.9020401@email.arizona.edu>
Message-ID: <4AC03A6244C3C34BB52A7EC60B799C4C03CC2A24@m-pdc.sbu.ac.ir>

I've been using Qt Creator these days. Lightweight, swift and fast. Of course you don't need to index the whole ns3 folder. And again, do building and debugging with waf itself.

Thanks,
Sabet



-----Original Message-----
From: Ndn-interest on behalf of Klaus Schneider
Sent: Fri 4/15/2016 12:30 AM
To: Spyridon (Spyros) Mastorakis; Nour El Houda Ben Youssef
Cc: ndn-interest at lists.cs.ucla.edu; ndnsim at lists.cs.ucla.edu; cawka1 at gmail.com
Subject: Re: [Ndn-interest] IDE suggestion
 
I'm using Eclipse CDT. The C++ Indexer is quite helpful, but requires 
some tuning (you don't want to index the whole ns3 folder).

Best regards,
Klaus

On 04/14/2016 10:13 AM, Spyridon (Spyros) Mastorakis wrote:
> Hi,
>
> personally, I have been using Atom for the last couple of months and I
> am quite happy with it:
>
> https://atom.io
>
> Alex has been using a fully customized version of emacs:
>
> https://www.gnu.org/software/emacs/
>
> Spyridon (Spyros) Mastorakis
> Personal Website: http://cs.ucla.edu/~mastorakis/
> <http://cs.ucla.edu/%7Emastorakis/>
> Internet Research Laboratory
> Computer Science Department
> UCLA
>
>
>> On Apr 14, 2016, at 5:53 AM, Nour El Houda Ben Youssef
>> <NourElHouda.BenYoussef at wevioo.com
>> <mailto:NourElHouda.BenYoussef at wevioo.com>> wrote:
>>
>> Dear ndnSimers
>> Which IDE do you suggest while adding new features to ndnSIM?
>> Best regards
>> *<image002.png>*
>> 	
>> *Nour El Houda BEN YOUSSEF*|Doctorante
>> Technopark El Ghazela 2088 Tunis- Tunisia
>> Phone: +216 31 34 00 14
>> Mobile: +216 24 54 24 54
>> www.wevioo.com <http://www.wevioo.com/>
>> Paris - Tunis - Dubai - Alger
>>
>
>
>
> _______________________________________________
> Ndn-interest mailing list
> 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
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/20160415/e5cecd87/attachment.html>

From NourElHouda.BenYoussef at wevioo.com  Thu Apr 21 04:21:14 2016
From: NourElHouda.BenYoussef at wevioo.com (Nour El Houda Ben Youssef)
Date: Thu, 21 Apr 2016 11:21:14 +0000
Subject: [Ndn-interest] ndn question
Message-ID: <712FE4E7257849499414892DD92704BC77C5E42C@INFRAEX02.oxia.corp>

Dear ndn users

I would like to ask what really happens when an ndn node receives an interest that he can't satisfy (no corresponding content in its CS, no corresponding entry neither in its PIT nor in its FIB)
Does it drop it ?

Another question on extending ndn with pub/sub mechanism, in fact each time we need to retrieve a content we have to express an interest
What if I want to express the interest once and receive the corresponding content each time it is published?

Best regards



[logoslogan.png]

Nour El Houda BEN YOUSSEF|Doctorante
Technopark El Ghazela 2088 Tunis- Tunisia
Phone: +216 31 34 00 14
Mobile: +216 24 54 24 54
www.wevioo.com
Paris - Tunis - Dubai - Alger







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160421/1e550616/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 4997 bytes
Desc: image001.png
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160421/1e550616/attachment.png>

From wentaoshang at gmail.com  Thu Apr 21 11:52:38 2016
From: wentaoshang at gmail.com (Wentao Shang)
Date: Thu, 21 Apr 2016 11:52:38 -0700
Subject: [Ndn-interest] First release of the micro-forwarder browser
 extension
Message-ID: <CAD4s1gR9HCbMO0m7KsaQ90KpJHwDLCmb1CmRKd6Xdt0et0PPmQ@mail.gmail.com>

Hi team,

During the 2nd NDN Hackathon at UCSD last month, a small team of developers
including Jeff Thompson, Muktadir Chowdhury and me worked on a project that
uses NDN-JS library to develop a micro NDN forwarder as a browser
extension.  We were able to run the JavaScript-based ChronoChat app in two
tabs inside the same browser and seamlessly communicate with each other
through the browser extension, without any dependency on external NFD
service.  We demonstrated the result at the end of the Hackathon and won
the Best External Impact award (see http://2nd-ndn-hackathon.named-data.net/
).

After the Hackathon we continued to improve the browser extension to make
it more user-friendly.  Now we are pleased to announce the first release of
the extension to the public community.  Here is a list of features we
currently provide:

1/ Cross-browser support: the same code runs in both Firefox (45.0+) and
Chrome, and we provide signed extension package for both browsers;

2/ Ability to connect to external NDN forwarder: the browser extension can
establish WebSocket connections to external NFD, and the connections will
be shared by all the tabs inside the browser;

3/ Simple configuration page for the extension: the user can add more
routes to external NFDs and show current micro forwarder status on the
config page;

NDN-JS is by far the most popular client library for the developers in the
NDN community.  We believe the new micro-forwarder extension will provide
stronger NDN support for browser platforms and enable more creative Web
applications powered by the NDN protocol.

The source code of the extension is part of the NDN-JS codebase and can be
found at
https://github.com/named-data/ndn-js/tree/master/tools/micro-forwarder.
Link to the Firefox Add-on package:
https://github.com/named-data/ndn-js/raw/master/tools/micro-forwarder/ndn-micro-forwarder.xpi
.
Link to the Chrome extension package:
https://github.com/named-data/ndn-js/raw/master/tools/micro-forwarder/extension.crx
.
Any feedback/bug report is welcome.

Best,
Wentao

-- 
PhD @ IRL, CSD, UCLA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160421/14a7011c/attachment.html>

From M.AbdollahiSabet at mail.sbu.ac.ir  Tue Apr 26 00:24:34 2016
From: M.AbdollahiSabet at mail.sbu.ac.ir (Muhammad Hosain Abdollahi Sabet)
Date: Tue, 26 Apr 2016 11:54:34 +0430
Subject: [Ndn-interest] ndn question
Message-ID: <4AC03A6244C3C34BB52A7EC60B799C4C043E7B53@m-pdc.sbu.ac.ir>

Hi,

 

1- That is when NACK comes up! For example in DFZ(Default-free zone) when there is no entry(in CS,PIT or FIB), a NACK with some description will be sent back to the consumer.

 

2- Could you elaborate a bit more on "each time it is published"? Generally a Data packet cannot traverse nodes if already there is no interest for it.

 

Thanks,

Sabet

 

From: Ndn-interest [mailto:ndn-interest-bounces at lists.cs.ucla.edu] On Behalf Of Nour El Houda Ben Youssef
Sent: Thursday, April 21, 2016 3:51 PM
To: ndn-interest at lists.cs.ucla.edu
Subject: [Ndn-interest] ndn question

 

Dear ndn users

 

I would like to ask what really happens when an ndn node receives an interest that he can?t satisfy (no corresponding content in its CS, no corresponding entry neither in its PIT nor in its FIB)

Does it drop it ?

 

Another question on extending ndn with pub/sub mechanism, in fact each time we need to retrieve a content we have to express an interest 

What if I want to express the interest once and receive the corresponding content each time it is published?

 

Best regards

 

 

 

 

Nour El Houda BEN YOUSSEF|Doctorante

Technopark El Ghazela 2088 Tunis- Tunisia 

Phone: +216 31 34 00 14 

Mobile: +216 24 54 24 54  

www.wevioo.com

Paris ? Tunis - Dubai ? Alger

 

 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160426/9cd994b3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 4997 bytes
Desc: image001.png
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160426/9cd994b3/attachment.png>

From mobinranjbar at hotmail.com  Wed Apr 27 01:47:36 2016
From: mobinranjbar at hotmail.com (Mobin Ranjbar)
Date: Wed, 27 Apr 2016 08:47:36 +0000
Subject: [Ndn-interest] Performance Measures Criteria of Skiplist in Content
 Store
Message-ID: <BAY173-W18477D0A6059B3ED7DCB08CE640@phx.gbl>

Hi NDN-Users,
I am working on a paper/project to improve content store's data structure(Skiplist) for Big Data use cases(Connecting Big Data World to NDN). I am looking for recent papers about ideas in content store specially their Performance Measures Criteria. How can I find them?
Best,
________Mobin RanjbarSoftware Engineer, Big Data Evangelist and Startup GuyCo-Founder of Iran StartupsFounder of SharikshoEditor in Chief at Techly.coFounder of FaraFekr TechnologyFounder of Hadoop.irFounder of Big Data WatcherWebsite | Twitter | Linkedin | skype: mobinranjbar
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160427/fcff8315/attachment.html>

From NourElHouda.BenYoussef at wevioo.com  Wed Apr 27 02:53:49 2016
From: NourElHouda.BenYoussef at wevioo.com (Nour El Houda Ben Youssef)
Date: Wed, 27 Apr 2016 09:53:49 +0000
Subject: [Ndn-interest] ndn question
In-Reply-To: <4AC03A6244C3C34BB52A7EC60B799C4C043E7B53@m-pdc.sbu.ac.ir>
References: <4AC03A6244C3C34BB52A7EC60B799C4C043E7B53@m-pdc.sbu.ac.ir>
Message-ID: <712FE4E7257849499414892DD92704BC77C656BC@INFRAEX02.oxia.corp>

Hello,

What I meant by my second question is to add a pub/sub extension to ndn, in fact the present policy in ndn is demand-response based, what if we wanted for some data flows to use a pub/sub policy
In other words allow to a consumer to subscribe once in a topic and then he will receive any data packet produced and corresponding to this topic?

It could be useful when I have an information that I want to retrieve periodically ! like electricity price for instance, I don?t want to send an interest in order to have data, but I want to subscribe once and then get electricity price each time there is a new one

Best regards

De : Muhammad Hosain Abdollahi Sabet [mailto:M.AbdollahiSabet at Mail.sbu.ac.ir]
Envoy? : mardi 26 avril 2016 08:33
? : Nour El Houda Ben Youssef; ndn-interest at lists.cs.ucla.edu
Objet : RE: [Ndn-interest] ndn question

Hi,

1- That is when NACK comes up! For example in DFZ(Default-free zone) when there is no entry(in CS,PIT or FIB), a NACK with some description will be sent back to the consumer.

2- Could you elaborate a bit more on "each time it is published"? Generally a Data packet cannot traverse nodes if already there is no interest for it.

Thanks,
Sabet

From: Ndn-interest [mailto:ndn-interest-bounces at lists.cs.ucla.edu] On Behalf Of Nour El Houda Ben Youssef
Sent: Thursday, April 21, 2016 3:51 PM
To: ndn-interest at lists.cs.ucla.edu<mailto:ndn-interest at lists.cs.ucla.edu>
Subject: [Ndn-interest] ndn question

Dear ndn users

I would like to ask what really happens when an ndn node receives an interest that he can?t satisfy (no corresponding content in its CS, no corresponding entry neither in its PIT nor in its FIB)
Does it drop it ?

Another question on extending ndn with pub/sub mechanism, in fact each time we need to retrieve a content we have to express an interest
What if I want to express the interest once and receive the corresponding content each time it is published?

Best regards



[logoslogan.png]

Nour El Houda BEN YOUSSEF|Doctorante
Technopark El Ghazela 2088 Tunis- Tunisia
Phone: +216 31 34 00 14
Mobile: +216 24 54 24 54
www.wevioo.com<http://www.wevioo.com>
Paris ? Tunis - Dubai ? Alger







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160427/b56f9a9d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 4997 bytes
Desc: image001.png
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160427/b56f9a9d/attachment.png>

From amin.hadipour.86 at gmail.com  Wed Apr 27 05:27:06 2016
From: amin.hadipour.86 at gmail.com (Amin Hadipour)
Date: Wed, 27 Apr 2016 16:57:06 +0430
Subject: [Ndn-interest] Mailing Mechanism in NDN
Message-ID: <CALyndyzF3HAsou5sxjrNTGzuiU0i3J_6SAXOUgy62rp9kj+YSw@mail.gmail.com>

Hi NDN-users


I want to know about receiving an email mechanism in the NDN architecture,
Because sometimes we should get an email from somebody that, we do not know
him and can not know when attempting to send.

what is the solution for this problem in NDN?

Best Regards
Amin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160427/6ff54e84/attachment.html>

From gaurav.barokar at gmail.com  Wed Apr 27 06:33:35 2016
From: gaurav.barokar at gmail.com (Gaurav Barokar)
Date: Wed, 27 Apr 2016 14:33:35 +0100
Subject: [Ndn-interest] NFD Android (WiFi Direct face)
Message-ID: <CABejKBrL7YnzCMk8oqU+Z9uLt0RAqMz9WG3jSueJ5OoH_+hGGQ@mail.gmail.com>

Dear all,


           Can we have the NFD Android with the WiFi Direct? As we all
know that NFD for Android works on WiFi, so it should be also work
with the WiFi Direct. If yes please provide the new version of NFD
Android with WiFi Direct face.
Thank you.


From M.AbdollahiSabet at mail.sbu.ac.ir  Wed Apr 27 09:55:37 2016
From: M.AbdollahiSabet at mail.sbu.ac.ir (Muhammad Hosain Abdollahi Sabet)
Date: Wed, 27 Apr 2016 21:25:37 +0430
Subject: [Ndn-interest] ndn question
References: <4AC03A6244C3C34BB52A7EC60B799C4C043E7B53@m-pdc.sbu.ac.ir>
	<712FE4E7257849499414892DD92704BC77C656BC@INFRAEX02.oxia.corp>
Message-ID: <4AC03A6244C3C34BB52A7EC60B799C4C03CC2A29@m-pdc.sbu.ac.ir>

Hi,

Well, right now there has been a discussion about hob by hop flow balance. But for the time being, I suggest you take a look at:
http://named-data.net/project/ndn-design-principles/
which is in contradiction with your point I guess.

By the way, for your use case, I think chronosync is well suited. 
http://named-data.net/publications/chronosync/
http://named-data.net/publications/story_of_chronoshare/

Thanks,
Sabet

-----Original Message-----
From: Nour El Houda Ben Youssef [mailto:NourElHouda.BenYoussef at wevioo.com]
Sent: Wed 4/27/2016 2:23 PM
To: Muhammad Hosain Abdollahi Sabet; ndn-interest at lists.cs.ucla.edu
Subject: RE: [Ndn-interest] ndn question
 
Hello,

What I meant by my second question is to add a pub/sub extension to ndn, in fact the present policy in ndn is demand-response based, what if we wanted for some data flows to use a pub/sub policy
In other words allow to a consumer to subscribe once in a topic and then he will receive any data packet produced and corresponding to this topic.

It could be useful when I have an information that I want to retrieve periodically ! like electricity price for instance, I don't want to send an interest in order to have data, but I want to subscribe once and then get electricity price each time there is a new one

Best regards

De : Muhammad Hosain Abdollahi Sabet [mailto:M.AbdollahiSabet at Mail.sbu.ac.ir]
Envoy? : mardi 26 avril 2016 08:33
? : Nour El Houda Ben Youssef; ndn-interest at lists.cs.ucla.edu
Objet : RE: [Ndn-interest] ndn question

Hi,

1- That is when NACK comes up! For example in DFZ(Default-free zone) when there is no entry(in CS,PIT or FIB), a NACK with some description will be sent back to the consumer.

2- Could you elaborate a bit more on "each time it is published"? Generally a Data packet cannot traverse nodes if already there is no interest for it.

Thanks,
Sabet

From: Ndn-interest [mailto:ndn-interest-bounces at lists.cs.ucla.edu] On Behalf Of Nour El Houda Ben Youssef
Sent: Thursday, April 21, 2016 3:51 PM
To: ndn-interest at lists.cs.ucla.edu<mailto:ndn-interest at lists.cs.ucla.edu>
Subject: [Ndn-interest] ndn question

Dear ndn users

I would like to ask what really happens when an ndn node receives an interest that he can't satisfy (no corresponding content in its CS, no corresponding entry neither in its PIT nor in its FIB)
Does it drop it ?

Another question on extending ndn with pub/sub mechanism, in fact each time we need to retrieve a content we have to express an interest
What if I want to express the interest once and receive the corresponding content each time it is published?

Best regards



[logoslogan.png]

Nour El Houda BEN YOUSSEF|Doctorante
Technopark El Ghazela 2088 Tunis- Tunisia
Phone: +216 31 34 00 14
Mobile: +216 24 54 24 54
www.wevioo.com<http://www.wevioo.com>
Paris - Tunis - Dubai - Alger








-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160427/5e11fc2b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 4997 bytes
Desc: image001.png
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160427/5e11fc2b/attachment.png>

From aa at CS.UCLA.EDU  Wed Apr 27 11:47:36 2016
From: aa at CS.UCLA.EDU (Alex Afanasyev)
Date: Wed, 27 Apr 2016 11:47:36 -0700
Subject: [Ndn-interest] NFD Android (WiFi Direct face)
In-Reply-To: <CABejKBrL7YnzCMk8oqU+Z9uLt0RAqMz9WG3jSueJ5OoH_+hGGQ@mail.gmail.com>
References: <CABejKBrL7YnzCMk8oqU+Z9uLt0RAqMz9WG3jSueJ5OoH_+hGGQ@mail.gmail.com>
Message-ID: <40F9BAA7-7432-463A-B75D-7D712317E91B@cs.ucla.edu>

Dear Gaurav,

Of course you can use NFD-Android with the WiFi Direct.  Unfortunately, it is not yet a built-in functionality of the NFD application, but can be added in your application (if you are interested in helping us with it, we will be happy to merge your code).  You can check out one pilot application that uses WiFi direct to share photos using NDN (https://github.com/ohnonoho/photoSharing).

Sincerely,
Alex

> On Apr 27, 2016, at 6:33 AM, Gaurav Barokar <gaurav.barokar at gmail.com> wrote:
> 
> Dear all,
> 
> 
>           Can we have the NFD Android with the WiFi Direct? As we all
> know that NFD for Android works on WiFi, so it should be also work
> with the WiFi Direct. If yes please provide the new version of NFD
> Android with WiFi Direct face.
> Thank you.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160427/3c1b739b/attachment.bin>