From jburke at remap.UCLA.EDU  Wed Apr  1 08:38:26 2015
From: jburke at remap.UCLA.EDU (Burke, Jeff)
Date: Wed, 1 Apr 2015 15:38:26 +0000
Subject: [Nfd-dev] Handling new content in app for pending interest in
 NFD
In-Reply-To: <6cae5fe4-c081-44da-ad7c-17b311ca2ccc@parc.com>
Message-ID: <D1415A38.1C9BA2%jburke@remap.ucla.edu>


Thanks for all of the discussion. I am not sure if I have been able to extract an answer to the original question I was asking.  Let me try again with more information:

- The original question was intended to be only about a local NFD (for now).
- The use case is a (soft) real-time application, like videoconferencing or streaming sensor data for interactive applications. Specifically, we have encountered the issue in 1) ndnrtc/ndncon<https://github.com/remap/ndncon/> for videoconferencing and 2) ndn-opt, which streams data from OpenPTrack<http://openptrack.org/>, a person tracking system built on the robot operating system (ROS).

- In these use cases, consumers want to receive data with low latency, so they send interests intended to arrive before the time the data is produced, but not so long before that the Interests expire before corresponding data is produced.

- As they are born, samples are signed and put into a repository by the publisher.  Currently these apps use an in-memory repo specific to the application, via the MemoryContentCache class provided by the NDN-CCL library. But this could just as well be a repo outside the application.

- So, when Interests arrive, they go in the local  NFD's PIT, and are forwarded to the application.   We are interested in the case where the data is not born yet, so the publisher cannot respond to the Interest.

- Then, before the Interest expires from the local NFD's PIT, the corresponding data is born in the application and should be used to answer the Interest.  But how does that data get back to the local forwarder?

- What should the application do?  1) Maintain its own PIT?   2) Or, push the data to the local NFD, letting it drop it if it doesn't satisfy anything.  3) Or, as we have previously discussed about the MemoryContentCache, do we need to consider a more sophisticated interaction model between the application and the daemon's content store and/or PIT that reduces duplication of these capabilities in applications?

- For now, we have implemented an in-application PIT in ndnrtc.  (I am not sure what method we ended up using in ndn-opt, perhaps the unsolicited data method.)

- Discussion on this topic will help inform what library support will be provided in the short term.  (I don't think we want every application author to have to write a PIT, so am thinking in the short term we should provide one to complement the MemoryContentCache class.  But this is duplicating data structures and functionality in NFD ? is that natural, or should we look to handle it through a different interaction with the local forwarder?)

Thanks,
Jeff


From: <Ignacio.Solis at parc.com<mailto:Ignacio.Solis at parc.com>>
Date: Tue, 31 Mar 2015 00:06:33 +0000
To: <wentaoshang at gmail.com<mailto:wentaoshang at gmail.com>>, <Marc.Mosko at parc.com<mailto:Marc.Mosko at parc.com>>
Cc: <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: Re: [Nfd-dev] Handling new content in app for pending interest in NFD

I'm going to guess that caching data rules will be the same as forwarding rules. If the interface is not allowed to produce that content (due to routing / fib entries, local naming policy) data should not be forwarded OR cached.

NDN has a slightly more complicated problem with caching than CCN given then LPM matching rules.

If you have a repo that has permission to serve this content then you changed the problem. Now you need the repo protocol to give you trust.

For regular forwarding you are relying on trusting routing. For local apps you will rely (I assume)  on local permissions. For repo you will need both of those plus now a repo permission  protocol.

Dropping unsolicited data may end up being your only recourse.

There are obviously other approaches for pre-populating caches that involve higher level protocols, but I assume that's not what you're talking about.

Nacho (Ignacio) Solis
Principal Scientist
Palo Alto Research Center

From: Wentao Shang <wentaoshang at gmail.com<mailto:wentaoshang at gmail.com>>
Sent: Mar 30, 2015 4:50 PM
To: "Solis, Ignacio <Ignacio.Solis at parc.com<mailto:Ignacio.Solis at parc.com>>" <Ignacio.Solis at parc.com<mailto:Ignacio.Solis at parc.com>>;Mosko, Marc <Marc.Mosko at parc.com<mailto:Marc.Mosko at parc.com>>
Cc: nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>
Subject: Re: [Nfd-dev] Handling new content in app for pending interest in NFD

Hi Nacho,

I don't have any argument against this rule right now. But it seems more relevant to "forwarding" data packets, while the problem we were discussing is about "caching" unsolicited data packets, which cannot be forwarded anyway because there is no PIT. The simplest solution I would suggest to the problem is to drop any unsolicited data in the forwarder.

Wentao

On Mon, Mar 30, 2015 at 3:42 PM <Ignacio.Solis at parc.com<mailto:Ignacio.Solis at parc.com>> wrote:
This rule is important, router or not. You can't have "non-priviledged"  applications generating replies at servers. Specially important at systems with multiple users,  tenants, virtual systems.

At the local router there are even more restrictions.  We haven't even gotten to talking about privileged names and restrictions and end-h out behavior.   We have a design  for this for CCN that we'll be talking about at CCNxCon.

Nacho (Ignacio) Solis
Principal Scientist
Palo Alto Research Center

From: Wentao Shang <wentaoshang at gmail.com<mailto:wentaoshang at gmail.com>>
Sent: Mar 30, 2015 1:07 PM
To: Mosko, Marc <Marc.Mosko at parc.com<mailto:Marc.Mosko at parc.com>>

Cc: nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>
Subject: Re: [Nfd-dev] Handling new content in app for pending interest in NFD

On Mon, Mar 30, 2015 at 12:52 PM <Marc.Mosko at parc.com<mailto:Marc.Mosko at parc.com>> wrote:
I?ll add that in addition to the content having a PIT entry, Nacho Solis has suggested that a router should verify that a Content Object came in a face from which it was requested.  Otherwise, there?s a potential for off-path attacks sending content objects that match popular well-known names.  A variation on that, rather than tracking forward paths, would be to at minimum verify that a content object comes from a face for which there?s a corresponding FIB entry for the name.

This requirement makes sense for transit routers that receive packets from other routers. But I'm not sure whether this is necessary for forwarding daemons handling local applications... The pushed data should never get out of the local forwarder unless there is a PIT entry specifying a path pointing to some other router.

Wentao


Marc

On Mar 30, 2015, at 12:08 PM, Wentao Shang <wentaoshang at gmail.com<mailto:wentaoshang at gmail.com>> wrote:

I agree with Dave.

In principle, router should not cache unsolicited data. In the situation we are discussing, the application should either just push the data out, which may be dropped by NFD if the interest has expired, or store the data in some application-level cache (or repo) for future fetching.

Wentao

On Mon, Mar 30, 2015 at 11:52 AM Dave Oran (oran) <oran at cisco.com<mailto:oran at cisco.com>> wrote:
Isn?t this what the repo was invented for?

Holding packets in a router that has forgotten that they were asked for is a giant invitation to cache pollution/poisoning attacks.

> On Mar 30, 2015, at 2:24 PM, Haowei Yuan <hyuan at wustl.edu<mailto:hyuan at wustl.edu>> wrote:
>
> I think as long as the data has actually been requested by an Interest
> packet, it is safe to send the Data packet to NFD. The NFD will either
> forward or drop the Data packet by checking if the Interest has
> expired.
>
> If the Interest has expired, Data packet is dropped, and the consumer
> is still interested in the data, the consumer could resend the
> Interest. Hopefully this time, the Data packet can be generated and
> sent faster by the application so that NFD will forward it.
>
> Haowei
>
>
> On Mon, Mar 30, 2015 at 1:12 PM, Anil Jangam <anilj.mailing at gmail.com<mailto:anilj.mailing at gmail.com>> wrote:
>>
>> On Mar 30, 2015 11:08 AM, "Dehart, John" <jdd at wustl.edu<mailto:jdd at wustl.edu>> wrote:
>>>
>>>
>>> Is there any harm in it pushing the data out without knowing for sure if
>>> the
>>> Interest is still active?
>>>
>> If data is so critical, can the Interest be refreshed proactively before it
>> expires?
>>
>> /anil
>>
>>> John
>>>
>>>> On Mar 30, 2015, at 1:05 PM, Burke, Jeff <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>> wrote:
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>> On Mon, Mar 30, 2015 at 10:28 AM Burke, Jeff <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> Hi folks,
>>>>>>
>>>>>> We are facing this scenario in a few applications:
>>>>>>
>>>>>> 1) Interest received by NFD, passed to an application
>>>>>> 2) Application not able to respond to interest, so interest stays in
>>>>>> NFD PIT
>>>>>> 3) Some time passes, but not enough for the Interest to expire
>>>>>> 4) Application generates data (e.g., from a sensor reading) that would
>>>>>> answer the Interest in the NFD PIT
>>>>>>
>>>>>> Question: How does app know to inform NFD it has the data after step 4,
>>>>>> and how should it do that?
>>>>>>
>>>>>> - In this type of app, should it push the data unsolicited to the NFD
>>>>>> and let it decide if there is something to do?
>>>>>
>>>>>
>>>>> In my opinion, as long as the application is certain that the Interest
>>>>> has arrived and is stored in NFD's PIT, it can just push the data out to
>>>>> NFD.
>>>>
>>>>
>>>>
>>>> How certain does it have to be?  There is a chance it could have
>>>> expired...
>>>> jeff
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>> Wentao
>>>>>
>>>>>>
>>>>>> - Is it recommended to implement an application-level PIT so the app is
>>>>>> sure this data is solicited?  (Why add another PIT?)
>>>>>>
>>>>>> Thank you,
>>>>>> Jeff
>>>>>>
>>>>>> _______________________________________________
>>>>>> Nfd-dev mailing list
>>>>>> Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
>>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>>>
>>>> _______________________________________________
>>>> Nfd-dev mailing list
>>>> Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> Nfd-dev mailing list
>>> Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev


_______________________________________________
Nfd-dev mailing list
Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
_______________________________________________
Nfd-dev mailing list
Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

_______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150401/a697d691/attachment.html>

From wentaoshang at gmail.com  Wed Apr  1 09:59:59 2015
From: wentaoshang at gmail.com (Wentao Shang)
Date: Wed, 01 Apr 2015 16:59:59 +0000
Subject: [Nfd-dev] Handling new content in app for pending interest in
	NFD
In-Reply-To: <D1415A38.1C9BA2%jburke@remap.ucla.edu>
References: <6cae5fe4-c081-44da-ad7c-17b311ca2ccc@parc.com>
	<D1415A38.1C9BA2%jburke@remap.ucla.edu>
Message-ID: <CAD4s1gQ2i3i48sNE3aDoqTHup7y_zV_WvWOzCVaUHC=OKCCEUQ@mail.gmail.com>

I think this problem shows one limitation of in-memory cache (and repo in
general). The cache/repo is a "passive" storage: once the data gets in, it
never gets out unless someone explicitly request it. The applications, on
the other hand, can be more "active" in deciding when to send out data in
response to previous interests.

I remember Illya and Lijing's ndnvideo implementation also needs to handle
similar problem. Their current solution (as far as I understand) is to push
out the data twice: once to the NFD for satisfying request, once to the
repo for archiving. The second push uses repo insertion command so it's not
just a plain data packet (like in the first push).

Wentao

On Wed, Apr 1, 2015 at 8:38 AM Burke, Jeff <jburke at remap.ucla.edu> wrote:

>
>  Thanks for all of the discussion. I am not sure if I have been able to
> extract an answer to the original question I was asking.  Let me try again
> with more information:
>
>  - The original question was intended to be only about a local NFD (for
> now).
>  - The use case is a (soft) real-time application, like videoconferencing
> or streaming sensor data for interactive applications. Specifically, we
> have encountered the issue in 1) ndnrtc/ndncon
> <https://github.com/remap/ndncon/> for videoconferencing and 2) ndn-opt,
> which streams data from OpenPTrack <http://openptrack.org/>, a person
> tracking system built on the robot operating system (ROS).
>
>  - In these use cases, consumers want to receive data with low latency,
> so they send interests intended to arrive before the time the data is
> produced, but not so long before that the Interests expire before
> corresponding data is produced.
>
>  - As they are born, samples are signed and put into a repository by the
> publisher.  Currently these apps use an in-memory repo specific to the
> application, via the MemoryContentCache class provided by the NDN-CCL
> library. But this could just as well be a repo outside the application.
>
>  - So, when Interests arrive, they go in the local  NFD's PIT, and are
> forwarded to the application.   We are interested in the case where the
> data is not born *yet*, so the publisher cannot respond to the Interest.
>
>  - Then, before the Interest expires from the local NFD's PIT, the
> corresponding data is born in the application and *should* be used to
> answer the Interest.  But how does that data get back to the local
> forwarder?
>
>  - What should the application do?  1) Maintain its own PIT?   2) Or,
> push the data to the local NFD, letting it drop it if it doesn't satisfy
> anything.  3) Or, as we have previously discussed about the
> MemoryContentCache, do we need to consider a more sophisticated interaction
> model between the application and the daemon's content store and/or PIT
> that reduces duplication of these capabilities in applications?
>
>  - For now, we have implemented an in-application PIT in ndnrtc.  (I am
> not sure what method we ended up using in ndn-opt, perhaps the unsolicited
> data method.)
>
>  - Discussion on this topic will help inform what library support will be
> provided in the short term.  (I don't think we want every application
> author to have to write a PIT, so am thinking in the short term we should
> provide one to complement the MemoryContentCache class.  But this is
> duplicating data structures and functionality in NFD ? is that natural, or
> should we look to handle it through a different interaction with the local
> forwarder?)
>
>  Thanks,
> Jeff
>
>
>   From: <Ignacio.Solis at parc.com>
> Date: Tue, 31 Mar 2015 00:06:33 +0000
> To: <wentaoshang at gmail.com>, <Marc.Mosko at parc.com>
>
> Cc: <nfd-dev at lists.cs.ucla.edu>
> Subject: Re: [Nfd-dev] Handling new content in app for pending interest
> in NFD
>
>    I'm going to guess that caching data rules will be the same as
> forwarding rules. If the interface is not allowed to produce that content
> (due to routing / fib entries, local naming policy) data should not be
> forwarded OR cached.
>
>  NDN has a slightly more complicated problem with caching than CCN given
> then LPM matching rules.
>
>  If you have a repo that has permission to serve this content then you
> changed the problem. Now you need the repo protocol to give you trust.
>
>  For regular forwarding you are relying on trusting routing. For local
> apps you will rely (I assume)  on local permissions. For repo you will need
> both of those plus now a repo permission  protocol.
>
>  Dropping unsolicited data may end up being your only recourse.
>
>  There are obviously other approaches for pre-populating caches that
> involve higher level protocols, but I assume that's not what you're talking
> about.
>
>  Nacho (Ignacio) Solis
> Principal Scientist
> Palo Alto Research Center
>
>  *From:* Wentao Shang <wentaoshang at gmail.com>
> *Sent:* Mar 30, 2015 4:50 PM
> *To:* "Solis, Ignacio <Ignacio.Solis at parc.com>" <Ignacio.Solis at parc.com>;Mosko,
> Marc <Marc.Mosko at parc.com>
> *Cc:* nfd-dev at lists.cs.ucla.edu
> *Subject:* Re: [Nfd-dev] Handling new content in app for pending interest
> in NFD
>
>  Hi Nacho,
>
>  I don't have any argument against this rule right now. But it seems more
> relevant to "forwarding" data packets, while the problem we were discussing
> is about "caching" unsolicited data packets, which cannot be forwarded
> anyway because there is no PIT. The simplest solution I would suggest to
> the problem is to drop any unsolicited data in the forwarder.
>
>  Wentao
>
> On Mon, Mar 30, 2015 at 3:42 PM <Ignacio.Solis at parc.com> wrote:
>
>>  This rule is important, router or not. You can't have "non-priviledged"
>>  applications generating replies at servers. Specially important at systems
>> with multiple users,  tenants, virtual systems.
>>
>>  At the local router there are even more restrictions.  We haven't even
>> gotten to talking about privileged names and restrictions and end-h out
>> behavior.   We have a design  for this for CCN that we'll be talking about
>> at CCNxCon.
>>
>>  Nacho (Ignacio) Solis
>> Principal Scientist
>> Palo Alto Research Center
>>
>>  *From:* Wentao Shang <wentaoshang at gmail.com>
>> *Sent:* Mar 30, 2015 1:07 PM
>> *To:* Mosko, Marc <Marc.Mosko at parc.com>
>>
>> *Cc:* nfd-dev at lists.cs.ucla.edu
>> *Subject:* Re: [Nfd-dev] Handling new content in app for pending
>> interest in NFD
>>
>> On Mon, Mar 30, 2015 at 12:52 PM <Marc.Mosko at parc.com> wrote:
>>
>>> I?ll add that in addition to the content having a PIT entry, Nacho Solis
>>> has suggested that a router should verify that a Content Object came in a
>>> face from which it was requested.  Otherwise, there?s a potential for
>>> off-path attacks sending content objects that match popular well-known
>>> names.  A variation on that, rather than tracking forward paths, would be
>>> to at minimum verify that a content object comes from a face for which
>>> there?s a corresponding FIB entry for the name.
>>>
>>
>>  This requirement makes sense for transit routers that receive packets
>> from other routers. But I'm not sure whether this is necessary for
>> forwarding daemons handling local applications... The pushed data should
>> never get out of the local forwarder unless there is a PIT entry specifying
>> a path pointing to some other router.
>>
>>  Wentao
>>
>>
>>>
>>>  Marc
>>>
>>>  On Mar 30, 2015, at 12:08 PM, Wentao Shang <wentaoshang at gmail.com>
>>> wrote:
>>>
>>>  I agree with Dave.
>>>
>>>  In principle, router should not cache unsolicited data. In the
>>> situation we are discussing, the application should either just push the
>>> data out, which may be dropped by NFD if the interest has expired, or store
>>> the data in some application-level cache (or repo) for future fetching.
>>>
>>>  Wentao
>>>
>>> On Mon, Mar 30, 2015 at 11:52 AM Dave Oran (oran) <oran at cisco.com>
>>> wrote:
>>>
>>>> Isn?t this what the repo was invented for?
>>>>
>>>> Holding packets in a router that has forgotten that they were asked for
>>>> is a giant invitation to cache pollution/poisoning attacks.
>>>>
>>>> > On Mar 30, 2015, at 2:24 PM, Haowei Yuan <hyuan at wustl.edu> wrote:
>>>> >
>>>> > I think as long as the data has actually been requested by an Interest
>>>> > packet, it is safe to send the Data packet to NFD. The NFD will either
>>>> > forward or drop the Data packet by checking if the Interest has
>>>> > expired.
>>>> >
>>>> > If the Interest has expired, Data packet is dropped, and the consumer
>>>> > is still interested in the data, the consumer could resend the
>>>> > Interest. Hopefully this time, the Data packet can be generated and
>>>> > sent faster by the application so that NFD will forward it.
>>>> >
>>>> > Haowei
>>>> >
>>>> >
>>>> > On Mon, Mar 30, 2015 at 1:12 PM, Anil Jangam <anilj.mailing at gmail.com>
>>>> wrote:
>>>> >>
>>>> >> On Mar 30, 2015 11:08 AM, "Dehart, John" <jdd at wustl.edu> wrote:
>>>> >>>
>>>> >>>
>>>> >>> Is there any harm in it pushing the data out without knowing for
>>>> sure if
>>>> >>> the
>>>> >>> Interest is still active?
>>>> >>>
>>>> >> If data is so critical, can the Interest be refreshed proactively
>>>> before it
>>>> >> expires?
>>>> >>
>>>> >> /anil
>>>> >>
>>>> >>> John
>>>> >>>
>>>> >>>> On Mar 30, 2015, at 1:05 PM, Burke, Jeff <jburke at remap.ucla.edu>
>>>> wrote:
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>>>
>>>> >>>>>
>>>> >>>>> On Mon, Mar 30, 2015 at 10:28 AM Burke, Jeff <
>>>> jburke at remap.ucla.edu>
>>>> >>>>> wrote:
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>> Hi folks,
>>>> >>>>>>
>>>> >>>>>> We are facing this scenario in a few applications:
>>>> >>>>>>
>>>> >>>>>> 1) Interest received by NFD, passed to an application
>>>> >>>>>> 2) Application not able to respond to interest, so interest
>>>> stays in
>>>> >>>>>> NFD PIT
>>>> >>>>>> 3) Some time passes, but not enough for the Interest to expire
>>>> >>>>>> 4) Application generates data (e.g., from a sensor reading) that
>>>> would
>>>> >>>>>> answer the Interest in the NFD PIT
>>>> >>>>>>
>>>> >>>>>> Question: How does app know to inform NFD it has the data after
>>>> step 4,
>>>> >>>>>> and how should it do that?
>>>> >>>>>>
>>>> >>>>>> - In this type of app, should it push the data unsolicited to
>>>> the NFD
>>>> >>>>>> and let it decide if there is something to do?
>>>> >>>>>
>>>> >>>>>
>>>> >>>>> In my opinion, as long as the application is certain that the
>>>> Interest
>>>> >>>>> has arrived and is stored in NFD's PIT, it can just push the data
>>>> out to
>>>> >>>>> NFD.
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>> How certain does it have to be?  There is a chance it could have
>>>> >>>> expired...
>>>> >>>> jeff
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>>>
>>>> >>>>> Wentao
>>>> >>>>>
>>>> >>>>>>
>>>> >>>>>> - Is it recommended to implement an application-level PIT so the
>>>> app is
>>>> >>>>>> sure this data is solicited?  (Why add another PIT?)
>>>> >>>>>>
>>>> >>>>>> Thank you,
>>>> >>>>>> Jeff
>>>> >>>>>>
>>>> >>>>>> _______________________________________________
>>>> >>>>>> Nfd-dev mailing list
>>>> >>>>>> Nfd-dev at lists.cs.ucla.edu
>>>> >>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>>> >>>>
>>>> >>>> _______________________________________________
>>>> >>>> Nfd-dev mailing list
>>>> >>>> Nfd-dev at lists.cs.ucla.edu
>>>> >>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>> _______________________________________________
>>>> >>> Nfd-dev mailing list
>>>> >>> Nfd-dev at lists.cs.ucla.edu
>>>> >>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>>> >>>
>>>> > _______________________________________________
>>>> > Nfd-dev mailing list
>>>> > Nfd-dev at lists.cs.ucla.edu
>>>> > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> Nfd-dev mailing list
>>>> Nfd-dev at lists.cs.ucla.edu
>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>>>
>>>   _______________________________________________
>>> Nfd-dev mailing list
>>> Nfd-dev at lists.cs.ucla.edu
>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>>
>>>
>>>        _______________________________________________ Nfd-dev mailing
> list Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>  _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150401/2a14804e/attachment.html>

From shijunxiao at email.arizona.edu  Wed Apr  1 10:21:02 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Wed, 1 Apr 2015 10:21:02 -0700
Subject: [Nfd-dev] Handling new content in app for pending interest in
	NFD
In-Reply-To: <D13ED5BB.1C7F93%jburke@remap.ucla.edu>
References: <D13ED5BB.1C7F93%jburke@remap.ucla.edu>
Message-ID: <CAOFH+OZTwq13rYW137s86BaLog5uP_wCtpc4UwRZ6C_CHYORrw@mail.gmail.com>

Hi Jeff

The recommendation for "soft realtime app" is given below.
Please note that some features are not yet implemented, but the
specifications are already approved.
Watch each listed feature for implementation progress.


The *forwarder MUST NOT cache unsolicited Data*, regardless of its origin.
Feature: http://redmine.named-data.net/issues/2181
Announcement:
http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2014-November/000605.html

A soft realtime app MUST maintain an *in-memory storage*.
It MUST NOT rely on the forwarder to cache its Data, even if they are sent
to the forwarder in response to an unexpired Interest.
The data structure is referred to as "in-memory storage" rather than
"cache", because it SHOULD be fully managed by the app to keep all Data
that the app wants to serve. It's not a cache where useful Data can be
evicted.
Reason: the forwarder is free to evict any Data.

A soft realtime app SHOULD set *CachingPolicy=NoCache* in
LocalControlHeader (or NDNLPv2 header) on a Data served from an in-memory
storage.
The local forwarder ContentStore SHOULD NOT cache a Data with
CachingPolicy=NoCache.
CachingPolicy field is not carried to remote forwarders, so that remote
forwarders can still cache the Data. It avoids duplicate Data copies on
localhost.
Protocol:
http://redmine.named-data.net/projects/nfd/wiki/LocalControlHeader#CachingPolicy-feature
Feature: http://redmine.named-data.net/issues/2183
http://redmine.named-data.net/issues/2185
http://redmine.named-data.net/issues/2184

A soft realtime app MAY maintain its PIT to *avoid sending unsolicited Data*
.
When an app chooses not to maintain a PIT, sending unsolicited Data has no
harmful effect.



Yours, Junxiao

On Wed, Apr 1, 2015 at 8:38 AM, Burke, Jeff <jburke at remap.ucla.edu> wrote:

>
> Thanks for all of the discussion. I am not sure if I have been able to
> extract an answer to the original question I was asking.  Let me try again
> with more information:
>
> - The original question was intended to be only about a local NFD (for
> now).
> - The use case is a (soft) real-time application, like videoconferencing
> or streaming sensor data for interactive applications. Specifically, we
> have encountered the issue in 1) ndnrtc/ndncon
> <https://github.com/remap/ndncon/> for videoconferencing and 2) ndn-opt,
> which streams data from OpenPTrack <http://openptrack.org/>, a person
> tracking system built on the robot operating system (ROS).
>
> - In these use cases, consumers want to receive data with low latency, so
> they send interests intended to arrive before the time the data is
> produced, but not so long before that the Interests expire before
> corresponding data is produced.
>
> - As they are born, samples are signed and put into a repository by the
> publisher.  Currently these apps use an in-memory repo specific to the
> application, via the MemoryContentCache class provided by the NDN-CCL
> library. But this could just as well be a repo outside the application.
>
> - So, when Interests arrive, they go in the local  NFD's PIT, and are
> forwarded to the application.   We are interested in the case where the
> data is not born *yet*, so the publisher cannot respond to the Interest.
>
> - Then, before the Interest expires from the local NFD's PIT, the
> corresponding data is born in the application and *should* be used to
> answer the Interest.  But how does that data get back to the local
> forwarder?
>
> - What should the application do?  1) Maintain its own PIT?   2) Or, push
> the data to the local NFD, letting it drop it if it doesn't satisfy
> anything.  3) Or, as we have previously discussed about the
> MemoryContentCache, do we need to consider a more sophisticated interaction
> model between the application and the daemon's content store and/or PIT
> that reduces duplication of these capabilities in applications?
>
> - For now, we have implemented an in-application PIT in ndnrtc.  (I am not
> sure what method we ended up using in ndn-opt, perhaps the unsolicited data
> method.)
>
> - Discussion on this topic will help inform what library support will be
> provided in the short term.  (I don't think we want every application
> author to have to write a PIT, so am thinking in the short term we should
> provide one to complement the MemoryContentCache class.  But this is
> duplicating data structures and functionality in NFD ? is that natural, or
> should we look to handle it through a different interaction with the local
> forwarder?)
>
> Thanks,
> Jeff
>
> On Mon, Mar 30, 2015 at 10:28 AM, Burke, Jeff <jburke at remap.ucla.edu>
wrote:

>
>  Hi folks,
>
>  We are facing this scenario in a few applications:
>
>  1) Interest received by NFD, passed to an application
> 2) Application not able to respond to interest, so interest stays in NFD
> PIT
> 3) Some time passes, but not enough for the Interest to expire
> 4) Application generates data (e.g., from a sensor reading) that would
> answer the Interest in the NFD PIT
>
>  Question: How does app know to inform NFD it has the data after step 4,
> and how should it do that?
>
>  - In this type of app, should it push the data unsolicited to the NFD
> and let it decide if there is something to do?
> - Is it recommended to implement an application-level PIT so the app is
> sure this data is solicited?  (Why add *another* PIT?)
>
>  Thank you,
> Jeff
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150401/a48cd5b5/attachment.html>

From oran at cisco.com  Wed Apr  1 10:21:26 2015
From: oran at cisco.com (Dave Oran (oran))
Date: Wed, 1 Apr 2015 17:21:26 +0000
Subject: [Nfd-dev] Handling new content in app for pending interest
	in	NFD
In-Reply-To: <CAD4s1gQ2i3i48sNE3aDoqTHup7y_zV_WvWOzCVaUHC=OKCCEUQ@mail.gmail.com>
References: <6cae5fe4-c081-44da-ad7c-17b311ca2ccc@parc.com>
	<D1415A38.1C9BA2%jburke@remap.ucla.edu>
	<CAD4s1gQ2i3i48sNE3aDoqTHup7y_zV_WvWOzCVaUHC=OKCCEUQ@mail.gmail.com>
Message-ID: <D4A62838-0237-4FEC-B0B1-EA33AD0A5D2F@cisco.com>


> On Apr 1, 2015, at 12:59 PM, Wentao Shang <wentaoshang at gmail.com> wrote:
> 
> I think this problem shows one limitation of in-memory cache (and repo in general). The cache/repo is a "passive" storage: once the data gets in, it never gets out unless someone explicitly request it.
And why is that not exactly what you want? A place that can respond to interests without interrupting or otherwise causing thread scheduling problems for an application generating data open-loop.

The repo is protected from infinite growth by the expiration time of the data. 

> The applications, on the other hand, can be more "active" in deciding when to send out data in response to previous interests.
> 
You;ll have to explain why this is a good thing? Can the application smooth jitter this way? Maybe. What other benefits might accrue?

> I remember Illya and Lijing's ndnvideo implementation also needs to handle similar problem. Their current solution (as far as I understand) is to push out the data twice: once to the NFD for satisfying request, once to the repo for archiving. The second push uses repo insertion command so it's not just a plain data packet (like in the first push).
> 
Why not put everything into the repo and let the Repo respond to all interests? Is it the cost of context switches?

Is it because the architectural model of the repo is that it had to have non-volatile backing store to survive host crashes which might be irrelevant for pure realtime applications (i.e. you don?t care about recordings).


> Wentao
> 
> On Wed, Apr 1, 2015 at 8:38 AM Burke, Jeff <jburke at remap.ucla.edu> wrote:
> 
> Thanks for all of the discussion. I am not sure if I have been able to extract an answer to the original question I was asking.  Let me try again with more information:
> 
> - The original question was intended to be only about a local NFD (for now).
> - The use case is a (soft) real-time application, like videoconferencing or streaming sensor data for interactive applications. Specifically, we have encountered the issue in 1) ndnrtc/ndncon for videoconferencing and 2) ndn-opt, which streams data from OpenPTrack, a person tracking system built on the robot operating system (ROS). 
> 
> - In these use cases, consumers want to receive data with low latency, so they send interests intended to arrive before the time the data is produced, but not so long before that the Interests expire before corresponding data is produced. 
> 
> - As they are born, samples are signed and put into a repository by the publisher.  Currently these apps use an in-memory repo specific to the application, via the MemoryContentCache class provided by the NDN-CCL library. But this could just as well be a repo outside the application.
> 
> - So, when Interests arrive, they go in the local  NFD's PIT, and are forwarded to the application.   We are interested in the case where the data is not born yet, so the publisher cannot respond to the Interest.
> 
> - Then, before the Interest expires from the local NFD's PIT, the corresponding data is born in the application and should be used to answer the Interest.  But how does that data get back to the local forwarder? 
> 
> - What should the application do?  1) Maintain its own PIT?   2) Or, push the data to the local NFD, letting it drop it if it doesn't satisfy anything.  3) Or, as we have previously discussed about the MemoryContentCache, do we need to consider a more sophisticated interaction model between the application and the daemon's content store and/or PIT that reduces duplication of these capabilities in applications?   
> 
> - For now, we have implemented an in-application PIT in ndnrtc.  (I am not sure what method we ended up using in ndn-opt, perhaps the unsolicited data method.) 
> 
> - Discussion on this topic will help inform what library support will be provided in the short term.  (I don't think we want every application author to have to write a PIT, so am thinking in the short term we should provide one to complement the MemoryContentCache class.  But this is duplicating data structures and functionality in NFD ? is that natural, or should we look to handle it through a different interaction with the local forwarder?) 
> 
> Thanks,
> Jeff
> 
> 
> From: <Ignacio.Solis at parc.com>
> Date: Tue, 31 Mar 2015 00:06:33 +0000
> To: <wentaoshang at gmail.com>, <Marc.Mosko at parc.com>
> 
> Cc: <nfd-dev at lists.cs.ucla.edu>
> Subject: Re: [Nfd-dev] Handling new content in app for pending interest in NFD
> 
> I'm going to guess that caching data rules will be the same as forwarding rules. If the interface is not allowed to produce that content (due to routing / fib entries, local naming policy) data should not be forwarded OR cached. 
> 
> NDN has a slightly more complicated problem with caching than CCN given then LPM matching rules. 
> 
> If you have a repo that has permission to serve this content then you changed the problem. Now you need the repo protocol to give you trust. 
> 
> For regular forwarding you are relying on trusting routing. For local apps you will rely (I assume)  on local permissions. For repo you will need both of those plus now a repo permission  protocol. 
> 
> Dropping unsolicited data may end up being your only recourse. 
> 
> There are obviously other approaches for pre-populating caches that involve higher level protocols, but I assume that's not what you're talking about. 
> 
> Nacho (Ignacio) Solis
> Principal Scientist
> Palo Alto Research Center 
> 
> From: Wentao Shang <wentaoshang at gmail.com>
> Sent: Mar 30, 2015 4:50 PM
> To: "Solis, Ignacio <Ignacio.Solis at parc.com>" <Ignacio.Solis at parc.com>;Mosko, Marc <Marc.Mosko at parc.com>
> Cc: nfd-dev at lists.cs.ucla.edu
> Subject: Re: [Nfd-dev] Handling new content in app for pending interest in NFD
> 
> Hi Nacho,
> 
> I don't have any argument against this rule right now. But it seems more relevant to "forwarding" data packets, while the problem we were discussing is about "caching" unsolicited data packets, which cannot be forwarded anyway because there is no PIT. The simplest solution I would suggest to the problem is to drop any unsolicited data in the forwarder.
> 
> Wentao
> 
> On Mon, Mar 30, 2015 at 3:42 PM <Ignacio.Solis at parc.com> wrote:
> This rule is important, router or not. You can't have "non-priviledged"  applications generating replies at servers. Specially important at systems with multiple users,  tenants, virtual systems. 
> 
> At the local router there are even more restrictions.  We haven't even gotten to talking about privileged names and restrictions and end-h out behavior.   We have a design  for this for CCN that we'll be talking about at CCNxCon. 
> 
> Nacho (Ignacio) Solis
> Principal Scientist
> Palo Alto Research Center 
> 
> From: Wentao Shang <wentaoshang at gmail.com>
> Sent: Mar 30, 2015 1:07 PM
> To: Mosko, Marc <Marc.Mosko at parc.com>
> 
> Cc: nfd-dev at lists.cs.ucla.edu
> Subject: Re: [Nfd-dev] Handling new content in app for pending interest in NFD
> 
> On Mon, Mar 30, 2015 at 12:52 PM <Marc.Mosko at parc.com> wrote:
> I?ll add that in addition to the content having a PIT entry, Nacho Solis has suggested that a router should verify that a Content Object came in a face from which it was requested.  Otherwise, there?s a potential for off-path attacks sending content objects that match popular well-known names.  A variation on that, rather than tracking forward paths, would be to at minimum verify that a content object comes from a face for which there?s a corresponding FIB entry for the name.
> 
> This requirement makes sense for transit routers that receive packets from other routers. But I'm not sure whether this is necessary for forwarding daemons handling local applications... The pushed data should never get out of the local forwarder unless there is a PIT entry specifying a path pointing to some other router.
> 
> Wentao
>  
> 
> Marc
> 
> On Mar 30, 2015, at 12:08 PM, Wentao Shang <wentaoshang at gmail.com> wrote:
> 
>> I agree with Dave.
>> 
>> In principle, router should not cache unsolicited data. In the situation we are discussing, the application should either just push the data out, which may be dropped by NFD if the interest has expired, or store the data in some application-level cache (or repo) for future fetching.
>> 
>> Wentao
>> 
>> On Mon, Mar 30, 2015 at 11:52 AM Dave Oran (oran) <oran at cisco.com> wrote:
>> Isn?t this what the repo was invented for?
>> 
>> Holding packets in a router that has forgotten that they were asked for is a giant invitation to cache pollution/poisoning attacks.
>> 
>> > On Mar 30, 2015, at 2:24 PM, Haowei Yuan <hyuan at wustl.edu> wrote:
>> >
>> > I think as long as the data has actually been requested by an Interest
>> > packet, it is safe to send the Data packet to NFD. The NFD will either
>> > forward or drop the Data packet by checking if the Interest has
>> > expired.
>> >
>> > If the Interest has expired, Data packet is dropped, and the consumer
>> > is still interested in the data, the consumer could resend the
>> > Interest. Hopefully this time, the Data packet can be generated and
>> > sent faster by the application so that NFD will forward it.
>> >
>> > Haowei
>> >
>> >
>> > On Mon, Mar 30, 2015 at 1:12 PM, Anil Jangam <anilj.mailing at gmail.com> wrote:
>> >>
>> >> On Mar 30, 2015 11:08 AM, "Dehart, John" <jdd at wustl.edu> wrote:
>> >>>
>> >>>
>> >>> Is there any harm in it pushing the data out without knowing for sure if
>> >>> the
>> >>> Interest is still active?
>> >>>
>> >> If data is so critical, can the Interest be refreshed proactively before it
>> >> expires?
>> >>
>> >> /anil
>> >>
>> >>> John
>> >>>
>> >>>> On Mar 30, 2015, at 1:05 PM, Burke, Jeff <jburke at remap.ucla.edu> wrote:
>> >>>>
>> >>>>
>> >>>>
>> >>>>>
>> >>>>>
>> >>>>> On Mon, Mar 30, 2015 at 10:28 AM Burke, Jeff <jburke at remap.ucla.edu>
>> >>>>> wrote:
>> >>>>>>
>> >>>>>>
>> >>>>>> Hi folks,
>> >>>>>>
>> >>>>>> We are facing this scenario in a few applications:
>> >>>>>>
>> >>>>>> 1) Interest received by NFD, passed to an application
>> >>>>>> 2) Application not able to respond to interest, so interest stays in
>> >>>>>> NFD PIT
>> >>>>>> 3) Some time passes, but not enough for the Interest to expire
>> >>>>>> 4) Application generates data (e.g., from a sensor reading) that would
>> >>>>>> answer the Interest in the NFD PIT
>> >>>>>>
>> >>>>>> Question: How does app know to inform NFD it has the data after step 4,
>> >>>>>> and how should it do that?
>> >>>>>>
>> >>>>>> - In this type of app, should it push the data unsolicited to the NFD
>> >>>>>> and let it decide if there is something to do?
>> >>>>>
>> >>>>>
>> >>>>> In my opinion, as long as the application is certain that the Interest
>> >>>>> has arrived and is stored in NFD's PIT, it can just push the data out to
>> >>>>> NFD.
>> >>>>
>> >>>>
>> >>>>
>> >>>> How certain does it have to be?  There is a chance it could have
>> >>>> expired...
>> >>>> jeff
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>
>> >>>>>
>> >>>>> Wentao
>> >>>>>
>> >>>>>>
>> >>>>>> - Is it recommended to implement an application-level PIT so the app is
>> >>>>>> sure this data is solicited?  (Why add another PIT?)
>> >>>>>>
>> >>>>>> Thank you,
>> >>>>>> Jeff
>> >>>>>>
>> >>>>>> _______________________________________________
>> >>>>>> Nfd-dev mailing list
>> >>>>>> Nfd-dev at lists.cs.ucla.edu
>> >>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>> >>>>
>> >>>> _______________________________________________
>> >>>> Nfd-dev mailing list
>> >>>> Nfd-dev at lists.cs.ucla.edu
>> >>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>> >>>
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> Nfd-dev mailing list
>> >>> Nfd-dev at lists.cs.ucla.edu
>> >>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>> >>>
>> > _______________________________________________
>> > Nfd-dev mailing list
>> > Nfd-dev at lists.cs.ucla.edu
>> > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>> 
>> 
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
> 
> _______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev




From hyuan at wustl.edu  Wed Apr  1 10:25:06 2015
From: hyuan at wustl.edu (Haowei Yuan)
Date: Wed, 1 Apr 2015 12:25:06 -0500
Subject: [Nfd-dev] Handling new content in app for pending interest in
	NFD
In-Reply-To: <63b298e729804457bd44daef9a0db1e8@BLUPR02MB115.namprd02.prod.outlook.com>
References: <6cae5fe4-c081-44da-ad7c-17b311ca2ccc@parc.com>
	<D1415A38.1C9BA2%jburke@remap.ucla.edu>
	<63b298e729804457bd44daef9a0db1e8@BLUPR02MB115.namprd02.prod.outlook.com>
Message-ID: <CAMctUDOF-61c6ZeN3sNLTwOFy1GfBrKEsmScMHDVEogSDmLSww@mail.gmail.com>

I think this might depend the application's behavior and requirements.

If the app, by design, knows that new data generation is always
triggered by an Interest request, then when data becomes available, it
would be ok to just assume there is a pending Interest in NFD, and NFD
make the decision.

If the app generates lots of unsolicited data (for example, a user
starts to publish video on ndncon, but there is no consumer..). I'm
not sure if it is a good idea to consult the NFD's PIT for every data
in this case.

In addition, there might be cases where apps want to keep local states
for generating replies. For instance, some app may like to send a
message if no data is found within some time. Current web applications
probably also need to take care of this.

Haowei


On Wed, Apr 1, 2015 at 11:59 AM, Wentao Shang <wentaoshang at gmail.com> wrote:
> I think this problem shows one limitation of in-memory cache (and repo in
> general). The cache/repo is a "passive" storage: once the data gets in, it
> never gets out unless someone explicitly request it. The applications, on
> the other hand, can be more "active" in deciding when to send out data in
> response to previous interests.
>
> I remember Illya and Lijing's ndnvideo implementation also needs to handle
> similar problem. Their current solution (as far as I understand) is to push
> out the data twice: once to the NFD for satisfying request, once to the repo
> for archiving. The second push uses repo insertion command so it's not just
> a plain data packet (like in the first push).
>
> Wentao
>
>
> On Wed, Apr 1, 2015 at 8:38 AM Burke, Jeff <jburke at remap.ucla.edu> wrote:
>>
>>
>> Thanks for all of the discussion. I am not sure if I have been able to
>> extract an answer to the original question I was asking.  Let me try again
>> with more information:
>>
>> - The original question was intended to be only about a local NFD (for
>> now).
>> - The use case is a (soft) real-time application, like videoconferencing
>> or streaming sensor data for interactive applications. Specifically, we have
>> encountered the issue in 1) ndnrtc/ndncon for videoconferencing and 2)
>> ndn-opt, which streams data from OpenPTrack, a person tracking system built
>> on the robot operating system (ROS).
>>
>> - In these use cases, consumers want to receive data with low latency, so
>> they send interests intended to arrive before the time the data is produced,
>> but not so long before that the Interests expire before corresponding data
>> is produced.
>>
>> - As they are born, samples are signed and put into a repository by the
>> publisher.  Currently these apps use an in-memory repo specific to the
>> application, via the MemoryContentCache class provided by the NDN-CCL
>> library. But this could just as well be a repo outside the application.
>>
>> - So, when Interests arrive, they go in the local  NFD's PIT, and are
>> forwarded to the application.   We are interested in the case where the data
>> is not born yet, so the publisher cannot respond to the Interest.
>>
>> - Then, before the Interest expires from the local NFD's PIT, the
>> corresponding data is born in the application and should be used to answer
>> the Interest.  But how does that data get back to the local forwarder?
>>
>> - What should the application do?  1) Maintain its own PIT?   2) Or, push
>> the data to the local NFD, letting it drop it if it doesn't satisfy
>> anything.  3) Or, as we have previously discussed about the
>> MemoryContentCache, do we need to consider a more sophisticated interaction
>> model between the application and the daemon's content store and/or PIT that
>> reduces duplication of these capabilities in applications?
>>
>> - For now, we have implemented an in-application PIT in ndnrtc.  (I am not
>> sure what method we ended up using in ndn-opt, perhaps the unsolicited data
>> method.)
>>
>> - Discussion on this topic will help inform what library support will be
>> provided in the short term.  (I don't think we want every application author
>> to have to write a PIT, so am thinking in the short term we should provide
>> one to complement the MemoryContentCache class.  But this is duplicating
>> data structures and functionality in NFD ? is that natural, or should we
>> look to handle it through a different interaction with the local forwarder?)
>>
>> Thanks,
>> Jeff
>>
>>
>> From: <Ignacio.Solis at parc.com>
>> Date: Tue, 31 Mar 2015 00:06:33 +0000
>> To: <wentaoshang at gmail.com>, <Marc.Mosko at parc.com>
>>
>> Cc: <nfd-dev at lists.cs.ucla.edu>
>> Subject: Re: [Nfd-dev] Handling new content in app for pending interest in
>> NFD
>>
>> I'm going to guess that caching data rules will be the same as forwarding
>> rules. If the interface is not allowed to produce that content (due to
>> routing / fib entries, local naming policy) data should not be forwarded OR
>> cached.
>>
>> NDN has a slightly more complicated problem with caching than CCN given
>> then LPM matching rules.
>>
>> If you have a repo that has permission to serve this content then you
>> changed the problem. Now you need the repo protocol to give you trust.
>>
>> For regular forwarding you are relying on trusting routing. For local apps
>> you will rely (I assume)  on local permissions. For repo you will need both
>> of those plus now a repo permission  protocol.
>>
>> Dropping unsolicited data may end up being your only recourse.
>>
>> There are obviously other approaches for pre-populating caches that
>> involve higher level protocols, but I assume that's not what you're talking
>> about.
>>
>> Nacho (Ignacio) Solis
>> Principal Scientist
>> Palo Alto Research Center
>>
>> From: Wentao Shang <wentaoshang at gmail.com>
>> Sent: Mar 30, 2015 4:50 PM
>> To: "Solis, Ignacio <Ignacio.Solis at parc.com>"
>> <Ignacio.Solis at parc.com>;Mosko, Marc <Marc.Mosko at parc.com>
>> Cc: nfd-dev at lists.cs.ucla.edu
>> Subject: Re: [Nfd-dev] Handling new content in app for pending interest in
>> NFD
>>
>> Hi Nacho,
>>
>> I don't have any argument against this rule right now. But it seems more
>> relevant to "forwarding" data packets, while the problem we were discussing
>> is about "caching" unsolicited data packets, which cannot be forwarded
>> anyway because there is no PIT. The simplest solution I would suggest to the
>> problem is to drop any unsolicited data in the forwarder.
>>
>> Wentao
>>
>> On Mon, Mar 30, 2015 at 3:42 PM <Ignacio.Solis at parc.com> wrote:
>>>
>>> This rule is important, router or not. You can't have "non-priviledged"
>>> applications generating replies at servers. Specially important at systems
>>> with multiple users,  tenants, virtual systems.
>>>
>>> At the local router there are even more restrictions.  We haven't even
>>> gotten to talking about privileged names and restrictions and end-h out
>>> behavior.   We have a design  for this for CCN that we'll be talking about
>>> at CCNxCon.
>>>
>>> Nacho (Ignacio) Solis
>>> Principal Scientist
>>> Palo Alto Research Center
>>>
>>> From: Wentao Shang <wentaoshang at gmail.com>
>>> Sent: Mar 30, 2015 1:07 PM
>>> To: Mosko, Marc <Marc.Mosko at parc.com>
>>>
>>> Cc: nfd-dev at lists.cs.ucla.edu
>>> Subject: Re: [Nfd-dev] Handling new content in app for pending interest
>>> in NFD
>>>
>>> On Mon, Mar 30, 2015 at 12:52 PM <Marc.Mosko at parc.com> wrote:
>>>>
>>>> I?ll add that in addition to the content having a PIT entry, Nacho Solis
>>>> has suggested that a router should verify that a Content Object came in a
>>>> face from which it was requested.  Otherwise, there?s a potential for
>>>> off-path attacks sending content objects that match popular well-known
>>>> names.  A variation on that, rather than tracking forward paths, would be to
>>>> at minimum verify that a content object comes from a face for which there?s
>>>> a corresponding FIB entry for the name.
>>>
>>>
>>> This requirement makes sense for transit routers that receive packets
>>> from other routers. But I'm not sure whether this is necessary for
>>> forwarding daemons handling local applications... The pushed data should
>>> never get out of the local forwarder unless there is a PIT entry specifying
>>> a path pointing to some other router.
>>>
>>> Wentao
>>>
>>>>
>>>>
>>>> Marc
>>>>
>>>> On Mar 30, 2015, at 12:08 PM, Wentao Shang <wentaoshang at gmail.com>
>>>> wrote:
>>>>
>>>> I agree with Dave.
>>>>
>>>> In principle, router should not cache unsolicited data. In the situation
>>>> we are discussing, the application should either just push the data out,
>>>> which may be dropped by NFD if the interest has expired, or store the data
>>>> in some application-level cache (or repo) for future fetching.
>>>>
>>>> Wentao
>>>>
>>>> On Mon, Mar 30, 2015 at 11:52 AM Dave Oran (oran) <oran at cisco.com>
>>>> wrote:
>>>>>
>>>>> Isn?t this what the repo was invented for?
>>>>>
>>>>> Holding packets in a router that has forgotten that they were asked for
>>>>> is a giant invitation to cache pollution/poisoning attacks.
>>>>>
>>>>> > On Mar 30, 2015, at 2:24 PM, Haowei Yuan <hyuan at wustl.edu> wrote:
>>>>> >
>>>>> > I think as long as the data has actually been requested by an
>>>>> > Interest
>>>>> > packet, it is safe to send the Data packet to NFD. The NFD will
>>>>> > either
>>>>> > forward or drop the Data packet by checking if the Interest has
>>>>> > expired.
>>>>> >
>>>>> > If the Interest has expired, Data packet is dropped, and the consumer
>>>>> > is still interested in the data, the consumer could resend the
>>>>> > Interest. Hopefully this time, the Data packet can be generated and
>>>>> > sent faster by the application so that NFD will forward it.
>>>>> >
>>>>> > Haowei
>>>>> >
>>>>> >
>>>>> > On Mon, Mar 30, 2015 at 1:12 PM, Anil Jangam
>>>>> > <anilj.mailing at gmail.com> wrote:
>>>>> >>
>>>>> >> On Mar 30, 2015 11:08 AM, "Dehart, John" <jdd at wustl.edu> wrote:
>>>>> >>>
>>>>> >>>
>>>>> >>> Is there any harm in it pushing the data out without knowing for
>>>>> >>> sure if
>>>>> >>> the
>>>>> >>> Interest is still active?
>>>>> >>>
>>>>> >> If data is so critical, can the Interest be refreshed proactively
>>>>> >> before it
>>>>> >> expires?
>>>>> >>
>>>>> >> /anil
>>>>> >>
>>>>> >>> John
>>>>> >>>
>>>>> >>>> On Mar 30, 2015, at 1:05 PM, Burke, Jeff <jburke at remap.ucla.edu>
>>>>> >>>> wrote:
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>>
>>>>> >>>>>
>>>>> >>>>> On Mon, Mar 30, 2015 at 10:28 AM Burke, Jeff
>>>>> >>>>> <jburke at remap.ucla.edu>
>>>>> >>>>> wrote:
>>>>> >>>>>>
>>>>> >>>>>>
>>>>> >>>>>> Hi folks,
>>>>> >>>>>>
>>>>> >>>>>> We are facing this scenario in a few applications:
>>>>> >>>>>>
>>>>> >>>>>> 1) Interest received by NFD, passed to an application
>>>>> >>>>>> 2) Application not able to respond to interest, so interest
>>>>> >>>>>> stays in
>>>>> >>>>>> NFD PIT
>>>>> >>>>>> 3) Some time passes, but not enough for the Interest to expire
>>>>> >>>>>> 4) Application generates data (e.g., from a sensor reading) that
>>>>> >>>>>> would
>>>>> >>>>>> answer the Interest in the NFD PIT
>>>>> >>>>>>
>>>>> >>>>>> Question: How does app know to inform NFD it has the data after
>>>>> >>>>>> step 4,
>>>>> >>>>>> and how should it do that?
>>>>> >>>>>>
>>>>> >>>>>> - In this type of app, should it push the data unsolicited to
>>>>> >>>>>> the NFD
>>>>> >>>>>> and let it decide if there is something to do?
>>>>> >>>>>
>>>>> >>>>>
>>>>> >>>>> In my opinion, as long as the application is certain that the
>>>>> >>>>> Interest
>>>>> >>>>> has arrived and is stored in NFD's PIT, it can just push the data
>>>>> >>>>> out to
>>>>> >>>>> NFD.
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> How certain does it have to be?  There is a chance it could have
>>>>> >>>> expired...
>>>>> >>>> jeff
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>>
>>>>> >>>>> Wentao
>>>>> >>>>>
>>>>> >>>>>>
>>>>> >>>>>> - Is it recommended to implement an application-level PIT so the
>>>>> >>>>>> app is
>>>>> >>>>>> sure this data is solicited?  (Why add another PIT?)
>>>>> >>>>>>
>>>>> >>>>>> Thank you,
>>>>> >>>>>> Jeff
>>>>> >>>>>>
>>>>> >>>>>> _______________________________________________
>>>>> >>>>>> Nfd-dev mailing list
>>>>> >>>>>> Nfd-dev at lists.cs.ucla.edu
>>>>> >>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>>>> >>>>
>>>>> >>>> _______________________________________________
>>>>> >>>> Nfd-dev mailing list
>>>>> >>>> Nfd-dev at lists.cs.ucla.edu
>>>>> >>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>> >>> _______________________________________________
>>>>> >>> Nfd-dev mailing list
>>>>> >>> Nfd-dev at lists.cs.ucla.edu
>>>>> >>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>>>> >>>
>>>>> > _______________________________________________
>>>>> > Nfd-dev mailing list
>>>>> > Nfd-dev at lists.cs.ucla.edu
>>>>> > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Nfd-dev mailing list
>>>>> Nfd-dev at lists.cs.ucla.edu
>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>>>
>>>> _______________________________________________
>>>> Nfd-dev mailing list
>>>> Nfd-dev at lists.cs.ucla.edu
>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>>>
>>>>
>> _______________________________________________ Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev



From wentaoshang at gmail.com  Wed Apr  1 10:50:34 2015
From: wentaoshang at gmail.com (Wentao Shang)
Date: Wed, 01 Apr 2015 17:50:34 +0000
Subject: [Nfd-dev] Handling new content in app for pending interest in
	NFD
In-Reply-To: <D4A62838-0237-4FEC-B0B1-EA33AD0A5D2F@cisco.com>
References: <6cae5fe4-c081-44da-ad7c-17b311ca2ccc@parc.com>
	<D1415A38.1C9BA2%jburke@remap.ucla.edu>
	<CAD4s1gQ2i3i48sNE3aDoqTHup7y_zV_WvWOzCVaUHC=OKCCEUQ@mail.gmail.com>
	<D4A62838-0237-4FEC-B0B1-EA33AD0A5D2F@cisco.com>
Message-ID: <CAD4s1gTPQp=exUCVnZh2bscA2zhQhJMesA8MUa=Evge2FuX7Sw@mail.gmail.com>

On Wed, Apr 1, 2015 at 10:21 AM Dave Oran (oran) <oran at cisco.com> wrote:

>
> > On Apr 1, 2015, at 12:59 PM, Wentao Shang <wentaoshang at gmail.com> wrote:
> >
> > I think this problem shows one limitation of in-memory cache (and repo
> in general). The cache/repo is a "passive" storage: once the data gets in,
> it never gets out unless someone explicitly request it.
> And why is that not exactly what you want? A place that can respond to
> interests without interrupting or otherwise causing thread scheduling
> problems for an application generating data open-loop.
>

I think in general this is what most application wants. The problem that
Jeff mentioned is that by the time the data is inserted into repo, the
interest has already resided inside NFD. The repo may have seen that
interest before but did not response because the data wasn't ready yet.

But I totally agree that repo should not do anything more than just storing
the data and responding to incoming interest. It's the application who can
be more intelligent in deciding when to push out data.


>
> The repo is protected from infinite growth by the expiration time of the
> data.
>
> > The applications, on the other hand, can be more "active" in deciding
> when to send out data in response to previous interests.
> >
> You;ll have to explain why this is a good thing? Can the application
> smooth jitter this way? Maybe. What other benefits might accrue?
>

I believe the application should have the freedom to insert an arbitrary
delay before responding to the interest. That delay may range from zero to
infinite. There are various reasons to cause the delay: maybe the
application needs to fetch some data from some other remote host; maybe the
application wants to adjust jitter; or maybe the machine that runs the
application is just super slow...


>
> > I remember Illya and Lijing's ndnvideo implementation also needs to
> handle similar problem. Their current solution (as far as I understand) is
> to push out the data twice: once to the NFD for satisfying request, once to
> the repo for archiving. The second push uses repo insertion command so it's
> not just a plain data packet (like in the first push).
> >
> Why not put everything into the repo and let the Repo respond to all
> interests? Is it the cost of context switches?
>

Still, the problem is that if the repo already missed the interest, it has
to wait for the retransmission of that interest, unless someone (most
likely the application) pulls the trigger and sends out the data before the
previous interest expires...


>
> Is it because the architectural model of the repo is that it had to have
> non-volatile backing store to survive host crashes which might be
> irrelevant for pure realtime applications (i.e. you don?t care about
> recordings).
>
>
> > Wentao
> >
> > On Wed, Apr 1, 2015 at 8:38 AM Burke, Jeff <jburke at remap.ucla.edu>
> wrote:
> >
> > Thanks for all of the discussion. I am not sure if I have been able to
> extract an answer to the original question I was asking.  Let me try again
> with more information:
> >
> > - The original question was intended to be only about a local NFD (for
> now).
> > - The use case is a (soft) real-time application, like videoconferencing
> or streaming sensor data for interactive applications. Specifically, we
> have encountered the issue in 1) ndnrtc/ndncon for videoconferencing and 2)
> ndn-opt, which streams data from OpenPTrack, a person tracking system built
> on the robot operating system (ROS).
> >
> > - In these use cases, consumers want to receive data with low latency,
> so they send interests intended to arrive before the time the data is
> produced, but not so long before that the Interests expire before
> corresponding data is produced.
> >
> > - As they are born, samples are signed and put into a repository by the
> publisher.  Currently these apps use an in-memory repo specific to the
> application, via the MemoryContentCache class provided by the NDN-CCL
> library. But this could just as well be a repo outside the application.
> >
> > - So, when Interests arrive, they go in the local  NFD's PIT, and are
> forwarded to the application.   We are interested in the case where the
> data is not born yet, so the publisher cannot respond to the Interest.
> >
> > - Then, before the Interest expires from the local NFD's PIT, the
> corresponding data is born in the application and should be used to answer
> the Interest.  But how does that data get back to the local forwarder?
> >
> > - What should the application do?  1) Maintain its own PIT?   2) Or,
> push the data to the local NFD, letting it drop it if it doesn't satisfy
> anything.  3) Or, as we have previously discussed about the
> MemoryContentCache, do we need to consider a more sophisticated interaction
> model between the application and the daemon's content store and/or PIT
> that reduces duplication of these capabilities in applications?
> >
> > - For now, we have implemented an in-application PIT in ndnrtc.  (I am
> not sure what method we ended up using in ndn-opt, perhaps the unsolicited
> data method.)
> >
> > - Discussion on this topic will help inform what library support will be
> provided in the short term.  (I don't think we want every application
> author to have to write a PIT, so am thinking in the short term we should
> provide one to complement the MemoryContentCache class.  But this is
> duplicating data structures and functionality in NFD ? is that natural, or
> should we look to handle it through a different interaction with the local
> forwarder?)
> >
> > Thanks,
> > Jeff
> >
> >
> > From: <Ignacio.Solis at parc.com>
> > Date: Tue, 31 Mar 2015 00:06:33 +0000
> > To: <wentaoshang at gmail.com>, <Marc.Mosko at parc.com>
> >
> > Cc: <nfd-dev at lists.cs.ucla.edu>
> > Subject: Re: [Nfd-dev] Handling new content in app for pending interest
> in NFD
> >
> > I'm going to guess that caching data rules will be the same as
> forwarding rules. If the interface is not allowed to produce that content
> (due to routing / fib entries, local naming policy) data should not be
> forwarded OR cached.
> >
> > NDN has a slightly more complicated problem with caching than CCN given
> then LPM matching rules.
> >
> > If you have a repo that has permission to serve this content then you
> changed the problem. Now you need the repo protocol to give you trust.
> >
> > For regular forwarding you are relying on trusting routing. For local
> apps you will rely (I assume)  on local permissions. For repo you will need
> both of those plus now a repo permission  protocol.
> >
> > Dropping unsolicited data may end up being your only recourse.
> >
> > There are obviously other approaches for pre-populating caches that
> involve higher level protocols, but I assume that's not what you're talking
> about.
> >
> > Nacho (Ignacio) Solis
> > Principal Scientist
> > Palo Alto Research Center
> >
> > From: Wentao Shang <wentaoshang at gmail.com>
> > Sent: Mar 30, 2015 4:50 PM
> > To: "Solis, Ignacio <Ignacio.Solis at parc.com>" <Ignacio.Solis at parc.com>;Mosko,
> Marc <Marc.Mosko at parc.com>
> > Cc: nfd-dev at lists.cs.ucla.edu
> > Subject: Re: [Nfd-dev] Handling new content in app for pending interest
> in NFD
> >
> > Hi Nacho,
> >
> > I don't have any argument against this rule right now. But it seems more
> relevant to "forwarding" data packets, while the problem we were discussing
> is about "caching" unsolicited data packets, which cannot be forwarded
> anyway because there is no PIT. The simplest solution I would suggest to
> the problem is to drop any unsolicited data in the forwarder.
> >
> > Wentao
> >
> > On Mon, Mar 30, 2015 at 3:42 PM <Ignacio.Solis at parc.com> wrote:
> > This rule is important, router or not. You can't have "non-priviledged"
> applications generating replies at servers. Specially important at systems
> with multiple users,  tenants, virtual systems.
> >
> > At the local router there are even more restrictions.  We haven't even
> gotten to talking about privileged names and restrictions and end-h out
> behavior.   We have a design  for this for CCN that we'll be talking about
> at CCNxCon.
> >
> > Nacho (Ignacio) Solis
> > Principal Scientist
> > Palo Alto Research Center
> >
> > From: Wentao Shang <wentaoshang at gmail.com>
> > Sent: Mar 30, 2015 1:07 PM
> > To: Mosko, Marc <Marc.Mosko at parc.com>
> >
> > Cc: nfd-dev at lists.cs.ucla.edu
> > Subject: Re: [Nfd-dev] Handling new content in app for pending interest
> in NFD
> >
> > On Mon, Mar 30, 2015 at 12:52 PM <Marc.Mosko at parc.com> wrote:
> > I?ll add that in addition to the content having a PIT entry, Nacho Solis
> has suggested that a router should verify that a Content Object came in a
> face from which it was requested.  Otherwise, there?s a potential for
> off-path attacks sending content objects that match popular well-known
> names.  A variation on that, rather than tracking forward paths, would be
> to at minimum verify that a content object comes from a face for which
> there?s a corresponding FIB entry for the name.
> >
> > This requirement makes sense for transit routers that receive packets
> from other routers. But I'm not sure whether this is necessary for
> forwarding daemons handling local applications... The pushed data should
> never get out of the local forwarder unless there is a PIT entry specifying
> a path pointing to some other router.
> >
> > Wentao
> >
> >
> > Marc
> >
> > On Mar 30, 2015, at 12:08 PM, Wentao Shang <wentaoshang at gmail.com>
> wrote:
> >
> >> I agree with Dave.
> >>
> >> In principle, router should not cache unsolicited data. In the
> situation we are discussing, the application should either just push the
> data out, which may be dropped by NFD if the interest has expired, or store
> the data in some application-level cache (or repo) for future fetching.
> >>
> >> Wentao
> >>
> >> On Mon, Mar 30, 2015 at 11:52 AM Dave Oran (oran) <oran at cisco.com>
> wrote:
> >> Isn?t this what the repo was invented for?
> >>
> >> Holding packets in a router that has forgotten that they were asked for
> is a giant invitation to cache pollution/poisoning attacks.
> >>
> >> > On Mar 30, 2015, at 2:24 PM, Haowei Yuan <hyuan at wustl.edu> wrote:
> >> >
> >> > I think as long as the data has actually been requested by an Interest
> >> > packet, it is safe to send the Data packet to NFD. The NFD will either
> >> > forward or drop the Data packet by checking if the Interest has
> >> > expired.
> >> >
> >> > If the Interest has expired, Data packet is dropped, and the consumer
> >> > is still interested in the data, the consumer could resend the
> >> > Interest. Hopefully this time, the Data packet can be generated and
> >> > sent faster by the application so that NFD will forward it.
> >> >
> >> > Haowei
> >> >
> >> >
> >> > On Mon, Mar 30, 2015 at 1:12 PM, Anil Jangam <anilj.mailing at gmail.com>
> wrote:
> >> >>
> >> >> On Mar 30, 2015 11:08 AM, "Dehart, John" <jdd at wustl.edu> wrote:
> >> >>>
> >> >>>
> >> >>> Is there any harm in it pushing the data out without knowing for
> sure if
> >> >>> the
> >> >>> Interest is still active?
> >> >>>
> >> >> If data is so critical, can the Interest be refreshed proactively
> before it
> >> >> expires?
> >> >>
> >> >> /anil
> >> >>
> >> >>> John
> >> >>>
> >> >>>> On Mar 30, 2015, at 1:05 PM, Burke, Jeff <jburke at remap.ucla.edu>
> wrote:
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>>
> >> >>>>>
> >> >>>>> On Mon, Mar 30, 2015 at 10:28 AM Burke, Jeff <
> jburke at remap.ucla.edu>
> >> >>>>> wrote:
> >> >>>>>>
> >> >>>>>>
> >> >>>>>> Hi folks,
> >> >>>>>>
> >> >>>>>> We are facing this scenario in a few applications:
> >> >>>>>>
> >> >>>>>> 1) Interest received by NFD, passed to an application
> >> >>>>>> 2) Application not able to respond to interest, so interest
> stays in
> >> >>>>>> NFD PIT
> >> >>>>>> 3) Some time passes, but not enough for the Interest to expire
> >> >>>>>> 4) Application generates data (e.g., from a sensor reading) that
> would
> >> >>>>>> answer the Interest in the NFD PIT
> >> >>>>>>
> >> >>>>>> Question: How does app know to inform NFD it has the data after
> step 4,
> >> >>>>>> and how should it do that?
> >> >>>>>>
> >> >>>>>> - In this type of app, should it push the data unsolicited to
> the NFD
> >> >>>>>> and let it decide if there is something to do?
> >> >>>>>
> >> >>>>>
> >> >>>>> In my opinion, as long as the application is certain that the
> Interest
> >> >>>>> has arrived and is stored in NFD's PIT, it can just push the data
> out to
> >> >>>>> NFD.
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>> How certain does it have to be?  There is a chance it could have
> >> >>>> expired...
> >> >>>> jeff
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>
> >> >>>>>
> >> >>>>> Wentao
> >> >>>>>
> >> >>>>>>
> >> >>>>>> - Is it recommended to implement an application-level PIT so the
> app is
> >> >>>>>> sure this data is solicited?  (Why add another PIT?)
> >> >>>>>>
> >> >>>>>> Thank you,
> >> >>>>>> Jeff
> >> >>>>>>
> >> >>>>>> _______________________________________________
> >> >>>>>> Nfd-dev mailing list
> >> >>>>>> Nfd-dev at lists.cs.ucla.edu
> >> >>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
> >> >>>>
> >> >>>> _______________________________________________
> >> >>>> Nfd-dev mailing list
> >> >>>> Nfd-dev at lists.cs.ucla.edu
> >> >>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
> >> >>>
> >> >>>
> >> >>>
> >> >>> _______________________________________________
> >> >>> Nfd-dev mailing list
> >> >>> Nfd-dev at lists.cs.ucla.edu
> >> >>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
> >> >>>
> >> > _______________________________________________
> >> > Nfd-dev mailing list
> >> > Nfd-dev at lists.cs.ucla.edu
> >> > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
> >>
> >>
> >> _______________________________________________
> >> Nfd-dev mailing list
> >> Nfd-dev at lists.cs.ucla.edu
> >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
> >> _______________________________________________
> >> Nfd-dev mailing list
> >> Nfd-dev at lists.cs.ucla.edu
> >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
> >
> > _______________________________________________ Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu http://www.lists.cs.ucla.edu/
> mailman/listinfo/nfd-dev
> > _______________________________________________
> > Nfd-dev mailing list
> > Nfd-dev at lists.cs.ucla.edu
> > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
> > _______________________________________________
> > Nfd-dev mailing list
> > Nfd-dev at lists.cs.ucla.edu
> > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150401/b1842f26/attachment.html>

From dbhat at umass.EDU  Wed Apr  1 10:57:10 2015
From: dbhat at umass.EDU (Divyashri Bhat)
Date: Wed, 1 Apr 2015 17:57:10 +0000
Subject: [Nfd-dev] Ethernet Multicast in NFD
Message-ID: <1C6C5C13-4AAE-42B8-BC1E-C684F45C9EFB@umass.edu>

Hi,

I am trying to use the broadcast strategy in a testbed setup in Ubuntu 12.04 VMs.

The corresponding entry in my config file:

ether
  {
    ; Ethernet multicast settings
    ; NFD creates one Ethernet multicast face per NIC
    mcast yes ; set to 'no' to disable Ethernet multicast, default 'yes'
    mcast_group 01:00:5E:00:17:AA ; Ethernet multicast group
  }

As far as I understand, when I run the following command, I should see corresponding FIB entries for all Ethernet faces.

sudo nfdc register /test/pingserver ether://[01:00:5e:00:17:aa]


However, I have 4 ethernet faces and my nfd-status result looks like this:

  faceid=256 remote=ether://[01:00:5e:00:17:aa] local=dev://eth3 counters={in={185i 0d 11698B} out={0i 0d 0B}} non-local persistent multi-access
  faceid=257 remote=ether://[01:00:5e:00:17:aa] local=dev://eth2 counters={in={0i 0d 0B} out={0i 0d 0B}} non-local persistent multi-access
  faceid=258 remote=ether://[01:00:5e:00:17:aa] local=dev://eth1 counters={in={0i 0d 0B} out={0i 0d 0B}} non-local persistent multi-access
  faceid=259 remote=ether://[01:00:5e:00:17:aa] local=dev://eth0 counters={in={0i 0d 0B} out={0i 0d 0B}} non-local persistent multi-access
  faceid=260 remote=fd://23 local=unix:///run/nfd.sock counters={in={50i 7d 7511B} out={7i 29d 16632B}} local on-demand point-to-point
  faceid=271 remote=fd://26 local=unix:///run/nfd.sock counters={in={3i 0d 137B} out={0i 2d 858B}} local on-demand point-to-point
FIB:
  /localhost/nfd nexthops={faceid=1 (cost=0)}
  /test/pingserver nexthops={faceid=256 (cost=0)}
  /localhost/nfd/rib nexthops={faceid=260 (cost=0)}
RIB:
  /localhost/nfd/rib route={faceid=260 (origin=0 cost=0 ChildInherit)}
  /test/pingserver route={faceid=256 (origin=255 cost=0 ChildInherit)}
Strategy choices:
  /localhost/nfd strategy=/localhost/nfd/strategy/broadcast/%FD%01
  /ndn/broadcast strategy=/localhost/nfd/strategy/broadcast/%FD%01
  /localhost strategy=/localhost/nfd/strategy/broadcast/%FD%01
  /test/pingserver strategy=/localhost/nfd/strategy/broadcast/%FD%01
  / strategy=/localhost/nfd/strategy/broadcast/%FD%01

How can I broadcast this Interest on all Ethernet faces?

Could you help me understand what I am missing here?

Thank you

Regards,
Divyashri Bhat
dbhat at umass.edu<mailto:dbhat at umass.edu>
Graduate Student
Department of Electrical and Computer Engineering,
University of Massachusetts, Amherst




From mjs at cisco.com  Wed Apr  1 10:57:56 2015
From: mjs at cisco.com (Mark Stapp)
Date: Wed, 01 Apr 2015 13:57:56 -0400
Subject: [Nfd-dev] Handling new content in app for pending interest in
 NFD
In-Reply-To: <CAD4s1gQ2i3i48sNE3aDoqTHup7y_zV_WvWOzCVaUHC=OKCCEUQ@mail.gmail.com>
References: <6cae5fe4-c081-44da-ad7c-17b311ca2ccc@parc.com>	<D1415A38.1C9BA2%jburke@remap.ucla.edu>
	<CAD4s1gQ2i3i48sNE3aDoqTHup7y_zV_WvWOzCVaUHC=OKCCEUQ@mail.gmail.com>
Message-ID: <551C31A4.6070702@cisco.com>

Apologies for being a little ignorant about the 'repo' process. How does 
the local forwarder know whether to send an interest to the repo process 
or to the application process that 'registered' a particular name 
prefix? or does the repo process intermediate - somehow - between every 
application and the host's forwarder, by default, like a proxy? does the 
repo do exact-match on the names it sees, or something ... else?

Thanks,
Mark

On 4/1/15 12:59 PM, Wentao Shang wrote:
> I think this problem shows one limitation of in-memory cache (and repo
> in general). The cache/repo is a "passive" storage: once the data gets
> in, it never gets out unless someone explicitly request it. The
> applications, on the other hand, can be more "active" in deciding when
> to send out data in response to previous interests.
>
> I remember Illya and Lijing's ndnvideo implementation also needs to
> handle similar problem. Their current solution (as far as I understand)
> is to push out the data twice: once to the NFD for satisfying request,
> once to the repo for archiving. The second push uses repo insertion
> command so it's not just a plain data packet (like in the first push).
>
> Wentao
>
> On Wed, Apr 1, 2015 at 8:38 AM Burke, Jeff <jburke at remap.ucla.edu
> <mailto:jburke at remap.ucla.edu>> wrote:
>
>
>     Thanks for all of the discussion. I am not sure if I have been able
>     to extract an answer to the original question I was asking.  Let me
>     try again with more information:
>
>     - The original question was intended to be only about a local NFD
>     (for now).
>     - The use case is a (soft) real-time application, like
>     videoconferencing or streaming sensor data for interactive
>     applications. Specifically, we have encountered the issue in 1)
>     ndnrtc/ndncon <https://github.com/remap/ndncon/> for
>     videoconferencing and 2) ndn-opt, which streams data from OpenPTrack
>     <http://openptrack.org/>, a person tracking system built on the
>     robot operating system (ROS).
>
>     - In these use cases, consumers want to receive data with low
>     latency, so they send interests intended to arrive before the time
>     the data is produced, but not so long before that the Interests
>     expire before corresponding data is produced.
>
>     - As they are born, samples are signed and put into a repository by
>     the publisher.  Currently these apps use an in-memory repo specific
>     to the application, via the MemoryContentCache class provided by the
>     NDN-CCL library. But this could just as well be a repo outside the
>     application.
>
>     - So, when Interests arrive, they go in the local  NFD's PIT, and
>     are forwarded to the application.   We are interested in the case
>     where the data is not born /yet/, so the publisher cannot respond to
>     the Interest.
>
>     - Then, before the Interest expires from the local NFD's PIT, the
>     corresponding data is born in the application and /should/ be used
>     to answer the Interest.  But how does that data get back to the
>     local forwarder?
>
>     - What should the application do?  1) Maintain its own PIT?   2) Or,
>     push the data to the local NFD, letting it drop it if it doesn't
>     satisfy anything.  3) Or, as we have previously discussed about the
>     MemoryContentCache, do we need to consider a more sophisticated
>     interaction model between the application and the daemon's content
>     store and/or PIT that reduces duplication of these capabilities in
>     applications?
>
>     - For now, we have implemented an in-application PIT in ndnrtc.  (I
>     am not sure what method we ended up using in ndn-opt, perhaps the
>     unsolicited data method.)
>
>     - Discussion on this topic will help inform what library support
>     will be provided in the short term.  (I don't think we want every
>     application author to have to write a PIT, so am thinking in the
>     short term we should provide one to complement the
>     MemoryContentCache class.  But this is duplicating data structures
>     and functionality in NFD ? is that natural, or should we look to
>     handle it through a different interaction with the local forwarder?)
>
>     Thanks,
>     Jeff
>
>
>     From: <Ignacio.Solis at parc.com <mailto:Ignacio.Solis at parc.com>>
>     Date: Tue, 31 Mar 2015 00:06:33 +0000
>     To: <wentaoshang at gmail.com <mailto:wentaoshang at gmail.com>>,
>     <Marc.Mosko at parc.com <mailto:Marc.Mosko at parc.com>>
>
>     Cc: <nfd-dev at lists.cs.ucla.edu <mailto:nfd-dev at lists.cs.ucla.edu>>
>     Subject: Re: [Nfd-dev] Handling new content in app for pending
>     interest in NFD
>
>         I'm going to guess that caching data rules will be the same as
>         forwarding rules. If the interface is not allowed to produce
>         that content (due to routing / fib entries, local naming policy)
>         data should not be forwarded OR cached.
>
>         NDN has a slightly more complicated problem with caching than
>         CCN given then LPM matching rules.
>
>         If you have a repo that has permission to serve this content
>         then you changed the problem. Now you need the repo protocol to
>         give you trust.
>
>         For regular forwarding you are relying on trusting routing. For
>         local apps you will rely (I assume)  on local permissions. For
>         repo you will need both of those plus now a repo permission
>           protocol.
>
>         Dropping unsolicited data may end up being your only recourse.
>
>         There are obviously other approaches for pre-populating caches
>         that involve higher level protocols, but I assume that's not
>         what you're talking about.
>
>         Nacho (Ignacio) Solis
>         Principal Scientist
>         Palo Alto Research Center
>
>         *From:* Wentao Shang <wentaoshang at gmail.com
>         <mailto:wentaoshang at gmail.com>>
>         *Sent:* Mar 30, 2015 4:50 PM
>         *To:* "Solis, Ignacio <Ignacio.Solis at parc.com
>         <mailto:Ignacio.Solis at parc.com>>" <Ignacio.Solis at parc.com
>         <mailto:Ignacio.Solis at parc.com>>;Mosko, Marc
>         <Marc.Mosko at parc.com <mailto:Marc.Mosko at parc.com>>
>         *Cc:* nfd-dev at lists.cs.ucla.edu <mailto:nfd-dev at lists.cs.ucla.edu>
>         *Subject:* Re: [Nfd-dev] Handling new content in app for pending
>         interest in NFD
>
>         Hi Nacho,
>
>         I don't have any argument against this rule right now. But it
>         seems more relevant to "forwarding" data packets, while the
>         problem we were discussing is about "caching" unsolicited data
>         packets, which cannot be forwarded anyway because there is no
>         PIT. The simplest solution I would suggest to the problem is to
>         drop any unsolicited data in the forwarder.
>
>         Wentao
>
>         On Mon, Mar 30, 2015 at 3:42 PM <Ignacio.Solis at parc.com
>         <mailto:Ignacio.Solis at parc.com>> wrote:
>
>             This rule is important, router or not. You can't have
>             "non-priviledged"  applications generating replies at
>             servers. Specially important at systems with multiple users,
>               tenants, virtual systems.
>
>             At the local router there are even more restrictions.  We
>             haven't even gotten to talking about privileged names and
>             restrictions and end-h out behavior.   We have a design  for
>             this for CCN that we'll be talking about at CCNxCon.
>
>             Nacho (Ignacio) Solis
>             Principal Scientist
>             Palo Alto Research Center
>
>             *From:* Wentao Shang <wentaoshang at gmail.com
>             <mailto:wentaoshang at gmail.com>>
>             *Sent:* Mar 30, 2015 1:07 PM
>             *To:* Mosko, Marc <Marc.Mosko at parc.com
>             <mailto:Marc.Mosko at parc.com>>
>
>             *Cc:* nfd-dev at lists.cs.ucla.edu
>             <mailto:nfd-dev at lists.cs.ucla.edu>
>             *Subject:* Re: [Nfd-dev] Handling new content in app for
>             pending interest in NFD
>
>             On Mon, Mar 30, 2015 at 12:52 PM <Marc.Mosko at parc.com
>             <mailto:Marc.Mosko at parc.com>> wrote:
>
>                 I?ll add that in addition to the content having a PIT
>                 entry, Nacho Solis has suggested that a router should
>                 verify that a Content Object came in a face from which
>                 it was requested.  Otherwise, there?s a potential for
>                 off-path attacks sending content objects that match
>                 popular well-known names.  A variation on that, rather
>                 than tracking forward paths, would be to at minimum
>                 verify that a content object comes from a face for which
>                 there?s a corresponding FIB entry for the name.
>
>
>             This requirement makes sense for transit routers that
>             receive packets from other routers. But I'm not sure whether
>             this is necessary for forwarding daemons handling local
>             applications... The pushed data should never get out of the
>             local forwarder unless there is a PIT entry specifying a
>             path pointing to some other router.
>
>             Wentao
>
>
>                 Marc
>
>                 On Mar 30, 2015, at 12:08 PM, Wentao Shang
>                 <wentaoshang at gmail.com <mailto:wentaoshang at gmail.com>>
>                 wrote:
>
>>                 I agree with Dave.
>>
>>                 In principle, router should not cache unsolicited
>>                 data. In the situation we are discussing, the
>>                 application should either just push the data out,
>>                 which may be dropped by NFD if the interest has
>>                 expired, or store the data in some application-level
>>                 cache (or repo) for future fetching.
>>
>>                 Wentao
>>
>>                 On Mon, Mar 30, 2015 at 11:52 AM Dave Oran (oran)
>>                 <oran at cisco.com <mailto:oran at cisco.com>> wrote:
>>
>>                     Isn?t this what the repo was invented for?
>>
>>                     Holding packets in a router that has forgotten
>>                     that they were asked for is a giant invitation to
>>                     cache pollution/poisoning attacks.
>>
>>                     > On Mar 30, 2015, at 2:24 PM, Haowei Yuan <hyuan at wustl.edu <mailto:hyuan at wustl.edu>> wrote:
>>                     >
>>                     > I think as long as the data has actually been requested by an Interest
>>                     > packet, it is safe to send the Data packet to NFD. The NFD will either
>>                     > forward or drop the Data packet by checking if the Interest has
>>                     > expired.
>>                     >
>>                     > If the Interest has expired, Data packet is dropped, and the consumer
>>                     > is still interested in the data, the consumer could resend the
>>                     > Interest. Hopefully this time, the Data packet can be generated and
>>                     > sent faster by the application so that NFD will forward it.
>>                     >
>>                     > Haowei
>>                     >
>>                     >
>>                     > On Mon, Mar 30, 2015 at 1:12 PM, Anil Jangam <anilj.mailing at gmail.com
>>                     <mailto:anilj.mailing at gmail.com>> wrote:
>>                     >>
>>                     >> On Mar 30, 2015 11:08 AM, "Dehart, John" <jdd at wustl.edu <mailto:jdd at wustl.edu>> wrote:
>>                     >>>
>>                     >>>
>>                     >>> Is there any harm in it pushing the data out without knowing for sure if
>>                     >>> the
>>                     >>> Interest is still active?
>>                     >>>
>>                     >> If data is so critical, can the Interest be refreshed proactively before it
>>                     >> expires?
>>                     >>
>>                     >> /anil
>>                     >>
>>                     >>> John
>>                     >>>
>>                     >>>> On Mar 30, 2015, at 1:05 PM, Burke, Jeff <jburke at remap.ucla.edu
>>                     <mailto:jburke at remap.ucla.edu>> wrote:
>>                     >>>>
>>                     >>>>
>>                     >>>>
>>                     >>>>>
>>                     >>>>>
>>                     >>>>> On Mon, Mar 30, 2015 at 10:28 AM Burke, Jeff <jburke at remap.ucla.edu <mailto:jburke at remap.ucla.edu>>
>>                     >>>>> wrote:
>>                     >>>>>>
>>                     >>>>>>
>>                     >>>>>> Hi folks,
>>                     >>>>>>
>>                     >>>>>> We are facing this scenario in a few applications:
>>                     >>>>>>
>>                     >>>>>> 1) Interest received by NFD, passed to an application
>>                     >>>>>> 2) Application not able to respond to interest, so interest stays in
>>                     >>>>>> NFD PIT
>>                     >>>>>> 3) Some time passes, but not enough for the Interest to expire
>>                     >>>>>> 4) Application generates data (e.g., from a sensor reading) that would
>>                     >>>>>> answer the Interest in the NFD PIT
>>                     >>>>>>
>>                     >>>>>> Question: How does app know to inform NFD it has the data after step 4,
>>                     >>>>>> and how should it do that?
>>                     >>>>>>
>>                     >>>>>> - In this type of app, should it push the data unsolicited to the NFD
>>                     >>>>>> and let it decide if there is something to do?
>>                     >>>>>
>>                     >>>>>
>>                     >>>>> In my opinion, as long as the application is certain that the Interest
>>                     >>>>> has arrived and is stored in NFD's PIT, it can just push the data out to
>>                     >>>>> NFD.
>>                     >>>>
>>                     >>>>
>>                     >>>>
>>                     >>>> How certain does it have to be?  There is a chance it could have
>>                     >>>> expired...
>>                     >>>> jeff
>>                     >>>>
>>                     >>>>
>>                     >>>>
>>                     >>>>
>>                     >>>>
>>                     >>>>>
>>                     >>>>> Wentao
>>                     >>>>>
>>                     >>>>>>
>>                     >>>>>> - Is it recommended to implement an application-level PIT so the app is
>>                     >>>>>> sure this data is solicited?  (Why add another PIT?)
>>                     >>>>>>
>>                     >>>>>> Thank you,
>>                     >>>>>> Jeff
>>                     >>>>>>
>>                     >>>>>> _________________________________________________
>>                     >>>>>> Nfd-dev mailing list
>>                     >>>>>>Nfd-dev at lists.cs.ucla.edu
>>                     <mailto:Nfd-dev at lists.cs.ucla.edu>
>>                     >>>>>>http://www.lists.cs.ucla.edu/__mailman/listinfo/nfd-dev
>>                     <http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev>
>>                     >>>>
>>                     >>>> _________________________________________________
>>                     >>>> Nfd-dev mailing list
>>                     >>>>Nfd-dev at lists.cs.ucla.edu
>>                     <mailto:Nfd-dev at lists.cs.ucla.edu>
>>                     >>>>http://www.lists.cs.ucla.edu/__mailman/listinfo/nfd-dev
>>                     <http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev>
>>                     >>>
>>                     >>>
>>                     >>>
>>                     >>> _________________________________________________
>>                     >>> Nfd-dev mailing list
>>                     >>>Nfd-dev at lists.cs.ucla.edu
>>                     <mailto:Nfd-dev at lists.cs.ucla.edu>
>>                     >>>http://www.lists.cs.ucla.edu/__mailman/listinfo/nfd-dev
>>                     <http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev>
>>                     >>>
>>                     > _________________________________________________
>>                     > Nfd-dev mailing list
>>                     >Nfd-dev at lists.cs.ucla.edu
>>                     <mailto:Nfd-dev at lists.cs.ucla.edu>
>>                     >http://www.lists.cs.ucla.edu/__mailman/listinfo/nfd-dev
>>                     <http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev>
>>
>>
>>                     _________________________________________________
>>                     Nfd-dev mailing list
>>                     Nfd-dev at lists.cs.ucla.edu
>>                     <mailto:Nfd-dev at lists.cs.ucla.edu>
>>                     http://www.lists.cs.ucla.edu/__mailman/listinfo/nfd-dev
>>                     <http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev>
>>
>>                 _______________________________________________
>>                 Nfd-dev mailing list
>>                 Nfd-dev at lists.cs.ucla.edu
>>                 <mailto:Nfd-dev at lists.cs.ucla.edu>
>>                 http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>         _______________________________________________ Nfd-dev mailing
>         list Nfd-dev at lists.cs.ucla.edu
>         <mailto:Nfd-dev at lists.cs.ucla.edu>
>         http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>     _________________________________________________
>     Nfd-dev mailing list
>     Nfd-dev at lists.cs.ucla.edu <mailto:Nfd-dev at lists.cs.ucla.edu>
>     http://www.lists.cs.ucla.edu/__mailman/listinfo/nfd-dev
>     <http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev>
>
>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>


From jburke at remap.UCLA.EDU  Wed Apr  1 11:01:05 2015
From: jburke at remap.UCLA.EDU (Burke, Jeff)
Date: Wed, 1 Apr 2015 18:01:05 +0000
Subject: [Nfd-dev] Handling new content in app for pending interest in
 NFD
In-Reply-To: <CAOFH+OZTwq13rYW137s86BaLog5uP_wCtpc4UwRZ6C_CHYORrw@mail.gmail.com>
Message-ID: <D1417F17.1C9DF2%jburke@remap.ucla.edu>

Hi Junxiao,

Thanks!  It would be great to summarize  such things in a design document somewhere rather than relying on the mailing list traffic / issues... Has the team considered this?

One question:  The approach suggested by these recommendations seems to be motivated by having the application's in-memory cache play the role of the content store...  I'm not sure that necessarily they have the same goals.  (I have to think about this more.) For example, the app may just want to support a modest history (last few seconds of video, for example), while the forwarder may have its own goals that result in caching more or less than this.   So is what you're describing on the level of an architectural recommendation or simply the best approach we have for now... ?

Jeff


From: Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>
Date: Wed, 1 Apr 2015 10:21:02 -0700
To: Jeff Burke <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>>
Cc: "nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>" <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: Re: [Nfd-dev] Handling new content in app for pending interest in NFD

Hi Jeff

The recommendation for "soft realtime app" is given below.
Please note that some features are not yet implemented, but the specifications are already approved.
Watch each listed feature for implementation progress.


The forwarder MUST NOT cache unsolicited Data, regardless of its origin.
Feature: http://redmine.named-data.net/issues/2181
Announcement: http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2014-November/000605.html

A soft realtime app MUST maintain an in-memory storage.
It MUST NOT rely on the forwarder to cache its Data, even if they are sent to the forwarder in response to an unexpired Interest.
The data structure is referred to as "in-memory storage" rather than "cache", because it SHOULD be fully managed by the app to keep all Data that the app wants to serve. It's not a cache where useful Data can be evicted.
Reason: the forwarder is free to evict any Data.

A soft realtime app SHOULD set CachingPolicy=NoCache in LocalControlHeader (or NDNLPv2 header) on a Data served from an in-memory storage.
The local forwarder ContentStore SHOULD NOT cache a Data with CachingPolicy=NoCache.
CachingPolicy field is not carried to remote forwarders, so that remote forwarders can still cache the Data. It avoids duplicate Data copies on localhost.
Protocol: http://redmine.named-data.net/projects/nfd/wiki/LocalControlHeader#CachingPolicy-feature
Feature: http://redmine.named-data.net/issues/2183 http://redmine.named-data.net/issues/2185 http://redmine.named-data.net/issues/2184

A soft realtime app MAY maintain its PIT to avoid sending unsolicited Data.
When an app chooses not to maintain a PIT, sending unsolicited Data has no harmful effect.



Yours, Junxiao

On Wed, Apr 1, 2015 at 8:38 AM, Burke, Jeff <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>> wrote:

Thanks for all of the discussion. I am not sure if I have been able to extract an answer to the original question I was asking.  Let me try again with more information:

- The original question was intended to be only about a local NFD (for now).
- The use case is a (soft) real-time application, like videoconferencing or streaming sensor data for interactive applications. Specifically, we have encountered the issue in 1) ndnrtc/ndncon<https://github.com/remap/ndncon/> for videoconferencing and 2) ndn-opt, which streams data from OpenPTrack<http://openptrack.org/>, a person tracking system built on the robot operating system (ROS).

- In these use cases, consumers want to receive data with low latency, so they send interests intended to arrive before the time the data is produced, but not so long before that the Interests expire before corresponding data is produced.

- As they are born, samples are signed and put into a repository by the publisher.  Currently these apps use an in-memory repo specific to the application, via the MemoryContentCache class provided by the NDN-CCL library. But this could just as well be a repo outside the application.

- So, when Interests arrive, they go in the local  NFD's PIT, and are forwarded to the application.   We are interested in the case where the data is not born yet, so the publisher cannot respond to the Interest.

- Then, before the Interest expires from the local NFD's PIT, the corresponding data is born in the application and should be used to answer the Interest.  But how does that data get back to the local forwarder?

- What should the application do?  1) Maintain its own PIT?   2) Or, push the data to the local NFD, letting it drop it if it doesn't satisfy anything.  3) Or, as we have previously discussed about the MemoryContentCache, do we need to consider a more sophisticated interaction model between the application and the daemon's content store and/or PIT that reduces duplication of these capabilities in applications?

- For now, we have implemented an in-application PIT in ndnrtc.  (I am not sure what method we ended up using in ndn-opt, perhaps the unsolicited data method.)

- Discussion on this topic will help inform what library support will be provided in the short term.  (I don't think we want every application author to have to write a PIT, so am thinking in the short term we should provide one to complement the MemoryContentCache class.  But this is duplicating data structures and functionality in NFD ? is that natural, or should we look to handle it through a different interaction with the local forwarder?)

Thanks,
Jeff

On Mon, Mar 30, 2015 at 10:28 AM, Burke, Jeff <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>> wrote:

Hi folks,

We are facing this scenario in a few applications:

1) Interest received by NFD, passed to an application
2) Application not able to respond to interest, so interest stays in NFD PIT
3) Some time passes, but not enough for the Interest to expire
4) Application generates data (e.g., from a sensor reading) that would answer the Interest in the NFD PIT

Question: How does app know to inform NFD it has the data after step 4, and how should it do that?

- In this type of app, should it push the data unsolicited to the NFD and let it decide if there is something to do?
- Is it recommended to implement an application-level PIT so the app is sure this data is solicited?  (Why add another PIT?)

Thank you,
Jeff

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150401/a8c42935/attachment.html>

From jburke at remap.UCLA.EDU  Wed Apr  1 11:04:01 2015
From: jburke at remap.UCLA.EDU (Burke, Jeff)
Date: Wed, 1 Apr 2015 18:04:01 +0000
Subject: [Nfd-dev] Handling new content in app for pending interest in
 NFD
In-Reply-To: <D4A62838-0237-4FEC-B0B1-EA33AD0A5D2F@cisco.com>
Message-ID: <D1418091.1C9E1E%jburke@remap.ucla.edu>

I can't speak for the other ndnvideo implementation (next-ndvideo) but
generally think that putting this type of content in a repo is a good
idea.  (The same issue I raised would exist, though.) We'll eventually use
a repo in ndnrtc, either in addition to or instead of the app cache, for
call recording - I think we didn't at first because we weren't sure about
the current implementation's impact on latency if it was the sole
mechanism used to publish the data.

Jeff


On 4/1/15, 10:21 AM, "Dave Oran (oran)" <oran at cisco.com> wrote:

>
>> On Apr 1, 2015, at 12:59 PM, Wentao Shang <wentaoshang at gmail.com> wrote:
>> 
>> I think this problem shows one limitation of in-memory cache (and repo
>>in general). The cache/repo is a "passive" storage: once the data gets
>>in, it never gets out unless someone explicitly request it.
>And why is that not exactly what you want? A place that can respond to
>interests without interrupting or otherwise causing thread scheduling
>problems for an application generating data open-loop.
>
>The repo is protected from infinite growth by the expiration time of the
>data. 
>
>> The applications, on the other hand, can be more "active" in deciding
>>when to send out data in response to previous interests.
>> 
>You;ll have to explain why this is a good thing? Can the application
>smooth jitter this way? Maybe. What other benefits might accrue?
>
>> I remember Illya and Lijing's ndnvideo implementation also needs to
>>handle similar problem. Their current solution (as far as I understand)
>>is to push out the data twice: once to the NFD for satisfying request,
>>once to the repo for archiving. The second push uses repo insertion
>>command so it's not just a plain data packet (like in the first push).
>> 
>Why not put everything into the repo and let the Repo respond to all
>interests? Is it the cost of context switches?
>
>Is it because the architectural model of the repo is that it had to have
>non-volatile backing store to survive host crashes which might be
>irrelevant for pure realtime applications (i.e. you don?t care about
>recordings).
>
>
>> Wentao
>> 
>> On Wed, Apr 1, 2015 at 8:38 AM Burke, Jeff <jburke at remap.ucla.edu>
>>wrote:
>> 
>> Thanks for all of the discussion. I am not sure if I have been able to
>>extract an answer to the original question I was asking.  Let me try
>>again with more information:
>> 
>> - The original question was intended to be only about a local NFD (for
>>now).
>> - The use case is a (soft) real-time application, like
>>videoconferencing or streaming sensor data for interactive applications.
>>Specifically, we have encountered the issue in 1) ndnrtc/ndncon for
>>videoconferencing and 2) ndn-opt, which streams data from OpenPTrack, a
>>person tracking system built on the robot operating system (ROS).
>> 
>> - In these use cases, consumers want to receive data with low latency,
>>so they send interests intended to arrive before the time the data is
>>produced, but not so long before that the Interests expire before
>>corresponding data is produced.
>> 
>> - As they are born, samples are signed and put into a repository by the
>>publisher.  Currently these apps use an in-memory repo specific to the
>>application, via the MemoryContentCache class provided by the NDN-CCL
>>library. But this could just as well be a repo outside the application.
>> 
>> - So, when Interests arrive, they go in the local  NFD's PIT, and are
>>forwarded to the application.   We are interested in the case where the
>>data is not born yet, so the publisher cannot respond to the Interest.
>> 
>> - Then, before the Interest expires from the local NFD's PIT, the
>>corresponding data is born in the application and should be used to
>>answer the Interest.  But how does that data get back to the local
>>forwarder? 
>> 
>> - What should the application do?  1) Maintain its own PIT?   2) Or,
>>push the data to the local NFD, letting it drop it if it doesn't satisfy
>>anything.  3) Or, as we have previously discussed about the
>>MemoryContentCache, do we need to consider a more sophisticated
>>interaction model between the application and the daemon's content store
>>and/or PIT that reduces duplication of these capabilities in
>>applications?   
>> 
>> - For now, we have implemented an in-application PIT in ndnrtc.  (I am
>>not sure what method we ended up using in ndn-opt, perhaps the
>>unsolicited data method.)
>> 
>> - Discussion on this topic will help inform what library support will
>>be provided in the short term.  (I don't think we want every application
>>author to have to write a PIT, so am thinking in the short term we
>>should provide one to complement the MemoryContentCache class.  But this
>>is duplicating data structures and functionality in NFD ? is that
>>natural, or should we look to handle it through a different interaction
>>with the local forwarder?)
>> 
>> Thanks,
>> Jeff
>> 
>> 
>> From: <Ignacio.Solis at parc.com>
>> Date: Tue, 31 Mar 2015 00:06:33 +0000
>> To: <wentaoshang at gmail.com>, <Marc.Mosko at parc.com>
>> 
>> Cc: <nfd-dev at lists.cs.ucla.edu>
>> Subject: Re: [Nfd-dev] Handling new content in app for pending interest
>>in NFD
>> 
>> I'm going to guess that caching data rules will be the same as
>>forwarding rules. If the interface is not allowed to produce that
>>content (due to routing / fib entries, local naming policy) data should
>>not be forwarded OR cached.
>> 
>> NDN has a slightly more complicated problem with caching than CCN given
>>then LPM matching rules.
>> 
>> If you have a repo that has permission to serve this content then you
>>changed the problem. Now you need the repo protocol to give you trust.
>> 
>> For regular forwarding you are relying on trusting routing. For local
>>apps you will rely (I assume)  on local permissions. For repo you will
>>need both of those plus now a repo permission  protocol.
>> 
>> Dropping unsolicited data may end up being your only recourse.
>> 
>> There are obviously other approaches for pre-populating caches that
>>involve higher level protocols, but I assume that's not what you're
>>talking about. 
>> 
>> Nacho (Ignacio) Solis
>> Principal Scientist
>> Palo Alto Research Center
>> 
>> From: Wentao Shang <wentaoshang at gmail.com>
>> Sent: Mar 30, 2015 4:50 PM
>> To: "Solis, Ignacio <Ignacio.Solis at parc.com>"
>><Ignacio.Solis at parc.com>;Mosko, Marc <Marc.Mosko at parc.com>
>> Cc: nfd-dev at lists.cs.ucla.edu
>> Subject: Re: [Nfd-dev] Handling new content in app for pending interest
>>in NFD
>> 
>> Hi Nacho,
>> 
>> I don't have any argument against this rule right now. But it seems
>>more relevant to "forwarding" data packets, while the problem we were
>>discussing is about "caching" unsolicited data packets, which cannot be
>>forwarded anyway because there is no PIT. The simplest solution I would
>>suggest to the problem is to drop any unsolicited data in the forwarder.
>> 
>> Wentao
>> 
>> On Mon, Mar 30, 2015 at 3:42 PM <Ignacio.Solis at parc.com> wrote:
>> This rule is important, router or not. You can't have "non-priviledged"
>> applications generating replies at servers. Specially important at
>>systems with multiple users,  tenants, virtual systems.
>> 
>> At the local router there are even more restrictions.  We haven't even
>>gotten to talking about privileged names and restrictions and end-h out
>>behavior.   We have a design  for this for CCN that we'll be talking
>>about at CCNxCon.
>> 
>> Nacho (Ignacio) Solis
>> Principal Scientist
>> Palo Alto Research Center
>> 
>> From: Wentao Shang <wentaoshang at gmail.com>
>> Sent: Mar 30, 2015 1:07 PM
>> To: Mosko, Marc <Marc.Mosko at parc.com>
>> 
>> Cc: nfd-dev at lists.cs.ucla.edu
>> Subject: Re: [Nfd-dev] Handling new content in app for pending interest
>>in NFD
>> 
>> On Mon, Mar 30, 2015 at 12:52 PM <Marc.Mosko at parc.com> wrote:
>> I?ll add that in addition to the content having a PIT entry, Nacho
>>Solis has suggested that a router should verify that a Content Object
>>came in a face from which it was requested.  Otherwise, there?s a
>>potential for off-path attacks sending content objects that match
>>popular well-known names.  A variation on that, rather than tracking
>>forward paths, would be to at minimum verify that a content object comes
>>from a face for which there?s a corresponding FIB entry for the name.
>> 
>> This requirement makes sense for transit routers that receive packets
>>from other routers. But I'm not sure whether this is necessary for
>>forwarding daemons handling local applications... The pushed data should
>>never get out of the local forwarder unless there is a PIT entry
>>specifying a path pointing to some other router.
>> 
>> Wentao
>>  
>> 
>> Marc
>> 
>> On Mar 30, 2015, at 12:08 PM, Wentao Shang <wentaoshang at gmail.com>
>>wrote:
>> 
>>> I agree with Dave.
>>> 
>>> In principle, router should not cache unsolicited data. In the
>>>situation we are discussing, the application should either just push
>>>the data out, which may be dropped by NFD if the interest has expired,
>>>or store the data in some application-level cache (or repo) for future
>>>fetching.
>>> 
>>> Wentao
>>> 
>>> On Mon, Mar 30, 2015 at 11:52 AM Dave Oran (oran) <oran at cisco.com>
>>>wrote:
>>> Isn?t this what the repo was invented for?
>>> 
>>> Holding packets in a router that has forgotten that they were asked
>>>for is a giant invitation to cache pollution/poisoning attacks.
>>> 
>>> > On Mar 30, 2015, at 2:24 PM, Haowei Yuan <hyuan at wustl.edu> wrote:
>>> >
>>> > I think as long as the data has actually been requested by an
>>>Interest
>>> > packet, it is safe to send the Data packet to NFD. The NFD will
>>>either
>>> > forward or drop the Data packet by checking if the Interest has
>>> > expired.
>>> >
>>> > If the Interest has expired, Data packet is dropped, and the consumer
>>> > is still interested in the data, the consumer could resend the
>>> > Interest. Hopefully this time, the Data packet can be generated and
>>> > sent faster by the application so that NFD will forward it.
>>> >
>>> > Haowei
>>> >
>>> >
>>> > On Mon, Mar 30, 2015 at 1:12 PM, Anil Jangam
>>><anilj.mailing at gmail.com> wrote:
>>> >>
>>> >> On Mar 30, 2015 11:08 AM, "Dehart, John" <jdd at wustl.edu> wrote:
>>> >>>
>>> >>>
>>> >>> Is there any harm in it pushing the data out without knowing for
>>>sure if
>>> >>> the
>>> >>> Interest is still active?
>>> >>>
>>> >> If data is so critical, can the Interest be refreshed proactively
>>>before it
>>> >> expires?
>>> >>
>>> >> /anil
>>> >>
>>> >>> John
>>> >>>
>>> >>>> On Mar 30, 2015, at 1:05 PM, Burke, Jeff <jburke at remap.ucla.edu>
>>>wrote:
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>>
>>> >>>>>
>>> >>>>> On Mon, Mar 30, 2015 at 10:28 AM Burke, Jeff
>>><jburke at remap.ucla.edu>
>>> >>>>> wrote:
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> Hi folks,
>>> >>>>>>
>>> >>>>>> We are facing this scenario in a few applications:
>>> >>>>>>
>>> >>>>>> 1) Interest received by NFD, passed to an application
>>> >>>>>> 2) Application not able to respond to interest, so interest
>>>stays in
>>> >>>>>> NFD PIT
>>> >>>>>> 3) Some time passes, but not enough for the Interest to expire
>>> >>>>>> 4) Application generates data (e.g., from a sensor reading)
>>>that would
>>> >>>>>> answer the Interest in the NFD PIT
>>> >>>>>>
>>> >>>>>> Question: How does app know to inform NFD it has the data after
>>>step 4,
>>> >>>>>> and how should it do that?
>>> >>>>>>
>>> >>>>>> - In this type of app, should it push the data unsolicited to
>>>the NFD
>>> >>>>>> and let it decide if there is something to do?
>>> >>>>>
>>> >>>>>
>>> >>>>> In my opinion, as long as the application is certain that the
>>>Interest
>>> >>>>> has arrived and is stored in NFD's PIT, it can just push the
>>>data out to
>>> >>>>> NFD.
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> How certain does it have to be?  There is a chance it could have
>>> >>>> expired...
>>> >>>> jeff
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>>
>>> >>>>> Wentao
>>> >>>>>
>>> >>>>>>
>>> >>>>>> - Is it recommended to implement an application-level PIT so
>>>the app is
>>> >>>>>> sure this data is solicited?  (Why add another PIT?)
>>> >>>>>>
>>> >>>>>> Thank you,
>>> >>>>>> Jeff
>>> >>>>>>
>>> >>>>>> _______________________________________________
>>> >>>>>> Nfd-dev mailing list
>>> >>>>>> Nfd-dev at lists.cs.ucla.edu
>>> >>>>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> Nfd-dev mailing list
>>> >>>> Nfd-dev at lists.cs.ucla.edu
>>> >>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>> >>>
>>> >>>
>>> >>>
>>> >>> _______________________________________________
>>> >>> Nfd-dev mailing list
>>> >>> Nfd-dev at lists.cs.ucla.edu
>>> >>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>> >>>
>>> > _______________________________________________
>>> > Nfd-dev mailing list
>>> > Nfd-dev at lists.cs.ucla.edu
>>> > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>> 
>>> 
>>> _______________________________________________
>>> Nfd-dev mailing list
>>> Nfd-dev at lists.cs.ucla.edu
>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>> _______________________________________________
>>> Nfd-dev mailing list
>>> Nfd-dev at lists.cs.ucla.edu
>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>> 
>> _______________________________________________ Nfd-dev mailing list
>>Nfd-dev at lists.cs.ucla.edu
>>http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>




From wentaoshang at gmail.com  Wed Apr  1 11:12:18 2015
From: wentaoshang at gmail.com (Wentao Shang)
Date: Wed, 01 Apr 2015 18:12:18 +0000
Subject: [Nfd-dev] Handling new content in app for pending interest in
	NFD
In-Reply-To: <551C31A4.6070702@cisco.com>
References: <6cae5fe4-c081-44da-ad7c-17b311ca2ccc@parc.com>
	<D1415A38.1C9BA2%jburke@remap.ucla.edu>
	<CAD4s1gQ2i3i48sNE3aDoqTHup7y_zV_WvWOzCVaUHC=OKCCEUQ@mail.gmail.com>
	<551C31A4.6070702@cisco.com>
Message-ID: <CAD4s1gRTsqjYW+AmhwHik6_h2B7y6N1Aj-aNJeoQvaB7HSqnFw@mail.gmail.com>

On Wed, Apr 1, 2015 at 10:57 AM Mark Stapp <mjs at cisco.com> wrote:

> Apologies for being a little ignorant about the 'repo' process. How does
> the local forwarder know whether to send an interest to the repo process
> or to the application process that 'registered' a particular name
> prefix? or does the repo process intermediate - somehow - between every
> application and the host's forwarder, by default, like a proxy? does the
> repo do exact-match on the names it sees, or something ... else?
>

Current implementation called 'repo-ng' is just a simple application and
doesn't have any interaction with other applications except receiving
commands and accepting data from them. The forwarder can decide where to
send the interest based on forwarding strategies (broadcast, best route,
etc.). The interest/data matching semantics is the same as what the content
store in NFD does (i.e., longest prefix matching, child selector, exclude,
...)

Wentao


>
> Thanks,
> Mark
>
> On 4/1/15 12:59 PM, Wentao Shang wrote:
> > I think this problem shows one limitation of in-memory cache (and repo
> > in general). The cache/repo is a "passive" storage: once the data gets
> > in, it never gets out unless someone explicitly request it. The
> > applications, on the other hand, can be more "active" in deciding when
> > to send out data in response to previous interests.
> >
> > I remember Illya and Lijing's ndnvideo implementation also needs to
> > handle similar problem. Their current solution (as far as I understand)
> > is to push out the data twice: once to the NFD for satisfying request,
> > once to the repo for archiving. The second push uses repo insertion
> > command so it's not just a plain data packet (like in the first push).
> >
> > Wentao
> >
> > On Wed, Apr 1, 2015 at 8:38 AM Burke, Jeff <jburke at remap.ucla.edu
> > <mailto:jburke at remap.ucla.edu>> wrote:
> >
> >
> >     Thanks for all of the discussion. I am not sure if I have been able
> >     to extract an answer to the original question I was asking.  Let me
> >     try again with more information:
> >
> >     - The original question was intended to be only about a local NFD
> >     (for now).
> >     - The use case is a (soft) real-time application, like
> >     videoconferencing or streaming sensor data for interactive
> >     applications. Specifically, we have encountered the issue in 1)
> >     ndnrtc/ndncon <https://github.com/remap/ndncon/> for
> >     videoconferencing and 2) ndn-opt, which streams data from OpenPTrack
> >     <http://openptrack.org/>, a person tracking system built on the
> >     robot operating system (ROS).
> >
> >     - In these use cases, consumers want to receive data with low
> >     latency, so they send interests intended to arrive before the time
> >     the data is produced, but not so long before that the Interests
> >     expire before corresponding data is produced.
> >
> >     - As they are born, samples are signed and put into a repository by
> >     the publisher.  Currently these apps use an in-memory repo specific
> >     to the application, via the MemoryContentCache class provided by the
> >     NDN-CCL library. But this could just as well be a repo outside the
> >     application.
> >
> >     - So, when Interests arrive, they go in the local  NFD's PIT, and
> >     are forwarded to the application.   We are interested in the case
> >     where the data is not born /yet/, so the publisher cannot respond to
> >     the Interest.
> >
> >     - Then, before the Interest expires from the local NFD's PIT, the
> >     corresponding data is born in the application and /should/ be used
> >     to answer the Interest.  But how does that data get back to the
> >     local forwarder?
> >
> >     - What should the application do?  1) Maintain its own PIT?   2) Or,
> >     push the data to the local NFD, letting it drop it if it doesn't
> >     satisfy anything.  3) Or, as we have previously discussed about the
> >     MemoryContentCache, do we need to consider a more sophisticated
> >     interaction model between the application and the daemon's content
> >     store and/or PIT that reduces duplication of these capabilities in
> >     applications?
> >
> >     - For now, we have implemented an in-application PIT in ndnrtc.  (I
> >     am not sure what method we ended up using in ndn-opt, perhaps the
> >     unsolicited data method.)
> >
> >     - Discussion on this topic will help inform what library support
> >     will be provided in the short term.  (I don't think we want every
> >     application author to have to write a PIT, so am thinking in the
> >     short term we should provide one to complement the
> >     MemoryContentCache class.  But this is duplicating data structures
> >     and functionality in NFD ? is that natural, or should we look to
> >     handle it through a different interaction with the local forwarder?)
> >
> >     Thanks,
> >     Jeff
> >
> >
> >     From: <Ignacio.Solis at parc.com <mailto:Ignacio.Solis at parc.com>>
> >     Date: Tue, 31 Mar 2015 00:06:33 +0000
> >     To: <wentaoshang at gmail.com <mailto:wentaoshang at gmail.com>>,
> >     <Marc.Mosko at parc.com <mailto:Marc.Mosko at parc.com>>
> >
> >     Cc: <nfd-dev at lists.cs.ucla.edu <mailto:nfd-dev at lists.cs.ucla.edu>>
> >     Subject: Re: [Nfd-dev] Handling new content in app for pending
> >     interest in NFD
> >
> >         I'm going to guess that caching data rules will be the same as
> >         forwarding rules. If the interface is not allowed to produce
> >         that content (due to routing / fib entries, local naming policy)
> >         data should not be forwarded OR cached.
> >
> >         NDN has a slightly more complicated problem with caching than
> >         CCN given then LPM matching rules.
> >
> >         If you have a repo that has permission to serve this content
> >         then you changed the problem. Now you need the repo protocol to
> >         give you trust.
> >
> >         For regular forwarding you are relying on trusting routing. For
> >         local apps you will rely (I assume)  on local permissions. For
> >         repo you will need both of those plus now a repo permission
> >           protocol.
> >
> >         Dropping unsolicited data may end up being your only recourse.
> >
> >         There are obviously other approaches for pre-populating caches
> >         that involve higher level protocols, but I assume that's not
> >         what you're talking about.
> >
> >         Nacho (Ignacio) Solis
> >         Principal Scientist
> >         Palo Alto Research Center
> >
> >         *From:* Wentao Shang <wentaoshang at gmail.com
> >         <mailto:wentaoshang at gmail.com>>
> >         *Sent:* Mar 30, 2015 4:50 PM
> >         *To:* "Solis, Ignacio <Ignacio.Solis at parc.com
> >         <mailto:Ignacio.Solis at parc.com>>" <Ignacio.Solis at parc.com
> >         <mailto:Ignacio.Solis at parc.com>>;Mosko, Marc
> >         <Marc.Mosko at parc.com <mailto:Marc.Mosko at parc.com>>
> >         *Cc:* nfd-dev at lists.cs.ucla.edu <mailto:nfd-dev at lists.cs.ucla.
> edu>
> >         *Subject:* Re: [Nfd-dev] Handling new content in app for pending
> >         interest in NFD
> >
> >         Hi Nacho,
> >
> >         I don't have any argument against this rule right now. But it
> >         seems more relevant to "forwarding" data packets, while the
> >         problem we were discussing is about "caching" unsolicited data
> >         packets, which cannot be forwarded anyway because there is no
> >         PIT. The simplest solution I would suggest to the problem is to
> >         drop any unsolicited data in the forwarder.
> >
> >         Wentao
> >
> >         On Mon, Mar 30, 2015 at 3:42 PM <Ignacio.Solis at parc.com
> >         <mailto:Ignacio.Solis at parc.com>> wrote:
> >
> >             This rule is important, router or not. You can't have
> >             "non-priviledged"  applications generating replies at
> >             servers. Specially important at systems with multiple users,
> >               tenants, virtual systems.
> >
> >             At the local router there are even more restrictions.  We
> >             haven't even gotten to talking about privileged names and
> >             restrictions and end-h out behavior.   We have a design  for
> >             this for CCN that we'll be talking about at CCNxCon.
> >
> >             Nacho (Ignacio) Solis
> >             Principal Scientist
> >             Palo Alto Research Center
> >
> >             *From:* Wentao Shang <wentaoshang at gmail.com
> >             <mailto:wentaoshang at gmail.com>>
> >             *Sent:* Mar 30, 2015 1:07 PM
> >             *To:* Mosko, Marc <Marc.Mosko at parc.com
> >             <mailto:Marc.Mosko at parc.com>>
> >
> >             *Cc:* nfd-dev at lists.cs.ucla.edu
> >             <mailto:nfd-dev at lists.cs.ucla.edu>
> >             *Subject:* Re: [Nfd-dev] Handling new content in app for
> >             pending interest in NFD
> >
> >             On Mon, Mar 30, 2015 at 12:52 PM <Marc.Mosko at parc.com
> >             <mailto:Marc.Mosko at parc.com>> wrote:
> >
> >                 I?ll add that in addition to the content having a PIT
> >                 entry, Nacho Solis has suggested that a router should
> >                 verify that a Content Object came in a face from which
> >                 it was requested.  Otherwise, there?s a potential for
> >                 off-path attacks sending content objects that match
> >                 popular well-known names.  A variation on that, rather
> >                 than tracking forward paths, would be to at minimum
> >                 verify that a content object comes from a face for which
> >                 there?s a corresponding FIB entry for the name.
> >
> >
> >             This requirement makes sense for transit routers that
> >             receive packets from other routers. But I'm not sure whether
> >             this is necessary for forwarding daemons handling local
> >             applications... The pushed data should never get out of the
> >             local forwarder unless there is a PIT entry specifying a
> >             path pointing to some other router.
> >
> >             Wentao
> >
> >
> >                 Marc
> >
> >                 On Mar 30, 2015, at 12:08 PM, Wentao Shang
> >                 <wentaoshang at gmail.com <mailto:wentaoshang at gmail.com>>
> >                 wrote:
> >
> >>                 I agree with Dave.
> >>
> >>                 In principle, router should not cache unsolicited
> >>                 data. In the situation we are discussing, the
> >>                 application should either just push the data out,
> >>                 which may be dropped by NFD if the interest has
> >>                 expired, or store the data in some application-level
> >>                 cache (or repo) for future fetching.
> >>
> >>                 Wentao
> >>
> >>                 On Mon, Mar 30, 2015 at 11:52 AM Dave Oran (oran)
> >>                 <oran at cisco.com <mailto:oran at cisco.com>> wrote:
> >>
> >>                     Isn?t this what the repo was invented for?
> >>
> >>                     Holding packets in a router that has forgotten
> >>                     that they were asked for is a giant invitation to
> >>                     cache pollution/poisoning attacks.
> >>
> >>                     > On Mar 30, 2015, at 2:24 PM, Haowei Yuan <
> hyuan at wustl.edu <mailto:hyuan at wustl.edu>> wrote:
> >>                     >
> >>                     > I think as long as the data has actually been
> requested by an Interest
> >>                     > packet, it is safe to send the Data packet to
> NFD. The NFD will either
> >>                     > forward or drop the Data packet by checking if
> the Interest has
> >>                     > expired.
> >>                     >
> >>                     > If the Interest has expired, Data packet is
> dropped, and the consumer
> >>                     > is still interested in the data, the consumer
> could resend the
> >>                     > Interest. Hopefully this time, the Data packet
> can be generated and
> >>                     > sent faster by the application so that NFD will
> forward it.
> >>                     >
> >>                     > Haowei
> >>                     >
> >>                     >
> >>                     > On Mon, Mar 30, 2015 at 1:12 PM, Anil Jangam <
> anilj.mailing at gmail.com
> >>                     <mailto:anilj.mailing at gmail.com>> wrote:
> >>                     >>
> >>                     >> On Mar 30, 2015 11:08 AM, "Dehart, John" <
> jdd at wustl.edu <mailto:jdd at wustl.edu>> wrote:
> >>                     >>>
> >>                     >>>
> >>                     >>> Is there any harm in it pushing the data out
> without knowing for sure if
> >>                     >>> the
> >>                     >>> Interest is still active?
> >>                     >>>
> >>                     >> If data is so critical, can the Interest be
> refreshed proactively before it
> >>                     >> expires?
> >>                     >>
> >>                     >> /anil
> >>                     >>
> >>                     >>> John
> >>                     >>>
> >>                     >>>> On Mar 30, 2015, at 1:05 PM, Burke, Jeff <
> jburke at remap.ucla.edu
> >>                     <mailto:jburke at remap.ucla.edu>> wrote:
> >>                     >>>>
> >>                     >>>>
> >>                     >>>>
> >>                     >>>>>
> >>                     >>>>>
> >>                     >>>>> On Mon, Mar 30, 2015 at 10:28 AM Burke, Jeff <
> jburke at remap.ucla.edu <mailto:jburke at remap.ucla.edu>>
> >>                     >>>>> wrote:
> >>                     >>>>>>
> >>                     >>>>>>
> >>                     >>>>>> Hi folks,
> >>                     >>>>>>
> >>                     >>>>>> We are facing this scenario in a few
> applications:
> >>                     >>>>>>
> >>                     >>>>>> 1) Interest received by NFD, passed to an
> application
> >>                     >>>>>> 2) Application not able to respond to
> interest, so interest stays in
> >>                     >>>>>> NFD PIT
> >>                     >>>>>> 3) Some time passes, but not enough for the
> Interest to expire
> >>                     >>>>>> 4) Application generates data (e.g., from a
> sensor reading) that would
> >>                     >>>>>> answer the Interest in the NFD PIT
> >>                     >>>>>>
> >>                     >>>>>> Question: How does app know to inform NFD it
> has the data after step 4,
> >>                     >>>>>> and how should it do that?
> >>                     >>>>>>
> >>                     >>>>>> - In this type of app, should it push the
> data unsolicited to the NFD
> >>                     >>>>>> and let it decide if there is something to
> do?
> >>                     >>>>>
> >>                     >>>>>
> >>                     >>>>> In my opinion, as long as the application is
> certain that the Interest
> >>                     >>>>> has arrived and is stored in NFD's PIT, it
> can just push the data out to
> >>                     >>>>> NFD.
> >>                     >>>>
> >>                     >>>>
> >>                     >>>>
> >>                     >>>> How certain does it have to be?  There is a
> chance it could have
> >>                     >>>> expired...
> >>                     >>>> jeff
> >>                     >>>>
> >>                     >>>>
> >>                     >>>>
> >>                     >>>>
> >>                     >>>>
> >>                     >>>>>
> >>                     >>>>> Wentao
> >>                     >>>>>
> >>                     >>>>>>
> >>                     >>>>>> - Is it recommended to implement an
> application-level PIT so the app is
> >>                     >>>>>> sure this data is solicited?  (Why add
> another PIT?)
> >>                     >>>>>>
> >>                     >>>>>> Thank you,
> >>                     >>>>>> Jeff
> >>                     >>>>>>
> >>                     >>>>>> ______________________________
> ___________________
> >>                     >>>>>> Nfd-dev mailing list
> >>                     >>>>>>Nfd-dev at lists.cs.ucla.edu
> >>                     <mailto:Nfd-dev at lists.cs.ucla.edu>
> >>                     >>>>>>http://www.lists.cs.
> ucla.edu/__mailman/listinfo/nfd-dev
> >>                     <http://www.lists.cs.ucla.edu/
> mailman/listinfo/nfd-dev>
> >>                     >>>>
> >>                     >>>> ______________________________
> ___________________
> >>                     >>>> Nfd-dev mailing list
> >>                     >>>>Nfd-dev at lists.cs.ucla.edu
> >>                     <mailto:Nfd-dev at lists.cs.ucla.edu>
> >>                     >>>>http://www.lists.cs.ucla.
> edu/__mailman/listinfo/nfd-dev
> >>                     <http://www.lists.cs.ucla.edu/
> mailman/listinfo/nfd-dev>
> >>                     >>>
> >>                     >>>
> >>                     >>>
> >>                     >>> ______________________________
> ___________________
> >>                     >>> Nfd-dev mailing list
> >>                     >>>Nfd-dev at lists.cs.ucla.edu
> >>                     <mailto:Nfd-dev at lists.cs.ucla.edu>
> >>                     >>>http://www.lists.cs.ucla.
> edu/__mailman/listinfo/nfd-dev
> >>                     <http://www.lists.cs.ucla.edu/
> mailman/listinfo/nfd-dev>
> >>                     >>>
> >>                     > _________________________________________________
> >>                     > Nfd-dev mailing list
> >>                     >Nfd-dev at lists.cs.ucla.edu
> >>                     <mailto:Nfd-dev at lists.cs.ucla.edu>
> >>                     >http://www.lists.cs.ucla.edu/
> __mailman/listinfo/nfd-dev
> >>                     <http://www.lists.cs.ucla.edu/
> mailman/listinfo/nfd-dev>
> >>
> >>
> >>                     _________________________________________________
> >>                     Nfd-dev mailing list
> >>                     Nfd-dev at lists.cs.ucla.edu
> >>                     <mailto:Nfd-dev at lists.cs.ucla.edu>
> >>                     http://www.lists.cs.ucla.edu/_
> _mailman/listinfo/nfd-dev
> >>                     <http://www.lists.cs.ucla.edu/
> mailman/listinfo/nfd-dev>
> >>
> >>                 _______________________________________________
> >>                 Nfd-dev mailing list
> >>                 Nfd-dev at lists.cs.ucla.edu
> >>                 <mailto:Nfd-dev at lists.cs.ucla.edu>
> >>                 http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
> >
> >         _______________________________________________ Nfd-dev mailing
> >         list Nfd-dev at lists.cs.ucla.edu
> >         <mailto:Nfd-dev at lists.cs.ucla.edu>
> >         http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
> >
> >     _________________________________________________
> >     Nfd-dev mailing list
> >     Nfd-dev at lists.cs.ucla.edu <mailto:Nfd-dev at lists.cs.ucla.edu>
> >     http://www.lists.cs.ucla.edu/__mailman/listinfo/nfd-dev
> >     <http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev>
> >
> >
> >
> > _______________________________________________
> > Nfd-dev mailing list
> > Nfd-dev at lists.cs.ucla.edu
> > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150401/f8469bce/attachment.html>

From davide.pesavento at lip6.fr  Wed Apr  1 11:16:03 2015
From: davide.pesavento at lip6.fr (Davide Pesavento)
Date: Wed, 1 Apr 2015 20:16:03 +0200
Subject: [Nfd-dev] Ethernet Multicast in NFD
In-Reply-To: <1C6C5C13-4AAE-42B8-BC1E-C684F45C9EFB@umass.edu>
References: <1C6C5C13-4AAE-42B8-BC1E-C684F45C9EFB@umass.edu>
Message-ID: <CADfzvvZcCEs_d-sFOExF8NumgnsY4_a2qm85Sagj2tgWBW6F1g@mail.gmail.com>

Hi Divyashri,

Use the faceId instead of the faceUri in the `nfdc register ...`
command, and repeat the command for each of the 4 EthernetFace IDs you
have.

Question for Alex/Junxiao: nfdc's FaceIdFetcher returns only 1 faceId
in case multiple faces match the specified faceUri. Is this intended
behavior or a bug?

Thanks,
Davide

On Wed, Apr 1, 2015 at 7:57 PM, Divyashri Bhat <dbhat at umass.edu> wrote:
> Hi,
>
> I am trying to use the broadcast strategy in a testbed setup in Ubuntu 12.04 VMs.
>
> The corresponding entry in my config file:
>
> ether
>   {
>     ; Ethernet multicast settings
>     ; NFD creates one Ethernet multicast face per NIC
>     mcast yes ; set to 'no' to disable Ethernet multicast, default 'yes'
>     mcast_group 01:00:5E:00:17:AA ; Ethernet multicast group
>   }
>
> As far as I understand, when I run the following command, I should see corresponding FIB entries for all Ethernet faces.
>
> sudo nfdc register /test/pingserver ether://[01:00:5e:00:17:aa]
>
>
> However, I have 4 ethernet faces and my nfd-status result looks like this:
>
>   faceid=256 remote=ether://[01:00:5e:00:17:aa] local=dev://eth3 counters={in={185i 0d 11698B} out={0i 0d 0B}} non-local persistent multi-access
>   faceid=257 remote=ether://[01:00:5e:00:17:aa] local=dev://eth2 counters={in={0i 0d 0B} out={0i 0d 0B}} non-local persistent multi-access
>   faceid=258 remote=ether://[01:00:5e:00:17:aa] local=dev://eth1 counters={in={0i 0d 0B} out={0i 0d 0B}} non-local persistent multi-access
>   faceid=259 remote=ether://[01:00:5e:00:17:aa] local=dev://eth0 counters={in={0i 0d 0B} out={0i 0d 0B}} non-local persistent multi-access
>   faceid=260 remote=fd://23 local=unix:///run/nfd.sock counters={in={50i 7d 7511B} out={7i 29d 16632B}} local on-demand point-to-point
>   faceid=271 remote=fd://26 local=unix:///run/nfd.sock counters={in={3i 0d 137B} out={0i 2d 858B}} local on-demand point-to-point
> FIB:
>   /localhost/nfd nexthops={faceid=1 (cost=0)}
>   /test/pingserver nexthops={faceid=256 (cost=0)}
>   /localhost/nfd/rib nexthops={faceid=260 (cost=0)}
> RIB:
>   /localhost/nfd/rib route={faceid=260 (origin=0 cost=0 ChildInherit)}
>   /test/pingserver route={faceid=256 (origin=255 cost=0 ChildInherit)}
> Strategy choices:
>   /localhost/nfd strategy=/localhost/nfd/strategy/broadcast/%FD%01
>   /ndn/broadcast strategy=/localhost/nfd/strategy/broadcast/%FD%01
>   /localhost strategy=/localhost/nfd/strategy/broadcast/%FD%01
>   /test/pingserver strategy=/localhost/nfd/strategy/broadcast/%FD%01
>   / strategy=/localhost/nfd/strategy/broadcast/%FD%01
>
> How can I broadcast this Interest on all Ethernet faces?
>
> Could you help me understand what I am missing here?
>
> Thank you
>
> Regards,
> Divyashri Bhat
> dbhat at umass.edu<mailto:dbhat at umass.edu>
> Graduate Student
> Department of Electrical and Computer Engineering,
> University of Massachusetts, Amherst
>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev


From Marc.Mosko at parc.com  Wed Apr  1 11:47:24 2015
From: Marc.Mosko at parc.com (Marc.Mosko at parc.com)
Date: Wed, 1 Apr 2015 18:47:24 +0000
Subject: [Nfd-dev] Handling new content in app for pending interest
	in	NFD
In-Reply-To: <CAD4s1gRTsqjYW+AmhwHik6_h2B7y6N1Aj-aNJeoQvaB7HSqnFw@mail.gmail.com>
References: <6cae5fe4-c081-44da-ad7c-17b311ca2ccc@parc.com>
	<D1415A38.1C9BA2%jburke@remap.ucla.edu>
	<CAD4s1gQ2i3i48sNE3aDoqTHup7y_zV_WvWOzCVaUHC=OKCCEUQ@mail.gmail.com>
	<551C31A4.6070702@cisco.com>
	<CAD4s1gRTsqjYW+AmhwHik6_h2B7y6N1Aj-aNJeoQvaB7HSqnFw@mail.gmail.com>
Message-ID: <3F52A7DF-73F5-4FF5-9904-1FACF5A26519@parc.com>

There?s a big difference between an app using a repo that is across a forwarder vs the MemoryContentCache that is populated via API calls (as is my understanding).  If using a repo across a forwarder, the forwarder would automatically have pending interests in a PIT and could satisfy them when the producer pushes data in to the repo.  This is not the case with the InMemoryCache.

I think the an app should not have to worry about a shadow PIT.  The MemoryContentCache should take care of that functionality.  In fact, the MemoryContentCache might be the only thing serving the onInterest Callback for the registered face, so the app wouldn?t necessarily even see the interests.   I?ve only looked at the API docs, so my understanding of the MemoryContentCache might be off.

As a historical note, the 0.8 ccnx code used the former method, where the repo was across a forwarder, so it would get ?automatic? interest satisfaction of data sent to the repo because it used a call-home model (so long as the interest from the repo was not aggregated with the interest from the remote, otherwise it would have to timeout).

In regards to some of the previous comments about latency, etc., my understanding (from the API) is that the MemoryContentCache operates in the same thread as the application, and one must periodically crank the handle via a processEvents call.  I guess really it operates in the same thread as whatever calls processEvents.  But, I have no real experience with multi-threaded NDN apps, so someone else might address this.

Marc

On Apr 1, 2015, at 11:12 AM, Wentao Shang <wentaoshang at gmail.com<mailto:wentaoshang at gmail.com>> wrote:



On Wed, Apr 1, 2015 at 10:57 AM Mark Stapp <mjs at cisco.com<mailto:mjs at cisco.com>> wrote:
Apologies for being a little ignorant about the 'repo' process. How does
the local forwarder know whether to send an interest to the repo process
or to the application process that 'registered' a particular name
prefix? or does the repo process intermediate - somehow - between every
application and the host's forwarder, by default, like a proxy? does the
repo do exact-match on the names it sees, or something ... else?

Current implementation called 'repo-ng' is just a simple application and doesn't have any interaction with other applications except receiving commands and accepting data from them. The forwarder can decide where to send the interest based on forwarding strategies (broadcast, best route, etc.). The interest/data matching semantics is the same as what the content store in NFD does (i.e., longest prefix matching, child selector, exclude, ...)

Wentao


Thanks,
Mark

On 4/1/15 12:59 PM, Wentao Shang wrote:
> I think this problem shows one limitation of in-memory cache (and repo
> in general). The cache/repo is a "passive" storage: once the data gets
> in, it never gets out unless someone explicitly request it. The
> applications, on the other hand, can be more "active" in deciding when
> to send out data in response to previous interests.
>
> I remember Illya and Lijing's ndnvideo implementation also needs to
> handle similar problem. Their current solution (as far as I understand)
> is to push out the data twice: once to the NFD for satisfying request,
> once to the repo for archiving. The second push uses repo insertion
> command so it's not just a plain data packet (like in the first push).
>
> Wentao
>
> On Wed, Apr 1, 2015 at 8:38 AM Burke, Jeff <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>
> <mailto:jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>>> wrote:
>
>
>     Thanks for all of the discussion. I am not sure if I have been able
>     to extract an answer to the original question I was asking.  Let me
>     try again with more information:
>
>     - The original question was intended to be only about a local NFD
>     (for now).
>     - The use case is a (soft) real-time application, like
>     videoconferencing or streaming sensor data for interactive
>     applications. Specifically, we have encountered the issue in 1)
>     ndnrtc/ndncon <https://github.com/remap/ndncon/> for
>     videoconferencing and 2) ndn-opt, which streams data from OpenPTrack
>     <http://openptrack.org/>, a person tracking system built on the
>     robot operating system (ROS).
>
>     - In these use cases, consumers want to receive data with low
>     latency, so they send interests intended to arrive before the time
>     the data is produced, but not so long before that the Interests
>     expire before corresponding data is produced.
>
>     - As they are born, samples are signed and put into a repository by
>     the publisher.  Currently these apps use an in-memory repo specific
>     to the application, via the MemoryContentCache class provided by the
>     NDN-CCL library. But this could just as well be a repo outside the
>     application.
>
>     - So, when Interests arrive, they go in the local  NFD's PIT, and
>     are forwarded to the application.   We are interested in the case
>     where the data is not born /yet/, so the publisher cannot respond to
>     the Interest.
>
>     - Then, before the Interest expires from the local NFD's PIT, the
>     corresponding data is born in the application and /should/ be used
>     to answer the Interest.  But how does that data get back to the
>     local forwarder?
>
>     - What should the application do?  1) Maintain its own PIT?   2) Or,
>     push the data to the local NFD, letting it drop it if it doesn't
>     satisfy anything.  3) Or, as we have previously discussed about the
>     MemoryContentCache, do we need to consider a more sophisticated
>     interaction model between the application and the daemon's content
>     store and/or PIT that reduces duplication of these capabilities in
>     applications?
>
>     - For now, we have implemented an in-application PIT in ndnrtc.  (I
>     am not sure what method we ended up using in ndn-opt, perhaps the
>     unsolicited data method.)
>
>     - Discussion on this topic will help inform what library support
>     will be provided in the short term.  (I don't think we want every
>     application author to have to write a PIT, so am thinking in the
>     short term we should provide one to complement the
>     MemoryContentCache class.  But this is duplicating data structures
>     and functionality in NFD ? is that natural, or should we look to
>     handle it through a different interaction with the local forwarder?)
>
>     Thanks,
>     Jeff
>
>
>     From: <Ignacio.Solis at parc.com<mailto:Ignacio.Solis at parc.com> <mailto:Ignacio.Solis at parc.com<mailto:Ignacio.Solis at parc.com>>>
>     Date: Tue, 31 Mar 2015 00:06:33 +0000
>     To: <wentaoshang at gmail.com<mailto:wentaoshang at gmail.com> <mailto:wentaoshang at gmail.com<mailto:wentaoshang at gmail.com>>>,
>     <Marc.Mosko at parc.com<mailto:Marc.Mosko at parc.com> <mailto:Marc.Mosko at parc.com<mailto:Marc.Mosko at parc.com>>>
>
>     Cc: <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu> <mailto:nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>>
>     Subject: Re: [Nfd-dev] Handling new content in app for pending
>     interest in NFD
>
>         I'm going to guess that caching data rules will be the same as
>         forwarding rules. If the interface is not allowed to produce
>         that content (due to routing / fib entries, local naming policy)
>         data should not be forwarded OR cached.
>
>         NDN has a slightly more complicated problem with caching than
>         CCN given then LPM matching rules.
>
>         If you have a repo that has permission to serve this content
>         then you changed the problem. Now you need the repo protocol to
>         give you trust.
>
>         For regular forwarding you are relying on trusting routing. For
>         local apps you will rely (I assume)  on local permissions. For
>         repo you will need both of those plus now a repo permission
>           protocol.
>
>         Dropping unsolicited data may end up being your only recourse.
>
>         There are obviously other approaches for pre-populating caches
>         that involve higher level protocols, but I assume that's not
>         what you're talking about.
>
>         Nacho (Ignacio) Solis
>         Principal Scientist
>         Palo Alto Research Center
>
>         *From:* Wentao Shang <wentaoshang at gmail.com<mailto:wentaoshang at gmail.com>
>         <mailto:wentaoshang at gmail.com<mailto:wentaoshang at gmail.com>>>
>         *Sent:* Mar 30, 2015 4:50 PM
>         *To:* "Solis, Ignacio <Ignacio.Solis at parc.com<mailto:Ignacio.Solis at parc.com>
>         <mailto:Ignacio.Solis at parc.com<mailto:Ignacio.Solis at parc.com>>>" <Ignacio.Solis at parc.com<mailto:Ignacio.Solis at parc.com>
>         <mailto:Ignacio.Solis at parc.com<mailto:Ignacio.Solis at parc.com>>>;Mosko, Marc
>         <Marc.Mosko at parc.com<mailto:Marc.Mosko at parc.com> <mailto:Marc.Mosko at parc.com<mailto:Marc.Mosko at parc.com>>>
>         *Cc:* nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu> <mailto:nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
>         *Subject:* Re: [Nfd-dev] Handling new content in app for pending
>         interest in NFD
>
>         Hi Nacho,
>
>         I don't have any argument against this rule right now. But it
>         seems more relevant to "forwarding" data packets, while the
>         problem we were discussing is about "caching" unsolicited data
>         packets, which cannot be forwarded anyway because there is no
>         PIT. The simplest solution I would suggest to the problem is to
>         drop any unsolicited data in the forwarder.
>
>         Wentao
>
>         On Mon, Mar 30, 2015 at 3:42 PM <Ignacio.Solis at parc.com<mailto:Ignacio.Solis at parc.com>
>         <mailto:Ignacio.Solis at parc.com<mailto:Ignacio.Solis at parc.com>>> wrote:
>
>             This rule is important, router or not. You can't have
>             "non-priviledged"  applications generating replies at
>             servers. Specially important at systems with multiple users,
>               tenants, virtual systems.
>
>             At the local router there are even more restrictions.  We
>             haven't even gotten to talking about privileged names and
>             restrictions and end-h out behavior.   We have a design  for
>             this for CCN that we'll be talking about at CCNxCon.
>
>             Nacho (Ignacio) Solis
>             Principal Scientist
>             Palo Alto Research Center
>
>             *From:* Wentao Shang <wentaoshang at gmail.com<mailto:wentaoshang at gmail.com>
>             <mailto:wentaoshang at gmail.com<mailto:wentaoshang at gmail.com>>>
>             *Sent:* Mar 30, 2015 1:07 PM
>             *To:* Mosko, Marc <Marc.Mosko at parc.com<mailto:Marc.Mosko at parc.com>
>             <mailto:Marc.Mosko at parc.com<mailto:Marc.Mosko at parc.com>>>
>
>             *Cc:* nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>
>             <mailto:nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
>             *Subject:* Re: [Nfd-dev] Handling new content in app for
>             pending interest in NFD
>
>             On Mon, Mar 30, 2015 at 12:52 PM <Marc.Mosko at parc.com<mailto:Marc.Mosko at parc.com>
>             <mailto:Marc.Mosko at parc.com<mailto:Marc.Mosko at parc.com>>> wrote:
>
>                 I?ll add that in addition to the content having a PIT
>                 entry, Nacho Solis has suggested that a router should
>                 verify that a Content Object came in a face from which
>                 it was requested.  Otherwise, there?s a potential for
>                 off-path attacks sending content objects that match
>                 popular well-known names.  A variation on that, rather
>                 than tracking forward paths, would be to at minimum
>                 verify that a content object comes from a face for which
>                 there?s a corresponding FIB entry for the name.
>
>
>             This requirement makes sense for transit routers that
>             receive packets from other routers. But I'm not sure whether
>             this is necessary for forwarding daemons handling local
>             applications... The pushed data should never get out of the
>             local forwarder unless there is a PIT entry specifying a
>             path pointing to some other router.
>
>             Wentao
>
>
>                 Marc
>
>                 On Mar 30, 2015, at 12:08 PM, Wentao Shang
>                 <wentaoshang at gmail.com<mailto:wentaoshang at gmail.com> <mailto:wentaoshang at gmail.com<mailto:wentaoshang at gmail.com>>>
>                 wrote:
>
>>                 I agree with Dave.
>>
>>                 In principle, router should not cache unsolicited
>>                 data. In the situation we are discussing, the
>>                 application should either just push the data out,
>>                 which may be dropped by NFD if the interest has
>>                 expired, or store the data in some application-level
>>                 cache (or repo) for future fetching.
>>
>>                 Wentao
>>
>>                 On Mon, Mar 30, 2015 at 11:52 AM Dave Oran (oran)
>>                 <oran at cisco.com<mailto:oran at cisco.com> <mailto:oran at cisco.com<mailto:oran at cisco.com>>> wrote:
>>
>>                     Isn?t this what the repo was invented for?
>>
>>                     Holding packets in a router that has forgotten
>>                     that they were asked for is a giant invitation to
>>                     cache pollution/poisoning attacks.
>>
>>                     > On Mar 30, 2015, at 2:24 PM, Haowei Yuan <hyuan at wustl.edu<mailto:hyuan at wustl.edu> <mailto:hyuan at wustl.edu<mailto:hyuan at wustl.edu>>> wrote:
>>                     >
>>                     > I think as long as the data has actually been requested by an Interest
>>                     > packet, it is safe to send the Data packet to NFD. The NFD will either
>>                     > forward or drop the Data packet by checking if the Interest has
>>                     > expired.
>>                     >
>>                     > If the Interest has expired, Data packet is dropped, and the consumer
>>                     > is still interested in the data, the consumer could resend the
>>                     > Interest. Hopefully this time, the Data packet can be generated and
>>                     > sent faster by the application so that NFD will forward it.
>>                     >
>>                     > Haowei
>>                     >
>>                     >
>>                     > On Mon, Mar 30, 2015 at 1:12 PM, Anil Jangam <anilj.mailing at gmail.com<mailto:anilj.mailing at gmail.com>
>>                     <mailto:anilj.mailing at gmail.com<mailto:anilj.mailing at gmail.com>>> wrote:
>>                     >>
>>                     >> On Mar 30, 2015 11:08 AM, "Dehart, John" <jdd at wustl.edu<mailto:jdd at wustl.edu> <mailto:jdd at wustl.edu<mailto:jdd at wustl.edu>>> wrote:
>>                     >>>
>>                     >>>
>>                     >>> Is there any harm in it pushing the data out without knowing for sure if
>>                     >>> the
>>                     >>> Interest is still active?
>>                     >>>
>>                     >> If data is so critical, can the Interest be refreshed proactively before it
>>                     >> expires?
>>                     >>
>>                     >> /anil
>>                     >>
>>                     >>> John
>>                     >>>
>>                     >>>> On Mar 30, 2015, at 1:05 PM, Burke, Jeff <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>
>>                     <mailto:jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>>> wrote:
>>                     >>>>
>>                     >>>>
>>                     >>>>
>>                     >>>>>
>>                     >>>>>
>>                     >>>>> On Mon, Mar 30, 2015 at 10:28 AM Burke, Jeff <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu> <mailto:jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>>>
>>                     >>>>> wrote:
>>                     >>>>>>
>>                     >>>>>>
>>                     >>>>>> Hi folks,
>>                     >>>>>>
>>                     >>>>>> We are facing this scenario in a few applications:
>>                     >>>>>>
>>                     >>>>>> 1) Interest received by NFD, passed to an application
>>                     >>>>>> 2) Application not able to respond to interest, so interest stays in
>>                     >>>>>> NFD PIT
>>                     >>>>>> 3) Some time passes, but not enough for the Interest to expire
>>                     >>>>>> 4) Application generates data (e.g., from a sensor reading) that would
>>                     >>>>>> answer the Interest in the NFD PIT
>>                     >>>>>>
>>                     >>>>>> Question: How does app know to inform NFD it has the data after step 4,
>>                     >>>>>> and how should it do that?
>>                     >>>>>>
>>                     >>>>>> - In this type of app, should it push the data unsolicited to the NFD
>>                     >>>>>> and let it decide if there is something to do?
>>                     >>>>>
>>                     >>>>>
>>                     >>>>> In my opinion, as long as the application is certain that the Interest
>>                     >>>>> has arrived and is stored in NFD's PIT, it can just push the data out to
>>                     >>>>> NFD.
>>                     >>>>
>>                     >>>>
>>                     >>>>
>>                     >>>> How certain does it have to be?  There is a chance it could have
>>                     >>>> expired...
>>                     >>>> jeff
>>                     >>>>
>>                     >>>>
>>                     >>>>
>>                     >>>>
>>                     >>>>
>>                     >>>>>
>>                     >>>>> Wentao
>>                     >>>>>
>>                     >>>>>>
>>                     >>>>>> - Is it recommended to implement an application-level PIT so the app is
>>                     >>>>>> sure this data is solicited?  (Why add another PIT?)
>>                     >>>>>>
>>                     >>>>>> Thank you,
>>                     >>>>>> Jeff
>>                     >>>>>>
>>                     >>>>>> _________________________________________________
>>                     >>>>>> Nfd-dev mailing list
>>                     >>>>>>Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
>>                     <mailto:Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>>
>>                     >>>>>>http://www.lists.cs.ucla.edu/__mailman/listinfo/nfd-dev
>>                     <http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev>
>>                     >>>>
>>                     >>>> _________________________________________________
>>                     >>>> Nfd-dev mailing list
>>                     >>>>Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
>>                     <mailto:Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>>
>>                     >>>>http://www.lists.cs.ucla.edu/__mailman/listinfo/nfd-dev
>>                     <http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev>
>>                     >>>
>>                     >>>
>>                     >>>
>>                     >>> _________________________________________________
>>                     >>> Nfd-dev mailing list
>>                     >>>Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
>>                     <mailto:Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>>
>>                     >>>http://www.lists.cs.ucla.edu/__mailman/listinfo/nfd-dev
>>                     <http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev>
>>                     >>>
>>                     > _________________________________________________
>>                     > Nfd-dev mailing list
>>                     >Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
>>                     <mailto:Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>>
>>                     >http://www.lists.cs.ucla.edu/__mailman/listinfo/nfd-dev
>>                     <http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev>
>>
>>
>>                     _________________________________________________
>>                     Nfd-dev mailing list
>>                     Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
>>                     <mailto:Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>>
>>                     http://www.lists.cs.ucla.edu/__mailman/listinfo/nfd-dev
>>                     <http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev>
>>
>>                 _______________________________________________
>>                 Nfd-dev mailing list
>>                 Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
>>                 <mailto:Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>>
>>                 http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>         _______________________________________________ Nfd-dev mailing
>         list Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
>         <mailto:Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>>
>         http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>     _________________________________________________
>     Nfd-dev mailing list
>     Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu> <mailto:Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>>
>     http://www.lists.cs.ucla.edu/__mailman/listinfo/nfd-dev
>     <http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev>
>
>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
_______________________________________________
Nfd-dev mailing list
Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150401/42c1d008/attachment.html>

From shijunxiao at email.arizona.edu  Wed Apr  1 15:30:13 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Wed, 1 Apr 2015 15:30:13 -0700
Subject: [Nfd-dev] Ethernet Multicast in NFD
In-Reply-To: <CADfzvvZcCEs_d-sFOExF8NumgnsY4_a2qm85Sagj2tgWBW6F1g@mail.gmail.com>
References: <1C6C5C13-4AAE-42B8-BC1E-C684F45C9EFB@umass.edu>
	<CADfzvvZcCEs_d-sFOExF8NumgnsY4_a2qm85Sagj2tgWBW6F1g@mail.gmail.com>
Message-ID: <CAOFH+OaY9uJ2uDsn7yDNqJ0XXXNRfn=Tzsz5B_8HheoSXA_03Q@mail.gmail.com>

Hi Davide

FaceIdFetcher returning only one face is by design.

nfdc manpage says for "register" sub-command:

Register *a* new or update existing routing entry in Routing Information
Base (RIB).


The word "a" indicates that only one route will be installed.
So it's correct to use one face only.

Yours, Junxiao

On Wed, Apr 1, 2015 at 11:16 AM, Davide Pesavento <davide.pesavento at lip6.fr>
wrote:

> Question for Alex/Junxiao: nfdc's FaceIdFetcher returns only 1 faceId
> in case multiple faces match the specified faceUri. Is this intended
> behavior or a bug?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150401/3272f227/attachment.html>

From dbhat at umass.EDU  Wed Apr  1 16:23:45 2015
From: dbhat at umass.EDU (Divyashri Bhat)
Date: Wed, 1 Apr 2015 23:23:45 +0000
Subject: [Nfd-dev] Ethernet Multicast in NFD
In-Reply-To: <CAOFH+OaY9uJ2uDsn7yDNqJ0XXXNRfn=Tzsz5B_8HheoSXA_03Q@mail.gmail.com>
References: <1C6C5C13-4AAE-42B8-BC1E-C684F45C9EFB@umass.edu>
	<CADfzvvZcCEs_d-sFOExF8NumgnsY4_a2qm85Sagj2tgWBW6F1g@mail.gmail.com>
	<CAOFH+OaY9uJ2uDsn7yDNqJ0XXXNRfn=Tzsz5B_8HheoSXA_03Q@mail.gmail.com>
Message-ID: <CAC007FF-FDA4-4FB3-AA9A-DD284918450B@umass.edu>

Hi Davide,

Thanks for that. It works now.

Junxiao, I have a ?multicast? Ethernet group in the config. All my Ethernet faces belong to that group. If I have to manually register each face, what is the significance of the group in this context?

Thank you.
Regards,
Divyashri Bhat
dbhat at umass.edu<mailto:dbhat at umass.edu>
Graduate Student
Department of Electrical and Computer Engineering,
University of Massachusetts, Amherst

On 1 Apr 2015, at 18:30, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:

Hi Davide

FaceIdFetcher returning only one face is by design.

nfdc manpage says for "register" sub-command:
Register a new or update existing routing entry in Routing Information Base (RIB).

The word "a" indicates that only one route will be installed.
So it's correct to use one face only.

Yours, Junxiao

On Wed, Apr 1, 2015 at 11:16 AM, Davide Pesavento <davide.pesavento at lip6.fr<mailto:davide.pesavento at lip6.fr>> wrote:
Question for Alex/Junxiao: nfdc's FaceIdFetcher returns only 1 faceId
in case multiple faces match the specified faceUri. Is this intended
behavior or a bug?




From philoliang2011 at gmail.com  Wed Apr  1 16:09:31 2015
From: philoliang2011 at gmail.com (Teng Liang)
Date: Wed, 1 Apr 2015 16:09:31 -0700
Subject: [Nfd-dev] HOWTO: clone the NFD repository
In-Reply-To: <CAOFH+OaZpYUQ_8ny_or5nwR6kWE8stYYCSUTSHXTG1RcQYCVeA@mail.gmail.com>
References: <CAOFH+OaZpYUQ_8ny_or5nwR6kWE8stYYCSUTSHXTG1RcQYCVeA@mail.gmail.com>
Message-ID: <CA+LWhLvPr8WKHwvAvkQ5bGQd1vy6VeETQ_yAUwRUuONm3Gx=HQ@mail.gmail.com>

Hi Junxiao,

I ran into a problem at the step 6. I've already added my ssh-rsa public
key, but I can only see anonymous HTTP clone instead of "git clone ssh:/".

[image: Inline image 1]
Thanks,
Teng



On Sat, Mar 28, 2015 at 12:43 PM, Junxiao Shi <shijunxiao at email.arizona.edu>
wrote:

> Dear folks
>
> I got question on how to clone the NFD repository for development purpose.
> Here's the procedure:
>
>    1. in a web browser, navigate to http://gerrit.named-data.net
>    2. click "Sign In" link on top-right corner, click "Google OAuth2",
>    and then authenticate with your Google Account
>    3. after you are redirected back to Gerrit system, click "Projects -
>    List" menu item on top navigate bar
>    4. type "NFD" in "Filter" textbox
>    5. click "NFD" table row
>    6. under "Project NFD" title, click "clone with commit-msg hook" and
>    "SSH" buttons
>    7. find the textbox below "clone with commit-msg hook" (it should
>    start with "git clone ssh:/")
>    8. the contents in this textbox is the complete command line needed to
>    clone the NFD repository
>
> Note: the development machine must have git and openssh-client installed.
>
> Yours, Junxiao
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150401/1c306a42/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 13084 bytes
Desc: not available
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150401/1c306a42/attachment.png>

From shijunxiao at email.arizona.edu  Thu Apr  2 10:37:24 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Thu, 2 Apr 2015 10:37:24 -0700
Subject: [Nfd-dev] HOWTO: clone the NFD repository
In-Reply-To: <CAOFH+OaZpYUQ_8ny_or5nwR6kWE8stYYCSUTSHXTG1RcQYCVeA@mail.gmail.com>
References: <CAOFH+OaZpYUQ_8ny_or5nwR6kWE8stYYCSUTSHXTG1RcQYCVeA@mail.gmail.com>
Message-ID: <CAOFH+OanZxwDm6Fvv_Sonh+O+FWx3fDri7UtHjavGmw_xVaBmw@mail.gmail.com>

Dear folks

I got question on how to clone the NFD repository for development purpose.
Here's the updated procedure: (Thanks Teng Liang for reporting a problem in
the procedure sent on Mar 28)

   1. in a web browser, navigate to http://gerrit.named-data.net
   2. click "Sign In" link on top-right corner, click "Google OAuth2"
   3. authenticate with your Google Account, and then you will be
   redirected back to Gerrit system
   4. click your name on top-right corner, and click "Settings" in the
   pop-up box
   5. look for a "Username" textbox; if there's no such textbox, but a
   username is displayed, goto step 7
   6. in the "Username" textbox, type a username (syntax: a letter,
   followed by letters or numbers), and click "Select" button, confirm
   7. click "SSH Public Keys" menu item on left navigation bar
   8. look for multi-line textbox below "Add SSH Public Key"; if there's no
   such textbox, but a table is displayed, goto step 10
   9. paste your SSH public key, and click "Add" button
   10. click "Projects - List" menu item on top navigation bar
   11. type "NFD" in "Filter" textbox
   12. click "NFD" table row
   13. under "Project NFD" title, click "clone with commit-msg hook" and
   "SSH" buttons
   14. find the textbox below "clone with commit-msg hook" (it should start
   with "git clone ssh:/")
   15. the contents in this textbox is the complete command line needed to
   clone the NFD repository


Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150402/209d2ac2/attachment.html>

From jburke at remap.UCLA.EDU  Sat Apr  4 10:24:17 2015
From: jburke at remap.UCLA.EDU (Burke, Jeff)
Date: Sat, 4 Apr 2015 17:24:17 +0000
Subject: [Nfd-dev] Behavior of "on demand" faces to applications
In-Reply-To: <D1384101.1C3B48%jburke@remap.ucla.edu>
Message-ID: <D1456B5F.1CD0B3%jburke@remap.ucla.edu>


For what it's worth ? the initial project that clued us into this need is (I think) the first public art sculpture using NDN. :)

This object is supposed to stay up-and-running on its own for the next year or so.  (I've mentioned it before but it officially launched last night.)  We are using NDN to fetch bus arrival data, and when we upgrade to Raspberry PI 2 controllers, will switch back to NDN for lighting control (changed to UDP for now to get refresh rates needed).

[cid:0965EEAB-17F6-45CC-B467-7FE4BA4D683C]



From: Jeff Burke <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>>
Date: Wed, 25 Mar 2015 18:04:16 +0000
To: Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>
Cc: "nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>" <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>, "Horn, Alex" <nano at remap.UCLA.EDU<mailto:nano at remap.UCLA.EDU>>, John DeHart <jdd at seas.wustl.edu<mailto:jdd at seas.wustl.edu>>
Subject: Re: [Nfd-dev] Behavior of "on demand" faces to applications

Hi Junxiao,

Thanks, this is very helpful. (@AlexH: We should probably implement this for all the permanent routes on borges & memoria.)

I have added an issue<http://redmine.named-data.net/issues/2696> in redmine to document face creation/destruction behavior ? this is something that should be easily understood by anyone deploying a multi-node application in a semi-real-world environment.

As Lan points out in issue 2491<http://redmine.named-data.net/issues/2491>, not having "permanent" faces creates deployment challenges.

I would suggest that the NFD team make permanent face support (for any underlying transport) a high priority for implementation, and easily selected?even perhaps the default?in routes created by 'nfdc register'.

Given that we try to use UDP wherever possible (so as not to create an invisible crutch of ordering and reliability for apps deployed on top), support for permanent UDP faces is actually higher for us than TCP, though both are used.

A few use cases on our end:

- We have a few Raspberry PIs deployed in an outdoor installation, which connect to each other via a wire and use NDN over UDP to communicate. One has a WiFi connection to the campus network, and uses NDN over TCP to get data from a remote process.    Occasionally, we restart one of the NFDs and not the other.  Also, occasionally, we have brief dropouts of wireless connectivity to the campus network.   In both cases, we lose the NDN faces and lose uptime of something that's supposed to run continuously.  While  Junxiao's approach provides a solution, it involves running additional components, etc.   Given that we are running out of time on that project, I'm probably going to remove NDN communication because of this and some performance issues on the PIs.  Better would be if NFD itself handled intermittent connectivity losses more robustly as proposed in the "permanent face".

- We have now a small number of persistent services (which we are trying to increase) that are designed to run unattended for long periods of time. (e.g., the ndnfs publisher for ndn content).  This would be very useful to have.  While the TCP connections are more stable, we are always upgrading / restarting versions of NFD, adding routes, etc.  So a low-overhead way of having permanent routes would be extremely helpful.

The "permanent" behavior seems to be the most typically desired for any manually registered routes ? whether for the lifetime of the NFD daemon (in the nfdc-created case) or the lifetime of an application process (in the app-created case).    I hope this can be considered for implementation soon...

Thanks!!
Jeff





From: Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>
Date: Sat, 21 Mar 2015 14:04:41 -0700
To: Jeff Burke <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>>
Cc: Alex Afanasyev <alexander.afanasyev at ucla.edu<mailto:alexander.afanasyev at ucla.edu>>, "Gusev, Peter" <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>>, "nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>" <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: Re: [Nfd-dev] Behavior of "on demand" faces to applications

Hi Jeff

A
A persistent TCP face is considered failed when TCP connection is broken. There's no built-in way to re-establish the connection and routes.
#2491<http://redmine.named-data.net/issues/2491> will provide the concept of permanent face which does exactly that: TCP connection is re-established after it's broken, and FaceId remains unchanged. This is still in early idea stage.

The workaround used by NDN6.TK<http://yoursunny.com/p/ndn6/> is:

  1.  use facemon<https://github.com/yoursunny/ndn6-tools/blob/master/facemon.md> to monitor face destroy events
  2.  pipe the output of facemon to an awk script
  3.  in the awk script, if the face to the uplink router is destroyed, invoke nfdc register to re-establish the face and register static routes

I'm attaching the awk script for reference.

B
A persistent UDP unicast face is considered failed when it receives an ICMP error. During the restart of remote NFD, if local NFD sends a UDP packet and gets back an ICMP error, the face will be destryoed; if local NFD doesn't send during this period, the face should be intact.
As I remember, this behavior dates back to May 2014, and hasn't been significantly changed since then.

You may use iptables to block incoming ICMP PortUnreachable error to avoid face getting destroy.
Otherwise, the workaround above is also effective.

Yours, Junxiao

On Sat, Mar 21, 2015 at 1:44 PM, Burke, Jeff <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>> wrote:
Alex / nfd folks,

We're going to make sure local connections are through unix sockets whenever available.

Two quick related questions.  Feel free to send a RTFM pointer:

#A -
- Is there a built-in way for "persistent" routes to get re-established if the TCP connection goes down?   I interpreted your original description to mean this is not the default behavior.

#B -
In the case of UDP faces, what happens in this situation:

1. nfdc is used to register (with a local NFD) a persistent UDP face for a remote NFD
2. The face is created successfully
3. The remote NFD is killed and then restarted

Is the intended behavior that the face created in #1 is still up after #3?   (And, has this been the case in all versions of NFD?  I am debugging a problem on an installation running an older version of NFD on the Raspberry PI.)

Thanks!
Jeff

_______________________________________________ Nfd-dev mailing list Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150404/2105cfbf/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot 2015-04-04 10.19.38.png
Type: image/png
Size: 294223 bytes
Desc: Screenshot 2015-04-04 10.19.38.png
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150404/2105cfbf/attachment.png>

From wentaoshang at gmail.com  Sat Apr  4 15:20:03 2015
From: wentaoshang at gmail.com (Wentao Shang)
Date: Sat, 04 Apr 2015 22:20:03 +0000
Subject: [Nfd-dev] Behavior of "on demand" faces to applications
In-Reply-To: <D1456B5F.1CD0B3%jburke@remap.ucla.edu>
References: <D1384101.1C3B48%jburke@remap.ucla.edu>
	<D1456B5F.1CD0B3%jburke@remap.ucla.edu>
Message-ID: <CAD4s1gTBbc4kQgueNZF1vi5c=Ckji7LahZNwMeuY2_BT7+JLOQ@mail.gmail.com>

Awesome! Nice work :)

Wentao

On Sat, Apr 4, 2015 at 10:24 AM Burke, Jeff <jburke at remap.ucla.edu> wrote:

>
>  For what it's worth ? the initial project that clued us into this need
> is (I think) the first public art sculpture using NDN. :)
>
>  This object is supposed to stay up-and-running on its own for the next
> year or so.  (I've mentioned it before but it officially launched last
> night.)  We are using NDN to fetch bus arrival data, and when we upgrade to
> Raspberry PI 2 controllers, will switch back to NDN for lighting control
> (changed to UDP for now to get refresh rates needed).
>
>
>
>
>   From: Jeff Burke <jburke at remap.ucla.edu>
> Date: Wed, 25 Mar 2015 18:04:16 +0000
> To: Junxiao Shi <shijunxiao at email.arizona.edu>
> Cc: "nfd-dev at lists.cs.ucla.edu" <nfd-dev at lists.cs.ucla.edu>, "Horn, Alex"
> <nano at remap.UCLA.EDU>, John DeHart <jdd at seas.wustl.edu>
>
> Subject: Re: [Nfd-dev] Behavior of "on demand" faces to applications
>
>   Hi Junxiao,
>
>  Thanks, this is very helpful. (@AlexH: We should probably implement this
> for all the permanent routes on borges & memoria.)
>
>  I have added an issue <http://redmine.named-data.net/issues/2696> in
> redmine to document face creation/destruction behavior ? this is something
> that should be easily understood by anyone deploying a multi-node
> application in a semi-real-world environment.
>
>  As Lan points out in issue 2491
> <http://redmine.named-data.net/issues/2491>, not having "permanent" faces
> creates deployment challenges.
>
>  I would suggest that the NFD team make permanent face support (for any
> underlying transport) a high priority for implementation, and easily
> selected?even perhaps the default?in routes created by 'nfdc register'.
>
>  Given that we try to use UDP wherever possible (so as not to create an
> invisible crutch of ordering and reliability for apps deployed on top),
> support for permanent UDP faces is actually higher for us than TCP, though
> both are used.
>
>  A few use cases on our end:
>
>  - We have a few Raspberry PIs deployed in an outdoor installation, which
> connect to each other via a wire and use NDN over UDP to communicate. One
> has a WiFi connection to the campus network, and uses NDN over TCP to get
> data from a remote process.    Occasionally, we restart one of the NFDs and
> not the other.  Also, occasionally, we have brief dropouts of wireless
> connectivity to the campus network.   In both cases, we lose the NDN faces
> and lose uptime of something that's supposed to run continuously.  While
>  Junxiao's approach provides a solution, it involves running additional
> components, etc.   Given that we are running out of time on that project,
> I'm probably going to remove NDN communication because of this and some
> performance issues on the PIs.  Better would be if NFD itself handled
> intermittent connectivity losses more robustly as proposed in the
> "permanent face".
>
>  - We have now a small number of persistent services (which we are trying
> to increase) that are designed to run unattended for long periods of time.
> (e.g., the ndnfs publisher for ndn content).  This would be very useful to
> have.  While the TCP connections are more stable, we are always upgrading /
> restarting versions of NFD, adding routes, etc.  So a low-overhead way of
> having permanent routes would be extremely helpful.
>
>  The "permanent" behavior seems to be the most typically desired for any
> manually registered routes ? whether for the lifetime of the NFD daemon (in
> the nfdc-created case) or the lifetime of an application process (in the
> app-created case).    I hope this can be considered for implementation
> soon...
>
>  Thanks!!
> Jeff
>
>
>
>
>
>   From: Junxiao Shi <shijunxiao at email.arizona.edu>
> Date: Sat, 21 Mar 2015 14:04:41 -0700
> To: Jeff Burke <jburke at remap.ucla.edu>
> Cc: Alex Afanasyev <alexander.afanasyev at ucla.edu>, "Gusev, Peter" <
> peter at remap.ucla.edu>, "nfd-dev at lists.cs.ucla.edu" <
> nfd-dev at lists.cs.ucla.edu>
> Subject: Re: [Nfd-dev] Behavior of "on demand" faces to applications
>
>  Hi Jeff
>
>  A
> A *persistent* TCP face is considered *failed* when TCP connection is
> broken. There's no built-in way to re-establish the connection and routes.
>  #2491 <http://redmine.named-data.net/issues/2491> will provide the
> concept of *permanent* face which does exactly that: TCP connection is
> re-established after it's broken, and FaceId remains unchanged. This is
> still in early idea stage.
>
>  The workaround used by NDN6.TK <http://yoursunny.com/p/ndn6/> is:
>
>    1. use facemon
>    <https://github.com/yoursunny/ndn6-tools/blob/master/facemon.md> to
>    monitor face destroy events
>    2. pipe the output of facemon to an awk script
>    3. in the awk script, if the face to the uplink router is destroyed,
>    invoke nfdc register to re-establish the face and register static
>    routes
>
> I'm attaching the awk script for reference.
>
>  B
>  A *persistent* UDP unicast face is considered *failed* when it receives
> an ICMP error. During the restart of remote NFD, if local NFD sends a UDP
> packet and gets back an ICMP error, the face will be destryoed; if local
> NFD doesn't send during this period, the face should be intact.
> As I remember, this behavior dates back to May 2014, and hasn't been
> significantly changed since then.
>
>  You may use iptables to block incoming ICMP PortUnreachable error to
> avoid face getting destroy.
> Otherwise, the workaround above is also effective.
>
>  Yours, Junxiao
>
> On Sat, Mar 21, 2015 at 1:44 PM, Burke, Jeff <jburke at remap.ucla.edu>
> wrote:
>
>>  Alex / nfd folks,
>>
>>  We're going to make sure local connections are through unix sockets
>> whenever available.
>>
>>  Two quick related questions.  Feel free to send a RTFM pointer:
>>
>>  #A -
>> - Is there a built-in way for "persistent" routes to get re-established
>> if the TCP connection goes down?   I interpreted your original description
>> to mean this is not the default behavior.
>>
>>  #B -
>> In the case of UDP faces, what happens in this situation:
>>
>>  1. nfdc is used to register (with a local NFD) a persistent UDP face
>> for a remote NFD
>> 2. The face is created successfully
>> 3. The remote NFD is killed and then restarted
>>
>>  Is the intended behavior that the face created in #1 is still up after
>> #3?   (And, has this been the case in all versions of NFD?  I am debugging
>> a problem on an installation running an older version of NFD on the
>> Raspberry PI.)
>>
>>  Thanks!
>> Jeff
>>
>>      _______________________________________________ Nfd-dev mailing
> list Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>  _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150404/1b4eb0ff/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot 2015-04-04 10.19.38.png
Type: image/png
Size: 294223 bytes
Desc: not available
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150404/1b4eb0ff/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot 2015-04-04 10.19.38.png
Type: image/png
Size: 294223 bytes
Desc: not available
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150404/1b4eb0ff/attachment-0001.png>

From diegownogueira at gmail.com  Fri Apr 10 06:14:41 2015
From: diegownogueira at gmail.com (=?UTF-8?Q?Diego_Jos=C3=A9_Welsing_Nogueira?=)
Date: Fri, 10 Apr 2015 10:14:41 -0300
Subject: [Nfd-dev] NFD on OpenWRT
Message-ID: <CAMYWomyzpeqBG+LDH=aJGX=rXu5WTXiceFt8v001rSp=O4xJxQ@mail.gmail.com>

Hello everyone,
I am beginner in the list and if possible would like a help from you.
I am now willing to install the NFD in OpenWRT. I followed the steps in
accordance with the link(
http://redmine.named-data.net/projects/ndn-embedded/wiki/Cross-compiling_NDN_projects_for_home_routers#DD-WRT-source-and-toolchain).
>From these steps it was possible to generate the cross compile the ndn-cxx,
however I am having trouble copying the packages for OpenWRT.

How do I copy and run the cross compile packages in OpenWRT?

Could help me at this stage?

Thank you.

-- 

*Diego Jos? Welsing Nogueira*
Cel.: +55 (27) 9 8889-0804
Lattes:http://lattes.cnpq.br/3710760972037978
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150410/73849098/attachment.html>

From gibmat at cs.ARIZONA.EDU  Fri Apr 10 09:28:51 2015
From: gibmat at cs.ARIZONA.EDU (Mathias Gibbens)
Date: Fri, 10 Apr 2015 16:28:51 +0000
Subject: [Nfd-dev] NFD on OpenWRT
In-Reply-To: <CAFxh1C9Aiy2RO2AQVZO4KRvQ3JSkdRYt-OnHREP5Dd8KqDyupA@mail.gmail.com>
References: <CAMYWomyzpeqBG+LDH=aJGX=rXu5WTXiceFt8v001rSp=O4xJxQ@mail.gmail.com>
	<CAFxh1C9Aiy2RO2AQVZO4KRvQ3JSkdRYt-OnHREP5Dd8KqDyupA@mail.gmail.com>
Message-ID: <1428683331.29832.90.camel@olorin.calenhad.com>

Hello Diego,

  I'm the author of the wiki page you referenced. What error(s) /
problem are you encountering when trying to cross-compile ndn-cxx and
NFD for OpenWrt?

  If you're just wondering about how to copy the resulting
libraries/binaries to your router, you need to copy the contents of
~/NFD-crosscompile to your router. The wiki page doesn't cover that,
since there are so many ways (USB drives, scp, package managers, etc).
Personally, I have a USB drive auto-mounted on my router that has
ndn-cxx and NFD on it from which I run the NDN software.

Mathias
(please CC me, since I'm not subscribed to this list)

> ---------- Forwarded message ----------
> From: "Diego Jos? Welsing Nogueira" <diegownogueira at gmail.com>
> Date: Apr 10, 2015 8:27 AM
> Subject: [Nfd-dev] NFD on OpenWRT
> To: <nfd-dev at lists.cs.ucla.edu>
> Cc:
> 
> Hello everyone,
> I am beginner in the list and if possible would like a help from you.
> I am now willing to install the NFD in OpenWRT. I followed the steps in
> accordance with the link(
> http://redmine.named-data.net/projects/ndn-embedded/wiki/Cross-compiling_NDN_projects_for_home_routers#DD-WRT-source-and-toolchain).
> From these steps it was possible to generate the cross compile the ndn-cxx,
> however I am having trouble copying the packages for OpenWRT.
> 
> How do I copy and run the cross compile packages in OpenWRT?
> 
> Could help me at this stage?
> 
> Thank you.
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150410/d9e3619d/attachment.bin>

From klaus.schneider at uni-bamberg.de  Sun Apr 12 06:23:06 2015
From: klaus.schneider at uni-bamberg.de (Klaus Schneider)
Date: Sun, 12 Apr 2015 15:23:06 +0200
Subject: [Nfd-dev] strategy specific parameters
Message-ID: <552A71BA.3090407@uni-bamberg.de>

Hi everyone,

I think it would be a good idea to have (optional) parameters for a 
forwarding strategy in order to make the design more flexible.

The CCNx prototype supports this:

> ccndc setstrategy <prefix> <strategy> [<parameters> [<lifetime>]]

Unfortunately, there is currently no such option in NFD:

> nfdc set-strategy <namespace> <strategy-name>


If you think this is reasonable, I can help with the implementation. I 
am also not sure if this is the right place for such feature requests or 
if I should put them up as a redmine ticket?

Thanks,
Klaus


-- 
Klaus Schneider

Mail: klaus.schneider at uni-bamberg.de
LinkedIn: https://www.linkedin.com/in/schneiderklaus


From klaus.schneider at uni-bamberg.de  Mon Apr 13 05:12:58 2015
From: klaus.schneider at uni-bamberg.de (Klaus Schneider)
Date: Mon, 13 Apr 2015 14:12:58 +0200
Subject: [Nfd-dev] strategy specific parameters
Message-ID: <552BB2CA.1020806@uni-bamberg.de>

One immediate application example is to give the Broadcast Strategy a 
parameter that states if it should send out Interests with a new nonce.

A new nonce allows the broadcasted Interests to travel different paths 
with overlapping nodes (or reaching the same content source) without 
being dropped by the duplicate nonce detection. This small alteration 
can be very useful when the duplicate Interests are used to compensate 
for link problems (delay, loss) on one of the paths.

Best regards.


> Hi everyone,
>
> I think it would be a good idea to have (optional) parameters for a
> forwarding strategy in order to make the design more flexible.
>
> The CCNx prototype supports this:
>
>> ccndc setstrategy <prefix> <strategy> [<parameters> [<lifetime>]]
>
> Unfortunately, there is currently no such option in NFD:
>
>> nfdc set-strategy <namespace> <strategy-name>
>
>
> If you think this is reasonable, I can help with the implementation. I
> am also not sure if this is the right place for such feature requests or
> if I should put them up as a redmine ticket?
>
> Thanks,
> Klaus

-- 
Klaus Schneider

Mail: klaus.schneider at uni-bamberg.de
LinkedIn: https://www.linkedin.com/in/schneiderklaus



From mahyuddin at gmail.com  Mon Apr 13 03:06:11 2015
From: mahyuddin at gmail.com (Mahyuddin Husairi)
Date: Mon, 13 Apr 2015 18:06:11 +0800
Subject: [Nfd-dev] NLSR failed to connect with NFD in Banana Pro (Raspbian
	OS)
Message-ID: <CAA5Vy7RwA-0kZsSKvu+bqv+45aS0+wN_f+K963+Ez2d0eAh0DA@mail.gmail.com>

I just successfully compile and install ndn-cxx, NFD and NLSR on Banana Pro
(design and produced by LeMaker - http://www.lemaker.org/).

I can run NFD as usual and create face and register prefix using nfdc.
After that i run several test using ndn-tlv-ping and ndn-traffic and
everything is run smoothly.

The problem is, when i run NLSR, it will simply throw error message "ERROR:
error while connecting to the forwarder" even though NFD is running. In
nlsr log file it is just simply throw the same error message "ERROR: error
while connecting to the forwarder". Something like below


20150413175010040 DEBUG: [HelloProtocol] Scheduling HELLO Interests in 10
seconds
20150413175010047 DEBUG: [nlsr] Process daemonized. Process id: 14975
20150413175010053 FATAL: [Main] ERROR: error while connecting to the
forwarder
20150413175010057 DEBUG: [Fib] Fib::clean called


Seems like it will crash once NLSR start to setup Hello protocol schedule.
So, because of lack of details in NLSR log message i tried strace to run
NLSR and the output from strace are something like this


gettimeofday({1428918610, 40666}, NULL) = 0
write(10, "20150413175010040 DEBUG: [HelloP"..., 82) = 82
clock_gettime(CLOCK_MONOTONIC, {367502, 38604022}) = 0
clock_gettime(CLOCK_MONOTONIC, {367502, 39270498}) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0xb4cbc288) = 14975
gettimeofday({1428918610, 47614}, NULL) = 0
write(10, "20150413175010047 DEBUG: [nlsr] "..., 70) = 70
close(9)                                = 0
close(10)                               = 0
ERROR: error while connecting to the forwardermunmap(0xb6f5a000, 8192)
           = 0


I'm using the same NFD and NLSR configuration setup that i successfully run
on my ubuntu desktop. Is that related to libboost_random (boost library
version is 1.49) or probably because Banana Pro is not using real hardware
clock? I'm just clueless.


-- 
Human knowledge Belongs to The World
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150413/61a6da2d/attachment.html>

From lanwang at memphis.edu  Mon Apr 13 07:53:15 2015
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Mon, 13 Apr 2015 14:53:15 +0000
Subject: [Nfd-dev] NLSR failed to connect with NFD in Banana Pro
	(Raspbian	OS)
In-Reply-To: <CAA5Vy7RwA-0kZsSKvu+bqv+45aS0+wN_f+K963+Ez2d0eAh0DA@mail.gmail.com>
References: <CAA5Vy7RwA-0kZsSKvu+bqv+45aS0+wN_f+K963+Ez2d0eAh0DA@mail.gmail.com>
Message-ID: <BB7514AB-4476-4C13-97A8-BE0F86B5D3A9@memphis.edu>

Not sure what's the problem.  Just some info and

- Somehow NLSR has difficulty getting connected with NFD.  It needs to send Interest and receive Data through that face.  If I understand correctly, they use UNIX socket to connect by default (and there's a default file name corresponding to the UNIX socket in the NFD configuration).

- Where did you download NLSR?  The GitHub version https://github.com/named-data/NLSR  is the latest.  Were there any warnings or problems during the compile and installation?

Lan

On Apr 13, 2015, at 5:06 AM, Mahyuddin Husairi <mahyuddin at gmail.com<mailto:mahyuddin at gmail.com>>
 wrote:

I just successfully compile and install ndn-cxx, NFD and NLSR on Banana Pro (design and produced by LeMaker - http://www.lemaker.org/).

I can run NFD as usual and create face and register prefix using nfdc. After that i run several test using ndn-tlv-ping and ndn-traffic and everything is run smoothly.

The problem is, when i run NLSR, it will simply throw error message "ERROR: error while connecting to the forwarder" even though NFD is running. In nlsr log file it is just simply throw the same error message "ERROR: error while connecting to the forwarder". Something like below


20150413175010040 DEBUG: [HelloProtocol] Scheduling HELLO Interests in 10 seconds
20150413175010047 DEBUG: [nlsr] Process daemonized. Process id: 14975
20150413175010053 FATAL: [Main] ERROR: error while connecting to the forwarder
20150413175010057 DEBUG: [Fib] Fib::clean called


Seems like it will crash once NLSR start to setup Hello protocol schedule. So, because of lack of details in NLSR log message i tried strace to run NLSR and the output from strace are something like this


gettimeofday({1428918610, 40666}, NULL) = 0
write(10, "20150413175010040 DEBUG: [HelloP"..., 82) = 82
clock_gettime(CLOCK_MONOTONIC, {367502, 38604022}) = 0
clock_gettime(CLOCK_MONOTONIC, {367502, 39270498}) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb4cbc288) = 14975
gettimeofday({1428918610, 47614}, NULL) = 0
write(10, "20150413175010047 DEBUG: [nlsr] "..., 70) = 70
close(9)                                = 0
close(10)                               = 0
ERROR: error while connecting to the forwardermunmap(0xb6f5a000, 8192)                = 0


I'm using the same NFD and NLSR configuration setup that i successfully run on my ubuntu desktop. Is that related to libboost_random (boost library version is 1.49) or probably because Banana Pro is not using real hardware clock? I'm just clueless.


--
Human knowledge Belongs to The World
_______________________________________________
Nfd-dev mailing list
Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150413/4e7b605a/attachment.html>

From lanwang at memphis.edu  Mon Apr 13 12:23:06 2015
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Mon, 13 Apr 2015 19:23:06 +0000
Subject: [Nfd-dev] strategy specific parameters
In-Reply-To: <552BB2CA.1020806@uni-bamberg.de>
References: <552BB2CA.1020806@uni-bamberg.de>
Message-ID: <6C311CEE-EFE6-48AF-BFE3-5953A1FB992B@memphis.edu>

Sounds like a useful feature to me in general.  They can also be implemented as different strategies (see Junxiao's various best-route strategies).

Lan

On Apr 13, 2015, at 7:12 AM, Klaus Schneider <klaus.schneider at uni-bamberg.de>
 wrote:

> One immediate application example is to give the Broadcast Strategy a parameter that states if it should send out Interests with a new nonce.
> 
> A new nonce allows the broadcasted Interests to travel different paths with overlapping nodes (or reaching the same content source) without being dropped by the duplicate nonce detection. This small alteration can be very useful when the duplicate Interests are used to compensate for link problems (delay, loss) on one of the paths.
> 
> Best regards.
> 
> 
>> Hi everyone,
>> 
>> I think it would be a good idea to have (optional) parameters for a
>> forwarding strategy in order to make the design more flexible.
>> 
>> The CCNx prototype supports this:
>> 
>>> ccndc setstrategy <prefix> <strategy> [<parameters> [<lifetime>]]
>> 
>> Unfortunately, there is currently no such option in NFD:
>> 
>>> nfdc set-strategy <namespace> <strategy-name>
>> 
>> 
>> If you think this is reasonable, I can help with the implementation. I
>> am also not sure if this is the right place for such feature requests or
>> if I should put them up as a redmine ticket?
>> 
>> Thanks,
>> Klaus
> 
> -- 
> Klaus Schneider
> 
> Mail: klaus.schneider at uni-bamberg.de
> LinkedIn: https://www.linkedin.com/in/schneiderklaus
> 
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev




From alexander.afanasyev at ucla.edu  Mon Apr 13 12:28:45 2015
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Mon, 13 Apr 2015 12:28:45 -0700
Subject: [Nfd-dev] strategy specific parameters
In-Reply-To: <6C311CEE-EFE6-48AF-BFE3-5953A1FB992B@memphis.edu>
References: <552BB2CA.1020806@uni-bamberg.de>
	<6C311CEE-EFE6-48AF-BFE3-5953A1FB992B@memphis.edu>
Message-ID: <D3F543AA-D63F-4653-98F2-55DB2AC06BED@ucla.edu>

Another way of specializing strategies is to define a parameters as part of strategy name.  For example,

ndn:/localhost/nfd/strategy/broadcast/%FD%01/?param=false

?
Alex

> On Apr 13, 2015, at 12:23 PM, Lan Wang (lanwang) <lanwang at memphis.edu> wrote:
> 
> Sounds like a useful feature to me in general.  They can also be implemented as different strategies (see Junxiao's various best-route strategies).
> 
> Lan
> 
> On Apr 13, 2015, at 7:12 AM, Klaus Schneider <klaus.schneider at uni-bamberg.de>
> wrote:
> 
>> One immediate application example is to give the Broadcast Strategy a parameter that states if it should send out Interests with a new nonce.
>> 
>> A new nonce allows the broadcasted Interests to travel different paths with overlapping nodes (or reaching the same content source) without being dropped by the duplicate nonce detection. This small alteration can be very useful when the duplicate Interests are used to compensate for link problems (delay, loss) on one of the paths.
>> 
>> Best regards.
>> 
>> 
>>> Hi everyone,
>>> 
>>> I think it would be a good idea to have (optional) parameters for a
>>> forwarding strategy in order to make the design more flexible.
>>> 
>>> The CCNx prototype supports this:
>>> 
>>>> ccndc setstrategy <prefix> <strategy> [<parameters> [<lifetime>]]
>>> 
>>> Unfortunately, there is currently no such option in NFD:
>>> 
>>>> nfdc set-strategy <namespace> <strategy-name>
>>> 
>>> 
>>> If you think this is reasonable, I can help with the implementation. I
>>> am also not sure if this is the right place for such feature requests or
>>> if I should put them up as a redmine ticket?
>>> 
>>> Thanks,
>>> Klaus
>> 
>> --
>> Klaus Schneider
>> 
>> Mail: klaus.schneider at uni-bamberg.de
>> LinkedIn: https://www.linkedin.com/in/schneiderklaus
>> 
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
> 
> 
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

-------------- 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/nfd-dev/attachments/20150413/dba910d2/attachment.bin>

From mahyuddin at gmail.com  Mon Apr 13 13:01:36 2015
From: mahyuddin at gmail.com (Mahyuddin Husairi)
Date: Tue, 14 Apr 2015 04:01:36 +0800
Subject: [Nfd-dev] NLSR failed to connect with NFD in Banana Pro
	(Raspbian OS)
In-Reply-To: <BB7514AB-4476-4C13-97A8-BE0F86B5D3A9@memphis.edu>
References: <CAA5Vy7RwA-0kZsSKvu+bqv+45aS0+wN_f+K963+Ez2d0eAh0DA@mail.gmail.com>
	<BB7514AB-4476-4C13-97A8-BE0F86B5D3A9@memphis.edu>
Message-ID: <CAA5Vy7Sf_McVDqxidEPUY2SUGGHu1WwT7J_dZcfqrGxs_CRLEA@mail.gmail.com>

Thanks for a reply.
1. Thanks for the explanation. Im aware that NLSR is communicating with NFD
by using unix socket and we can change that to use tcp tunnel (unicast) by
changing configuration inside client.conf but the same problem occur.
2. I tried both stable and latest version from github.
3. There is no problem during compilation (ndn-cxx, NFD and NLSR), except
some assembler warning message
    /tmp/ccAiTF1c.s: Assembler messages:
    /tmp/ccAiTF1c.s:23842: Warning: swp{b} use is deprecated for ARMv6 and
ARMv7
    /tmp/ccAiTF1c.s:24348: Warning: swp{b} use is deprecated for ARMv6 and
ARMv7
5. Is there anybody already tried running both NFD and NLSR on any single
board computer(SBC) such as Raspberry Pi or Banana Pi?


On Mon, Apr 13, 2015 at 10:53 PM, Lan Wang (lanwang) <lanwang at memphis.edu>
wrote:

>  Not sure what's the problem.  Just some info and
>
>  - Somehow NLSR has difficulty getting connected with NFD.  It needs to
> send Interest and receive Data through that face.  If I understand
> correctly, they use UNIX socket to connect by default (and there's a
> default file name corresponding to the UNIX socket in the NFD
> configuration).
>
>  - Where did you download NLSR?  The GitHub version
> https://github.com/named-data/NLSR  is the latest.  Were there any
> warnings or problems during the compile and installation?
>
> Lan
>
>  On Apr 13, 2015, at 5:06 AM, Mahyuddin Husairi <mahyuddin at gmail.com>
>  wrote:
>
>  I just successfully compile and install ndn-cxx, NFD and NLSR on Banana
> Pro (design and produced by LeMaker - http://www.lemaker.org/).
>
> I can run NFD as usual and create face and register prefix using nfdc.
> After that i run several test using ndn-tlv-ping and ndn-traffic and
> everything is run smoothly.
>
> The problem is, when i run NLSR, it will simply throw error message
> "ERROR: error while connecting to the forwarder" even though NFD is
> running. In nlsr log file it is just simply throw the same error message
> "ERROR: error while connecting to the forwarder". Something like below
>
>
> 20150413175010040 DEBUG: [HelloProtocol] Scheduling HELLO Interests in 10
> seconds
> 20150413175010047 DEBUG: [nlsr] Process daemonized. Process id: 14975
> 20150413175010053 FATAL: [Main] ERROR: error while connecting to the
> forwarder
> 20150413175010057 DEBUG: [Fib] Fib::clean called
>
>
>  Seems like it will crash once NLSR start to setup Hello protocol
> schedule. So, because of lack of details in NLSR log message i tried strace
> to run NLSR and the output from strace are something like this
>
>
>  gettimeofday({1428918610, 40666}, NULL) = 0
> write(10, "20150413175010040 DEBUG: [HelloP"..., 82) = 82
> clock_gettime(CLOCK_MONOTONIC, {367502, 38604022}) = 0
> clock_gettime(CLOCK_MONOTONIC, {367502, 39270498}) = 0
> clone(child_stack=0,
> flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
> child_tidptr=0xb4cbc288) = 14975
> gettimeofday({1428918610, 47614}, NULL) = 0
> write(10, "20150413175010047 DEBUG: [nlsr] "..., 70) = 70
> close(9)                                = 0
> close(10)                               = 0
> ERROR: error while connecting to the forwardermunmap(0xb6f5a000, 8192)
>            = 0
>
>
> I'm using the same NFD and NLSR configuration setup that i successfully
> run on my ubuntu desktop. Is that related to libboost_random (boost library
> version is 1.49) or probably because Banana Pro is not using real hardware
> clock? I'm just clueless.
>
>
>  --
> Human knowledge Belongs to The World
>  _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>
>


-- 
Human knowledge Belongs to The World
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150414/8259fbe8/attachment.html>

From lanwang at memphis.edu  Mon Apr 13 13:50:37 2015
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Mon, 13 Apr 2015 20:50:37 +0000
Subject: [Nfd-dev] NLSR failed to connect with NFD in Banana Pro
 (Raspbian OS)
In-Reply-To: <CAA5Vy7Sf_McVDqxidEPUY2SUGGHu1WwT7J_dZcfqrGxs_CRLEA@mail.gmail.com>
References: <CAA5Vy7RwA-0kZsSKvu+bqv+45aS0+wN_f+K963+Ez2d0eAh0DA@mail.gmail.com>
	<BB7514AB-4476-4C13-97A8-BE0F86B5D3A9@memphis.edu>
	<CAA5Vy7Sf_McVDqxidEPUY2SUGGHu1WwT7J_dZcfqrGxs_CRLEA@mail.gmail.com>
Message-ID: <B4258BD6-2D1E-42EF-980B-47595C5173FF@memphis.edu>

Someone has tried Raspberry Pi, but also had a problem.  We'll test NLSR in the lab with RPi's.  Maybe it'll help understand your problem as well.

Regarding the "ERROR: error while connecting to the forwarder", it is generated by ndn-cxx (NLSR uses ndn-cxx to connect to the forwarder).

Lan

On Apr 13, 2015, at 3:01 PM, Mahyuddin Husairi <mahyuddin at gmail.com<mailto:mahyuddin at gmail.com>>
 wrote:

Thanks for a reply.
1. Thanks for the explanation. Im aware that NLSR is communicating with NFD by using unix socket and we can change that to use tcp tunnel (unicast) by changing configuration inside client.conf but the same problem occur.
2. I tried both stable and latest version from github.
3. There is no problem during compilation (ndn-cxx, NFD and NLSR), except some assembler warning message
    /tmp/ccAiTF1c.s: Assembler messages:
    /tmp/ccAiTF1c.s:23842: Warning: swp{b} use is deprecated for ARMv6 and ARMv7
    /tmp/ccAiTF1c.s:24348: Warning: swp{b} use is deprecated for ARMv6 and ARMv7
5. Is there anybody already tried running both NFD and NLSR on any single board computer(SBC) such as Raspberry Pi or Banana Pi?


On Mon, Apr 13, 2015 at 10:53 PM, Lan Wang (lanwang) <lanwang at memphis.edu<mailto:lanwang at memphis.edu>> wrote:
Not sure what's the problem.  Just some info and

- Somehow NLSR has difficulty getting connected with NFD.  It needs to send Interest and receive Data through that face.  If I understand correctly, they use UNIX socket to connect by default (and there's a default file name corresponding to the UNIX socket in the NFD configuration).

- Where did you download NLSR?  The GitHub version https://github.com/named-data/NLSR  is the latest.  Were there any warnings or problems during the compile and installation?

Lan

On Apr 13, 2015, at 5:06 AM, Mahyuddin Husairi <mahyuddin at gmail.com<mailto:mahyuddin at gmail.com>>
 wrote:

I just successfully compile and install ndn-cxx, NFD and NLSR on Banana Pro (design and produced by LeMaker - http://www.lemaker.org/).

I can run NFD as usual and create face and register prefix using nfdc. After that i run several test using ndn-tlv-ping and ndn-traffic and everything is run smoothly.

The problem is, when i run NLSR, it will simply throw error message "ERROR: error while connecting to the forwarder" even though NFD is running. In nlsr log file it is just simply throw the same error message "ERROR: error while connecting to the forwarder". Something like below


20150413175010040 DEBUG: [HelloProtocol] Scheduling HELLO Interests in 10 seconds
20150413175010047 DEBUG: [nlsr] Process daemonized. Process id: 14975
20150413175010053 FATAL: [Main] ERROR: error while connecting to the forwarder
20150413175010057 DEBUG: [Fib] Fib::clean called


Seems like it will crash once NLSR start to setup Hello protocol schedule. So, because of lack of details in NLSR log message i tried strace to run NLSR and the output from strace are something like this


gettimeofday({1428918610, 40666}, NULL) = 0
write(10, "20150413175010040 DEBUG: [HelloP"..., 82) = 82
clock_gettime(CLOCK_MONOTONIC, {367502, 38604022}) = 0
clock_gettime(CLOCK_MONOTONIC, {367502, 39270498}) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb4cbc288) = 14975
gettimeofday({1428918610, 47614}, NULL) = 0
write(10, "20150413175010047 DEBUG: [nlsr] "..., 70) = 70
close(9)                                = 0
close(10)                               = 0
ERROR: error while connecting to the forwardermunmap(0xb6f5a000, 8192)                = 0


I'm using the same NFD and NLSR configuration setup that i successfully run on my ubuntu desktop. Is that related to libboost_random (boost library version is 1.49) or probably because Banana Pro is not using real hardware clock? I'm just clueless.


--
Human knowledge Belongs to The World
_______________________________________________
Nfd-dev mailing list
Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev




--
Human knowledge Belongs to The World

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150413/775c506f/attachment.html>

From mahyuddin at gmail.com  Mon Apr 13 15:05:01 2015
From: mahyuddin at gmail.com (Mahyuddin Husairi)
Date: Tue, 14 Apr 2015 06:05:01 +0800
Subject: [Nfd-dev] NLSR failed to connect with NFD in Banana Pro
	(Raspbian OS)
In-Reply-To: <B4258BD6-2D1E-42EF-980B-47595C5173FF@memphis.edu>
References: <CAA5Vy7RwA-0kZsSKvu+bqv+45aS0+wN_f+K963+Ez2d0eAh0DA@mail.gmail.com>
	<BB7514AB-4476-4C13-97A8-BE0F86B5D3A9@memphis.edu>
	<CAA5Vy7Sf_McVDqxidEPUY2SUGGHu1WwT7J_dZcfqrGxs_CRLEA@mail.gmail.com>
	<B4258BD6-2D1E-42EF-980B-47595C5173FF@memphis.edu>
Message-ID: <CAA5Vy7QpeLAk5dwHN_ncGHWTpE_7NBFAcYpHZwk-RJKu2oxTpQ@mail.gmail.com>

Glad to hear that.
I think, implementing NDN on any arm chip and/or other embedded should be
taken seriously by us to increase the adaptation of NDN. My research is
related to mesh network on mobile device (im using BananaPro to represent
wireless mobile device) and my hypothesis that by using NDN based dynamic
routing, it will solve reliability, stability and energy efficiency issues
facing by point to point based routing. Of course to develop my own dynamic
routing implementation, NLSR is my starting point to understand how to do
routing in NDN. Instead doing simulation which i've done it through
ndnsim2, i want to evaluate NDN dynamic routing in real world/testbed. But
it seems that i stuck with unknown problem.

On Tue, Apr 14, 2015 at 4:50 AM, Lan Wang (lanwang) <lanwang at memphis.edu>
wrote:

>  Someone has tried Raspberry Pi, but also had a problem.  We'll test NLSR
> in the lab with RPi's.  Maybe it'll help understand your problem as well.
>
>  Regarding the "ERROR: error while connecting to the forwarder", it is
> generated by ndn-cxx (NLSR uses ndn-cxx to connect to the forwarder).
>
> Lan
>
>  On Apr 13, 2015, at 3:01 PM, Mahyuddin Husairi <mahyuddin at gmail.com>
>  wrote:
>
>  Thanks for a reply.
> 1. Thanks for the explanation. Im aware that NLSR is communicating with
> NFD by using unix socket and we can change that to use tcp tunnel (unicast)
> by changing configuration inside client.conf but the same problem occur.
> 2. I tried both stable and latest version from github.
> 3. There is no problem during compilation (ndn-cxx, NFD and NLSR), except
> some assembler warning message
>     /tmp/ccAiTF1c.s: Assembler messages:
>     /tmp/ccAiTF1c.s:23842: Warning: swp{b} use is deprecated for ARMv6 and
> ARMv7
>     /tmp/ccAiTF1c.s:24348: Warning: swp{b} use is deprecated for ARMv6 and
> ARMv7
> 5. Is there anybody already tried running both NFD and NLSR on any single
> board computer(SBC) such as Raspberry Pi or Banana Pi?
>
>
> On Mon, Apr 13, 2015 at 10:53 PM, Lan Wang (lanwang) <lanwang at memphis.edu>
> wrote:
>
>>  Not sure what's the problem.  Just some info and
>>
>>  - Somehow NLSR has difficulty getting connected with NFD.  It needs to
>> send Interest and receive Data through that face.  If I understand
>> correctly, they use UNIX socket to connect by default (and there's a
>> default file name corresponding to the UNIX socket in the NFD
>> configuration).
>>
>>  - Where did you download NLSR?  The GitHub version
>> https://github.com/named-data/NLSR  is the latest.  Were there any
>> warnings or problems during the compile and installation?
>>
>> Lan
>>
>>  On Apr 13, 2015, at 5:06 AM, Mahyuddin Husairi <mahyuddin at gmail.com>
>>  wrote:
>>
>>   I just successfully compile and install ndn-cxx, NFD and NLSR on
>> Banana Pro (design and produced by LeMaker - http://www.lemaker.org/).
>>
>> I can run NFD as usual and create face and register prefix using nfdc.
>> After that i run several test using ndn-tlv-ping and ndn-traffic and
>> everything is run smoothly.
>>
>> The problem is, when i run NLSR, it will simply throw error message
>> "ERROR: error while connecting to the forwarder" even though NFD is
>> running. In nlsr log file it is just simply throw the same error message
>> "ERROR: error while connecting to the forwarder". Something like below
>>
>>
>> 20150413175010040 DEBUG: [HelloProtocol] Scheduling HELLO Interests in 10
>> seconds
>> 20150413175010047 DEBUG: [nlsr] Process daemonized. Process id: 14975
>> 20150413175010053 FATAL: [Main] ERROR: error while connecting to the
>> forwarder
>> 20150413175010057 DEBUG: [Fib] Fib::clean called
>>
>>
>>  Seems like it will crash once NLSR start to setup Hello protocol
>> schedule. So, because of lack of details in NLSR log message i tried strace
>> to run NLSR and the output from strace are something like this
>>
>>
>>  gettimeofday({1428918610, 40666}, NULL) = 0
>> write(10, "20150413175010040 DEBUG: [HelloP"..., 82) = 82
>> clock_gettime(CLOCK_MONOTONIC, {367502, 38604022}) = 0
>> clock_gettime(CLOCK_MONOTONIC, {367502, 39270498}) = 0
>> clone(child_stack=0,
>> flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
>> child_tidptr=0xb4cbc288) = 14975
>> gettimeofday({1428918610, 47614}, NULL) = 0
>> write(10, "20150413175010047 DEBUG: [nlsr] "..., 70) = 70
>> close(9)                                = 0
>> close(10)                               = 0
>> ERROR: error while connecting to the forwardermunmap(0xb6f5a000, 8192)
>>              = 0
>>
>>
>> I'm using the same NFD and NLSR configuration setup that i successfully
>> run on my ubuntu desktop. Is that related to libboost_random (boost library
>> version is 1.49) or probably because Banana Pro is not using real hardware
>> clock? I'm just clueless.
>>
>>
>>  --
>> Human knowledge Belongs to The World
>>   _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>
>>
>>
>
>
>  --
> Human knowledge Belongs to The World
>
>
>


-- 
Human knowledge Belongs to The World
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150414/778b1515/attachment.html>

From shijunxiao at email.arizona.edu  Mon Apr 13 16:10:17 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Mon, 13 Apr 2015 16:10:17 -0700
Subject: [Nfd-dev] strategy specific parameters
In-Reply-To: <552A71BA.3090407@uni-bamberg.de>
References: <552A71BA.3090407@uni-bamberg.de>
Message-ID: <CAOFH+OZEXt2MNwLW74g8T3wJpoXOCn49bNkrXTnEHucYe+nxKg@mail.gmail.com>

Hi Klaus

20150413 conference call discussed this proposal.

This proposal is a subset of #2000 composable strategy building blocks
<http://redmine.named-data.net/issues/2000>.
With #2000, an operator can not only pass parameters to a strategy, but
also create new strategies. Both can happen at runtime.
Passing parameters is just a special case of creating new strategies: take
an existing strategy, and give it new parameters.


I believe having strategy parameters is a good direction toward #2000.
I agree with Alex that parameters should be carried in the Name after the
version component, at the management protocol
<http://redmine.named-data.net/projects/nfd/wiki/StrategyChoice> level.
At command line tool level, however, I prefer to accept ccndc syntax as
well: operator can either specify parameters as part of the strategy Name,
or in separate command line options.


I disagree with the use case that broadcast strategy generates new Nonces
for outgoing Interests, because it can cause persistent Interest loop in #1953
scenario <http://redmine.named-data.net/issues/1953>.

Yours, Junxiao

On Sun, Apr 12, 2015 at 6:23 AM, Klaus Schneider <
klaus.schneider at uni-bamberg.de> wrote:

> Hi everyone,
>
> I think it would be a good idea to have (optional) parameters for a
> forwarding strategy in order to make the design more flexible.
>
> The CCNx prototype supports this:
>
>  ccndc setstrategy <prefix> <strategy> [<parameters> [<lifetime>]]
>>
>
> Unfortunately, there is currently no such option in NFD:
>
>  nfdc set-strategy <namespace> <strategy-name>
>>
>
>
> If you think this is reasonable, I can help with the implementation. I am
> also not sure if this is the right place for such feature requests or if I
> should put them up as a redmine ticket?
>
> Thanks,
> Klaus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150413/2410b736/attachment.html>

From shijunxiao at email.arizona.edu  Mon Apr 13 16:20:20 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Mon, 13 Apr 2015 16:20:20 -0700
Subject: [Nfd-dev] NLSR failed to connect with NFD in Banana Pro
	(Raspbian OS)
In-Reply-To: <CAA5Vy7RwA-0kZsSKvu+bqv+45aS0+wN_f+K963+Ez2d0eAh0DA@mail.gmail.com>
References: <CAA5Vy7RwA-0kZsSKvu+bqv+45aS0+wN_f+K963+Ez2d0eAh0DA@mail.gmail.com>
Message-ID: <CAOFH+OZFVZ-iLOrponxQMmoWcN3+XkrCq7XQLOfUbh1Z62o0SA@mail.gmail.com>

Dear folks

Given that Banana Pro has a slower CPU, could this be caused by #2742 "Face
creation fails due to heavy application processing before calling
processEvents" <http://redmine.named-data.net/issues/2742>?

Yours, Junxiao

On Mon, Apr 13, 2015 at 3:06 AM, Mahyuddin Husairi <mahyuddin at gmail.com>
wrote:

> I just successfully compile and install ndn-cxx, NFD and NLSR on Banana
> Pro (design and produced by LeMaker - http://www.lemaker.org/).
>
> I can run NFD as usual and create face and register prefix using nfdc.
> After that i run several test using ndn-tlv-ping and ndn-traffic and
> everything is run smoothly.
>
> The problem is, when i run NLSR, it will simply throw error message
> "ERROR: error while connecting to the forwarder" even though NFD is
> running. In nlsr log file it is just simply throw the same error message
> "ERROR: error while connecting to the forwarder". Something like below
>
>
> 20150413175010040 DEBUG: [HelloProtocol] Scheduling HELLO Interests in 10
> seconds
> 20150413175010047 DEBUG: [nlsr] Process daemonized. Process id: 14975
> 20150413175010053 FATAL: [Main] ERROR: error while connecting to the
> forwarder
> 20150413175010057 DEBUG: [Fib] Fib::clean called
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150413/5185af3e/attachment.html>

From mahyuddin at gmail.com  Mon Apr 13 16:50:14 2015
From: mahyuddin at gmail.com (Mahyuddin Husairi)
Date: Tue, 14 Apr 2015 07:50:14 +0800
Subject: [Nfd-dev] NLSR failed to connect with NFD in Banana Pro
	(Raspbian OS)
In-Reply-To: <CAOFH+OZFVZ-iLOrponxQMmoWcN3+XkrCq7XQLOfUbh1Z62o0SA@mail.gmail.com>
References: <CAA5Vy7RwA-0kZsSKvu+bqv+45aS0+wN_f+K963+Ez2d0eAh0DA@mail.gmail.com>
	<CAOFH+OZFVZ-iLOrponxQMmoWcN3+XkrCq7XQLOfUbh1Z62o0SA@mail.gmail.com>
Message-ID: <CAA5Vy7S7KcEtJ1pLdKyHAW3pDb1=-MDS+ExBfMA3Tw57dgAm1Q@mail.gmail.com>

I guess, my problem to connect NLSR with NFD in my BananaPro is related to
that issue (ndn-cxx).

On Tue, Apr 14, 2015 at 7:20 AM, Junxiao Shi <shijunxiao at email.arizona.edu>
wrote:

> Dear folks
>
> Given that Banana Pro has a slower CPU, could this be caused by #2742
> "Face creation fails due to heavy application processing before calling
> processEvents" <http://redmine.named-data.net/issues/2742>?
>
> Yours, Junxiao
>
> On Mon, Apr 13, 2015 at 3:06 AM, Mahyuddin Husairi <mahyuddin at gmail.com>
> wrote:
>
>> I just successfully compile and install ndn-cxx, NFD and NLSR on Banana
>> Pro (design and produced by LeMaker - http://www.lemaker.org/).
>>
>> I can run NFD as usual and create face and register prefix using nfdc.
>> After that i run several test using ndn-tlv-ping and ndn-traffic and
>> everything is run smoothly.
>>
>> The problem is, when i run NLSR, it will simply throw error message
>> "ERROR: error while connecting to the forwarder" even though NFD is
>> running. In nlsr log file it is just simply throw the same error message
>> "ERROR: error while connecting to the forwarder". Something like below
>>
>>
>> 20150413175010040 DEBUG: [HelloProtocol] Scheduling HELLO Interests in 10
>> seconds
>> 20150413175010047 DEBUG: [nlsr] Process daemonized. Process id: 14975
>> 20150413175010053 FATAL: [Main] ERROR: error while connecting to the
>> forwarder
>> 20150413175010057 DEBUG: [Fib] Fib::clean called
>>
>>


-- 
Human knowledge Belongs to The World
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150414/66a34454/attachment.html>

From lanwang at memphis.edu  Mon Apr 13 17:47:16 2015
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Tue, 14 Apr 2015 00:47:16 +0000
Subject: [Nfd-dev] NLSR failed to connect with NFD in Banana
 Pro	(Raspbian OS)
In-Reply-To: <CAA5Vy7S7KcEtJ1pLdKyHAW3pDb1=-MDS+ExBfMA3Tw57dgAm1Q@mail.gmail.com>
References: <CAA5Vy7RwA-0kZsSKvu+bqv+45aS0+wN_f+K963+Ez2d0eAh0DA@mail.gmail.com>
	<CAOFH+OZFVZ-iLOrponxQMmoWcN3+XkrCq7XQLOfUbh1Z62o0SA@mail.gmail.com>
	<CAA5Vy7S7KcEtJ1pLdKyHAW3pDb1=-MDS+ExBfMA3Tw57dgAm1Q@mail.gmail.com>
Message-ID: <8EA85B86-A61C-4D43-948A-9B49C2A0EAE1@memphis.edu>

Junxiao:

Thank you for finding this potentially related issue.  Not knowing how ndn-cxx works internally, I wonder why the face creation would fail when there is a long delay between creating the face and calling face.processEvents()?

Lan

On Apr 13, 2015, at 6:50 PM, Mahyuddin Husairi <mahyuddin at gmail.com<mailto:mahyuddin at gmail.com>>
 wrote:

I guess, my problem to connect NLSR with NFD in my BananaPro is related to that issue (ndn-cxx).

On Tue, Apr 14, 2015 at 7:20 AM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:
Dear folks

Given that Banana Pro has a slower CPU, could this be caused by #2742 "Face creation fails due to heavy application processing before calling processEvents"<http://redmine.named-data.net/issues/2742>?

Yours, Junxiao

On Mon, Apr 13, 2015 at 3:06 AM, Mahyuddin Husairi <mahyuddin at gmail.com<mailto:mahyuddin at gmail.com>> wrote:
I just successfully compile and install ndn-cxx, NFD and NLSR on Banana Pro (design and produced by LeMaker - http://www.lemaker.org/).

I can run NFD as usual and create face and register prefix using nfdc. After that i run several test using ndn-tlv-ping and ndn-traffic and everything is run smoothly.

The problem is, when i run NLSR, it will simply throw error message "ERROR: error while connecting to the forwarder" even though NFD is running. In nlsr log file it is just simply throw the same error message "ERROR: error while connecting to the forwarder". Something like below


20150413175010040 DEBUG: [HelloProtocol] Scheduling HELLO Interests in 10 seconds
20150413175010047 DEBUG: [nlsr] Process daemonized. Process id: 14975
20150413175010053 FATAL: [Main] ERROR: error while connecting to the forwarder
20150413175010057 DEBUG: [Fib] Fib::clean called




--
Human knowledge Belongs to The World
_______________________________________________
Nfd-dev mailing list
Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150414/126ba6fe/attachment.html>

From klaus.schneider at uni-bamberg.de  Tue Apr 14 13:59:55 2015
From: klaus.schneider at uni-bamberg.de (Klaus Schneider)
Date: Tue, 14 Apr 2015 22:59:55 +0200
Subject: [Nfd-dev] strategy specific parameters
In-Reply-To: <CAOFH+OZEXt2MNwLW74g8T3wJpoXOCn49bNkrXTnEHucYe+nxKg@mail.gmail.com>
References: <552A71BA.3090407@uni-bamberg.de>
	<CAOFH+OZEXt2MNwLW74g8T3wJpoXOCn49bNkrXTnEHucYe+nxKg@mail.gmail.com>
Message-ID: <552D7FCB.4030800@uni-bamberg.de>

Hi Junxiao and Alex,

Thank you for your elaborate answer. Using parameters as part of the 
strategy name is an interesting concept.

> Another way of specializing strategies is to define a parameters as part of strategy name.  For example,
>
> ndn:/localhost/nfd/strategy/broadcast/%FD%01/?param=false
>

Is it possible to access this parameter inside the strategy when using 
ndnSim?

In my simulation file I added a parameter:

> ndn::StrategyChoiceHelper::Install(client, "/",
>       "/localhost/nfd/strategy/somestrategy/%FD%01/?param=true");

However, none of the following two variables shows the correct parameter 
inside the strategy constructor:

> StrategyChoice& strategyChoice = forwarder.getStrategyChoice();
>   Strategy& str = strategyChoice.findEffectiveStrategy("/");
>
>   std::cout << "Name: " << str.getName() << ", " << name << "\n";

Is there another way to access the parameter?

Regarding the duplicate nonce loops: I think this is not a problem when 
the client who uses the broadcast strategy is not a source for the 
requested content. If no routes go back to the client (which is the 
scenario I had in mind), then to my understanding the Interest packets 
can't loop.

Even if this won't get implemented, I think it's a good example how 
parameters can help to avoid creating a new strategy for a change of one 
line of code.

Thanks,
Klaus





On 14.04.2015 01:10, Junxiao Shi wrote:
> Hi Klaus
>
> 20150413 conference call discussed this proposal.
>
> This proposal is a subset of #2000 composable strategy building blocks
> <http://redmine.named-data.net/issues/2000>.
> With #2000, an operator can not only pass parameters to a strategy, but
> also create new strategies. Both can happen at runtime.
> Passing parameters is just a special case of creating new strategies: take
> an existing strategy, and give it new parameters.
>
>
> I believe having strategy parameters is a good direction toward #2000.
> I agree with Alex that parameters should be carried in the Name after the
> version component, at the management protocol
> <http://redmine.named-data.net/projects/nfd/wiki/StrategyChoice> level.
> At command line tool level, however, I prefer to accept ccndc syntax as
> well: operator can either specify parameters as part of the strategy Name,
> or in separate command line options.
>
>
> I disagree with the use case that broadcast strategy generates new Nonces
> for outgoing Interests, because it can cause persistent Interest loop in #1953
> scenario <http://redmine.named-data.net/issues/1953>.
>
> Yours, Junxiao
>
> On Sun, Apr 12, 2015 at 6:23 AM, Klaus Schneider <
> klaus.schneider at uni-bamberg.de> wrote:
>
>> Hi everyone,
>>
>> I think it would be a good idea to have (optional) parameters for a
>> forwarding strategy in order to make the design more flexible.
>>
>> The CCNx prototype supports this:
>>
>>   ccndc setstrategy <prefix> <strategy> [<parameters> [<lifetime>]]
>>>
>>
>> Unfortunately, there is currently no such option in NFD:
>>
>>   nfdc set-strategy <namespace> <strategy-name>
>>>
>>
>>
>> If you think this is reasonable, I can help with the implementation. I am
>> also not sure if this is the right place for such feature requests or if I
>> should put them up as a redmine ticket?
>>
>> Thanks,
>> Klaus
>

-- 
Klaus Schneider

Mail: klaus.schneider at uni-bamberg.de
LinkedIn: https://www.linkedin.com/in/schneiderklaus


From klaus.schneider at uni-bamberg.de  Sun Apr 19 14:16:08 2015
From: klaus.schneider at uni-bamberg.de (Klaus Schneider)
Date: Sun, 19 Apr 2015 23:16:08 +0200
Subject: [Nfd-dev] strategy specific parameters
In-Reply-To: <552D7FCB.4030800@uni-bamberg.de>
References: <552A71BA.3090407@uni-bamberg.de>
	<CAOFH+OZEXt2MNwLW74g8T3wJpoXOCn49bNkrXTnEHucYe+nxKg@mail.gmail.com>
	<552D7FCB.4030800@uni-bamberg.de>
Message-ID: <55341B18.3090009@uni-bamberg.de>

Here is my quick and dirty solution for including parameters in the 
strategy name.

1. I added a string variable to the strategy.hpp class (+ getters and 
setters):

> protected std::string parameters;

>   public void setParameters(std::string newParameters){
>     parameters = newParameters;
>   }
>
>   public const std::string getParameters(){
>     return parameters;
>   }

2. I changed StrategyChoice::getStrategy() in strategy-choice.cpp to

> fw::Strategy*
> StrategyChoice::getStrategy(const Name& strategyName) const
> {
>   fw::Strategy* candidate = nullptr;
>   for (auto n : m_strategyInstances) {
>     if (strategyName.isPrefixOf(n.first) || n.first.isPrefixOf(strategyName)) {
>       switch (n.first.size() + 1 - strategyName.size()) {
>       case 0: // Strategy with parameters (one element longer than exact match)
>         n.second->setParameters(strategyName.toUri().erase(0, n.first.toUri().size() + 1));
>         return n.second.get();
>       case 1:  // exact match
>         return n.second.get();
>       case 2:  // unversioned strategyName matches versioned strategy
>         candidate = n.second.get();
>         break;
>       }
>     }
>   }
>   return candidate;
> }

3. Since one can't access the parameters in the constructor (they are 
set later), I created a method inside my strategy that is called once 
after the first call of afterReceiveInterest():

> void YourStrategyName::initialize()
> {
>   if (!init) {
>     init = true;
>     std::cout << "Parameters: " << parameters << "\n";
>
>     // Use parameters
>     double value = std::stod(parameters);
>     setParameters(Type::LOSS, value);
>   }
> }

Seems to work fine and saves a lot of recompilation time when using 
ndnSim. Just set the desired parameters after the full strategy name (as 
Alexander suggested in a previous mail):

>   ndn::StrategyChoiceHelper::Install(client, "/",
>       "/localhost/nfd/strategy/your-strategy/%FD%01/0.4");

Of course, one could add separated key-value pairs and define a syntax 
for that.

Best regards
Klaus



On 14.04.2015 22:59, Klaus Schneider wrote:
> Hi Junxiao and Alex,
>
> Thank you for your elaborate answer. Using parameters as part of the
> strategy name is an interesting concept.
>
>> Another way of specializing strategies is to define a parameters as
>> part of strategy name.  For example,
>>
>> ndn:/localhost/nfd/strategy/broadcast/%FD%01/?param=false
>>
>
> Is it possible to access this parameter inside the strategy when using
> ndnSim?
>
> In my simulation file I added a parameter:
>
>> ndn::StrategyChoiceHelper::Install(client, "/",
>>       "/localhost/nfd/strategy/somestrategy/%FD%01/?param=true");
>
> However, none of the following two variables shows the correct parameter
> inside the strategy constructor:
>
>> StrategyChoice& strategyChoice = forwarder.getStrategyChoice();
>>   Strategy& str = strategyChoice.findEffectiveStrategy("/");
>>
>>   std::cout << "Name: " << str.getName() << ", " << name << "\n";
>
> Is there another way to access the parameter?
>
> Regarding the duplicate nonce loops: I think this is not a problem when
> the client who uses the broadcast strategy is not a source for the
> requested content. If no routes go back to the client (which is the
> scenario I had in mind), then to my understanding the Interest packets
> can't loop.
>
> Even if this won't get implemented, I think it's a good example how
> parameters can help to avoid creating a new strategy for a change of one
> line of code.
>
> Thanks,
> Klaus
>
>
>
>
>
> On 14.04.2015 01:10, Junxiao Shi wrote:
>> Hi Klaus
>>
>> 20150413 conference call discussed this proposal.
>>
>> This proposal is a subset of #2000 composable strategy building blocks
>> <http://redmine.named-data.net/issues/2000>.
>> With #2000, an operator can not only pass parameters to a strategy, but
>> also create new strategies. Both can happen at runtime.
>> Passing parameters is just a special case of creating new strategies:
>> take
>> an existing strategy, and give it new parameters.
>>
>>
>> I believe having strategy parameters is a good direction toward #2000.
>> I agree with Alex that parameters should be carried in the Name after the
>> version component, at the management protocol
>> <http://redmine.named-data.net/projects/nfd/wiki/StrategyChoice> level.
>> At command line tool level, however, I prefer to accept ccndc syntax as
>> well: operator can either specify parameters as part of the strategy
>> Name,
>> or in separate command line options.
>>
>>
>> I disagree with the use case that broadcast strategy generates new Nonces
>> for outgoing Interests, because it can cause persistent Interest loop
>> in #1953
>> scenario <http://redmine.named-data.net/issues/1953>.
>>
>> Yours, Junxiao
>>
>> On Sun, Apr 12, 2015 at 6:23 AM, Klaus Schneider <
>> klaus.schneider at uni-bamberg.de> wrote:
>>
>>> Hi everyone,
>>>
>>> I think it would be a good idea to have (optional) parameters for a
>>> forwarding strategy in order to make the design more flexible.
>>>
>>> The CCNx prototype supports this:
>>>
>>>   ccndc setstrategy <prefix> <strategy> [<parameters> [<lifetime>]]
>>>>
>>>
>>> Unfortunately, there is currently no such option in NFD:
>>>
>>>   nfdc set-strategy <namespace> <strategy-name>
>>>>
>>>
>>>
>>> If you think this is reasonable, I can help with the implementation.
>>> I am
>>> also not sure if this is the right place for such feature requests or
>>> if I
>>> should put them up as a redmine ticket?
>>>
>>> Thanks,
>>> Klaus
>>
>

-- 
Klaus Schneider

Mail: klaus.schneider at uni-bamberg.de
LinkedIn: https://www.linkedin.com/in/schneiderklaus


From hila at wustl.edu  Mon Apr 20 08:41:58 2015
From: hila at wustl.edu (Hila Ben Abraham)
Date: Mon, 20 Apr 2015 15:41:58 +0000
Subject: [Nfd-dev] best-route behavior
Message-ID: <CA+KLkb=r0eKgdNuT8jJ4cV6dL0d52ETzw9eFHE+e_ziLavYdDA@mail.gmail.com>

All,

What is the expected behavior of the best-route strategy when the primary
face it uses doesn't respond with data? Shouldn't it try another face?
According to our experiments it keeps on forwarding the same interests to
the primary face, although another 'working' and more expensive face is
available.

In some more details:
We are running an experiment using the following topology:
A--B--C
      |
     D

On B, we set the cost of /ndn/test/ping toward C to be cheaper than the one
toward D.

We start ndnpingserver on node D to respond to /ndn/test/ping, and we start
ndnping to ping for the same namespace on node A.

As expected, B forwards the first interest on the cheapest face toward C.
However, even though C fails to respond with data, B keeps forwarding the
following ping interests to C, and never tries the face toward D.

Is this the expected behavior? Am I missing something here?

Thanks,
Hila
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150420/ffee5fd4/attachment.html>

From shijunxiao at email.arizona.edu  Mon Apr 20 08:46:45 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Mon, 20 Apr 2015 08:46:45 -0700
Subject: [Nfd-dev] best-route behavior
In-Reply-To: <CA+KLkb=r0eKgdNuT8jJ4cV6dL0d52ETzw9eFHE+e_ziLavYdDA@mail.gmail.com>
References: <CA+KLkb=r0eKgdNuT8jJ4cV6dL0d52ETzw9eFHE+e_ziLavYdDA@mail.gmail.com>
Message-ID: <CAOFH+Ob7jtxVJDQdxkffHG_8g1BZMXNSi2hLnr9mJgxNRyuSxg@mail.gmail.com>

Hi Hila

The consumer app needs to retransmit a similar Interest (same
Name+Selectors, different Nonce). The retransmission will be forwarded to
another nexthop (toward D).

best-route v3 has no memory beyond single PIT entry.
This means, even if a retx finds a different producer, a different Interest
still needs consumer retx.
The assumption is: routing protocol is expected to erase the incorrect
route (toward C) shortly.

Yours, Junxiao

On Mon, Apr 20, 2015 at 8:41 AM, Hila Ben Abraham <hila at wustl.edu> wrote:

> All,
>
> What is the expected behavior of the best-route strategy when the primary
> face it uses doesn't respond with data? Shouldn't it try another face?
> According to our experiments it keeps on forwarding the same interests to
> the primary face, although another 'working' and more expensive face is
> available.
>
> In some more details:
> We are running an experiment using the following topology:
> A--B--C
>       |
>      D
>
> On B, we set the cost of /ndn/test/ping toward C to be cheaper than the
> one toward D.
>
> We start ndnpingserver on node D to respond to /ndn/test/ping, and we
> start ndnping to ping for the same namespace on node A.
>
> As expected, B forwards the first interest on the cheapest face toward C.
> However, even though C fails to respond with data, B keeps forwarding the
> following ping interests to C, and never tries the face toward D.
>
> Is this the expected behavior? Am I missing something here?
>
> Thanks,
> Hila
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150420/216f7b36/attachment.html>

From hila at wustl.edu  Mon Apr 20 14:03:09 2015
From: hila at wustl.edu (Hila Ben Abraham)
Date: Mon, 20 Apr 2015 21:03:09 +0000
Subject: [Nfd-dev] best-route behavior
In-Reply-To: <CAOFH+Ob7jtxVJDQdxkffHG_8g1BZMXNSi2hLnr9mJgxNRyuSxg@mail.gmail.com>
References: <CA+KLkb=r0eKgdNuT8jJ4cV6dL0d52ETzw9eFHE+e_ziLavYdDA@mail.gmail.com>
	<CAOFH+Ob7jtxVJDQdxkffHG_8g1BZMXNSi2hLnr9mJgxNRyuSxg@mail.gmail.com>
Message-ID: <CA+KLkbmg9nAjX7UK7HfOKoqo8iJV2LqxTrrP9Oe1rDMZPOyNFg@mail.gmail.com>

Thank you Junxiao. My results make sense now.

Hila

On Mon, Apr 20, 2015 at 10:47 AM Junxiao Shi <shijunxiao at email.arizona.edu>
wrote:

> Hi Hila
>
> The consumer app needs to retransmit a similar Interest (same
> Name+Selectors, different Nonce). The retransmission will be forwarded to
> another nexthop (toward D).
>
> best-route v3 has no memory beyond single PIT entry.
> This means, even if a retx finds a different producer, a different
> Interest still needs consumer retx.
> The assumption is: routing protocol is expected to erase the incorrect
> route (toward C) shortly.
>
> Yours, Junxiao
>
> On Mon, Apr 20, 2015 at 8:41 AM, Hila Ben Abraham <hila at wustl.edu> wrote:
>
>> All,
>>
>> What is the expected behavior of the best-route strategy when the primary
>> face it uses doesn't respond with data? Shouldn't it try another face?
>> According to our experiments it keeps on forwarding the same interests to
>> the primary face, although another 'working' and more expensive face is
>> available.
>>
>> In some more details:
>> We are running an experiment using the following topology:
>> A--B--C
>>       |
>>      D
>>
>> On B, we set the cost of /ndn/test/ping toward C to be cheaper than the
>> one toward D.
>>
>> We start ndnpingserver on node D to respond to /ndn/test/ping, and we
>> start ndnping to ping for the same namespace on node A.
>>
>> As expected, B forwards the first interest on the cheapest face toward C.
>> However, even though C fails to respond with data, B keeps forwarding the
>> following ping interests to C, and never tries the face toward D.
>>
>> Is this the expected behavior? Am I missing something here?
>>
>> Thanks,
>> Hila
>>
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150420/0c151e6e/attachment.html>

From shijunxiao at email.arizona.edu  Wed Apr 22 10:06:44 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Wed, 22 Apr 2015 10:06:44 -0700
Subject: [Nfd-dev] strategy specific parameters
In-Reply-To: <55341B18.3090009@uni-bamberg.de>
References: <552A71BA.3090407@uni-bamberg.de>
	<CAOFH+OZEXt2MNwLW74g8T3wJpoXOCn49bNkrXTnEHucYe+nxKg@mail.gmail.com>
	<552D7FCB.4030800@uni-bamberg.de> <55341B18.3090009@uni-bamberg.de>
Message-ID: <CAOFH+OYVi2b+e9SkBPUMEO0EkiG9d0WAEPh-J+aHffVZbasu8A@mail.gmail.com>

Hi Klaus

A major flaw of this solution is: you can't use the same strategy with
different parameters.
Consider the following setup:

   - namespace=/, strategy=/my-strategy/param=no
   - namespace=/A , strategy=/my-strategy/param=yes

StrategyChoice::getStrategy returns the same instance (from
m_strategyInstances), so that the second set of parameters would change the
state of that instance, and affect both namespaces.
Since most simulations only deal with one strategy, this shouldn't cause
big problems.

Given you are only using this in simulations, an easier approach is to pass
the parameters with a ns3::GlobalVariable.

Yours, Junxiao

On Sun, Apr 19, 2015 at 2:16 PM, Klaus Schneider <
klaus.schneider at uni-bamberg.de> wrote:

> Here is my quick and dirty solution for including parameters in the
> strategy name.
>
> 2. I changed StrategyChoice::getStrategy() in strategy-choice.cpp to
>
>  fw::Strategy*
>> StrategyChoice::getStrategy(const Name& strategyName) const
>> {
>>   fw::Strategy* candidate = nullptr;
>>   for (auto n : m_strategyInstances) {
>>     if (strategyName.isPrefixOf(n.first) ||
>> n.first.isPrefixOf(strategyName)) {
>>       switch (n.first.size() + 1 - strategyName.size()) {
>>       case 0: // Strategy with parameters (one element longer than exact
>> match)
>>         n.second->setParameters(strategyName.toUri().erase(0,
>> n.first.toUri().size() + 1));
>>         return n.second.get();
>>       case 1:  // exact match
>>         return n.second.get();
>>       case 2:  // unversioned strategyName matches versioned strategy
>>         candidate = n.second.get();
>>         break;
>>       }
>>     }
>>   }
>>   return candidate;
>> }
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150422/27cf3c09/attachment.html>

From klaus.schneider at uni-bamberg.de  Wed Apr 22 14:37:19 2015
From: klaus.schneider at uni-bamberg.de (Klaus Schneider)
Date: Wed, 22 Apr 2015 23:37:19 +0200
Subject: [Nfd-dev] strategy specific parameters
In-Reply-To: <CAOFH+OYVi2b+e9SkBPUMEO0EkiG9d0WAEPh-J+aHffVZbasu8A@mail.gmail.com>
References: <552A71BA.3090407@uni-bamberg.de>
	<CAOFH+OZEXt2MNwLW74g8T3wJpoXOCn49bNkrXTnEHucYe+nxKg@mail.gmail.com>
	<552D7FCB.4030800@uni-bamberg.de> <55341B18.3090009@uni-bamberg.de>
	<CAOFH+OYVi2b+e9SkBPUMEO0EkiG9d0WAEPh-J+aHffVZbasu8A@mail.gmail.com>
Message-ID: <5538148F.9000506@uni-bamberg.de>

Hi Junxiao,

Thanks for your comment!

Of course, you are completely correct with your remark. Putting the 
parameters into the strategy makes them global for all strategy 
instances which isn't what we want. Also changing parameters in a method 
called "getStrategy()" wasn't the most logical thing to do.

Here is my new solution to solve this problem:

1. Remove the "n.second->setParameters..." line from the getStrategy() 
method below.

2. Add the parameters to strategy-choice-entry.hpp instead of Strategy.hpp

>   void setParameters(std::string newParameters)
>   {
>     parameters = newParameters;
>   }
>
>   const std::string getParameters()
>   {
>     return parameters;
>   }
>
> private:
>   std::string parameters;

3. In strategy-choice.cpp add this to the end of the 
StrategyChoice::insert() Method:

// Gets the parameters as last element of the name (behind "/").
>   std::string strName = strategyName.toUri();
>   std::vector<std::string> strVector;
>   boost::split(strVector, strName, boost::is_any_of("/"));
>
>   entry->setStrategy(*strategy);
>   entry->setParameters(strVector.back());
>   return true;
> }

Also add a method to access the parameters:

> std::string StrategyChoice::findEffectiveParameters(const Name& prefix) const
> {
>   shared_ptr < name_tree::Entry > nte = m_nameTree.findLongestPrefixMatch(prefix,
>       [] (const name_tree::Entry& entry) {
>         return static_cast<bool>(entry.getStrategyChoiceEntry());
>       });
>
>   BOOST_ASSERT(static_cast<bool>(nte));
>   return nte->getStrategyChoiceEntry()->getParameters();
> }

4. Use the parameters inside the strategy with a reference to the forwarder:

> void YourStrategyName::initialize()
> {
>   if (!init) {
>     init = true;
>     std::string parameters = ownForwarder.getStrategyChoice().findEffectiveParameters(Name("/"));
>     std::cout << "Effective parameters: " << parameters << "\n";
>   }
> }

My first test shows that a new parameter for namespace /A no longer 
overwrites parameters of namespace /.

Of course, it might contain other bugs. For instance, changing 
parameters of the same prefix after the initial insert 
(StrategyChoice::changeStrategy() ) currently doesn't work. However, it 
shouldn't be too hard to fix this.


Thanks for the tip with ns3::GlobalVariable, I have to look at this.

Best regards
Klaus






On 22.04.2015 19:06, Junxiao Shi wrote:
> Hi Klaus
>
> A major flaw of this solution is: you can't use the same strategy with
> different parameters.
> Consider the following setup:
>
>     - namespace=/, strategy=/my-strategy/param=no
>     - namespace=/A , strategy=/my-strategy/param=yes
>
> StrategyChoice::getStrategy returns the same instance (from
> m_strategyInstances), so that the second set of parameters would change the
> state of that instance, and affect both namespaces.
> Since most simulations only deal with one strategy, this shouldn't cause
> big problems.
>
> Given you are only using this in simulations, an easier approach is to pass
> the parameters with a ns3::GlobalVariable.
>
> Yours, Junxiao
>
> On Sun, Apr 19, 2015 at 2:16 PM, Klaus Schneider <
> klaus.schneider at uni-bamberg.de> wrote:
>
>> Here is my quick and dirty solution for including parameters in the
>> strategy name.
>>
>> 2. I changed StrategyChoice::getStrategy() in strategy-choice.cpp to
>>
>>   fw::Strategy*
>>> StrategyChoice::getStrategy(const Name& strategyName) const
>>> {
>>>    fw::Strategy* candidate = nullptr;
>>>    for (auto n : m_strategyInstances) {
>>>      if (strategyName.isPrefixOf(n.first) ||
>>> n.first.isPrefixOf(strategyName)) {
>>>        switch (n.first.size() + 1 - strategyName.size()) {
>>>        case 0: // Strategy with parameters (one element longer than exact
>>> match)
>>>          n.second->setParameters(strategyName.toUri().erase(0,
>>> n.first.toUri().size() + 1));
>>>          return n.second.get();
>>>        case 1:  // exact match
>>>          return n.second.get();
>>>        case 2:  // unversioned strategyName matches versioned strategy
>>>          candidate = n.second.get();
>>>          break;
>>>        }
>>>      }
>>>    }
>>>    return candidate;
>>> }
>>
>>
>

-- 
Klaus Schneider

Mail: klaus.schneider at uni-bamberg.de
LinkedIn: https://www.linkedin.com/in/schneiderklaus


From vslehman at memphis.edu  Thu Apr 23 16:15:05 2015
From: vslehman at memphis.edu (Vince Lehman (vslehman))
Date: Thu, 23 Apr 2015 23:15:05 +0000
Subject: [Nfd-dev] RTT delay caused by RIB registration commands
Message-ID: <2E7F0681-E8C1-49F6-BAEA-8A48F3B4B4E8@memphis.edu>

Hi all,

I was looking over some of our hyperbolic routing results and noticed some substantial delays in ndnping when RIB registration commands are sent to the forwarder.

Our tests use ndnping to track the RTTs between routers and when a node fails, the routing converges and new routes are registered with NFD.
What I saw in the logs was that even with our link-state routing implementation, two nodes that are directly connected were experiencing additional delay even though
their direct path was unaffected by the failed node.

I am able to replicate this result on my laptop from the command line. When I run an ndnping server and ndnping on my laptop, I see consistent RTTs. But, when I send
nfdc register commands at a relatively slow interval (0.5 s) at the same time, I see a large jump in the RTT.

Below is an example. I started the RIB registrations right after the ping with reference 810245465.

Content From /ndn - Ping Reference = 810245457   - Round Trip Time = 1.307 ms
Content From /ndn - Ping Reference = 810245458   - Round Trip Time = 1.296 ms
Content From /ndn - Ping Reference = 810245459   - Round Trip Time = 1.229 ms
Content From /ndn - Ping Reference = 810245460   - Round Trip Time = 1.291 ms
Content From /ndn - Ping Reference = 810245461   - Round Trip Time = 1.155 ms
Content From /ndn - Ping Reference = 810245462   - Round Trip Time = 1.251 ms
Content From /ndn - Ping Reference = 810245463   - Round Trip Time = 1.271 ms
Content From /ndn - Ping Reference = 810245464   - Round Trip Time = 1.436 ms
Content From /ndn - Ping Reference = 810245465   - Round Trip Time = 1.328 ms
Content From /ndn - Ping Reference = 810245466   - Round Trip Time = 1.22 ms
Content From /ndn - Ping Reference = 810245467   - Round Trip Time = 14.618 ms
Content From /ndn - Ping Reference = 810245468   - Round Trip Time = 1.255 ms
Content From /ndn - Ping Reference = 810245469   - Round Trip Time = 1.211 ms
Content From /ndn - Ping Reference = 810245470   - Round Trip Time = 0.854 ms
Content From /ndn - Ping Reference = 810245471   - Round Trip Time = 1.274 ms

I used this simple bash script to send the registration commands:
for i in `seq 1 25`; do
  nfdc register /a 258
  sleep 0.5
done

Has anyone else experienced this delay caused by registration commands? Any ideas to help reduce the RTT variance to stabilize our results?

Any comments or suggestions you can provide would be appreciated. Thanks.

--
Vince Lehman

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150423/ded7ddef/attachment.html>

From shijunxiao at email.arizona.edu  Fri Apr 24 11:19:53 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Fri, 24 Apr 2015 11:19:53 -0700
Subject: [Nfd-dev] RTT delay caused by RIB registration commands
In-Reply-To: <2E7F0681-E8C1-49F6-BAEA-8A48F3B4B4E8@memphis.edu>
References: <2E7F0681-E8C1-49F6-BAEA-8A48F3B4B4E8@memphis.edu>
Message-ID: <CAOFH+OavUKWSo6DOMP+T3Evw8rSFo+DLvsj0zrapxR_x7HHjzg@mail.gmail.com>

Hi Vince

This is similar to #1589 and #2174. Ubuntu could affected by those issues,
but it's less severe than OSX.


When you do prefix registration with nfdc using a FaceId, the following
signing operations are involved:

   1. nfdc connects to NFD: NFD signs face status change notification
   2. nfdc sends registration command to RIB: nfdc signs the command
   3. RIB answers registration command to nfdc: RIB signs the answer
   4. RIB sends FIB update(s) to NFD: RIB signs FIB update command(s)
   5. NFD answers FIB update(s): NFD signs the answer(s)
   6. nfdc disconnects from NFD: NFD signs face status change notification

There are at least 6 signing operations, assuming the registration triggers
only one FIB update.
At least 4 signing operations are within NFD thread.
If using RSA, they will take 78ms with osx-keychain TPM, and 10ms with file
TPM on Ubuntu (see #1589 note-1 benchmark).

The log shows 13ms extra RTT when processing a registration command. This
is in line with the calculation above.
10ms is spent for RSA signing, and 3ms is spent for other processing (eg.
step 6 also causes NFD to enumerate the FIB to erase NextHopRecords that
points to the failing face).


To either confirm or reject this hypothesis, please try doing the prefix
registration with FaceUri of an non-existing UDP face.
This should cause nfdc to send a face query request followed by a face
creation command, and make NFD to sign two more answers.
If the RTT is further increased by about 5ms, the hypothesis is confirmed.

Yours, Junxiao


On Thu, Apr 23, 2015 at 4:15 PM, Vince Lehman (vslehman) <
vslehman at memphis.edu> wrote:

>
>  I am able to replicate this result on my laptop from the command line.
> When I run an ndnping server and ndnping on my laptop, I see consistent
> RTTs. But, when I send
> nfdc register commands at a relatively slow interval (0.5 s) at the same
> time, I see a large jump in the RTT.
>
>  Below is an example. I started the RIB registrations right after the
> ping with reference 810245465.
>
> Content From /ndn - Ping Reference = 810245463   - Round Trip Time =
> 1.271 ms
> Content From /ndn - Ping Reference = 810245464   - Round Trip Time =
> 1.436 ms
> Content From /ndn - Ping Reference = 810245465   - Round Trip Time =
> 1.328 ms
> Content From /ndn - Ping Reference = 810245466   - Round Trip Time = 1.22
> ms
> Content From /ndn - Ping Reference = 810245467   - Round Trip Time =
> 14.618 ms
> Content From /ndn - Ping Reference = 810245468   - Round Trip Time =
> 1.255 ms
> Content From /ndn - Ping Reference = 810245469   - Round Trip Time =
> 1.211 ms
>
>  I used this simple bash script to send the registration commands:
> for i in `seq 1 25`; do
>   nfdc register /a 258
>   sleep 0.5
> done
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150424/fbe27c19/attachment.html>

From lanwang at memphis.edu  Fri Apr 24 11:33:52 2015
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Fri, 24 Apr 2015 18:33:52 +0000
Subject: [Nfd-dev] RTT delay caused by RIB registration commands
In-Reply-To: <2E7F0681-E8C1-49F6-BAEA-8A48F3B4B4E8@memphis.edu>
References: <2E7F0681-E8C1-49F6-BAEA-8A48F3B4B4E8@memphis.edu>
Message-ID: <D10AB5AE-A329-49F3-A967-3CCF75C6B89F@memphis.edu>

Basically, we saw a large jump in ndnping results between two nodes even though there was no path change for the path between those two nodes.  We found that it was because those nodes (or the intermediate ones) were busy updating their FIB (for other routes) -- each registration and unregistration of a route obviously took ~10ms for NRD/NFD to process.

We were interested in RTT changes due to route changes, so the extra delay caused by the route registrations is an undesirable side effect we'd like to remove (thus Vince's email).  So any suggestions on how to deal with this in our experiments are highly appreciated.

In the long term, we do need to address the problem of high processing delays of route registrations.

Lan

On Apr 23, 2015, at 6:15 PM, Vince Lehman (vslehman) <vslehman at memphis.edu<mailto:vslehman at memphis.edu>> wrote:

Hi all,

I was looking over some of our hyperbolic routing results and noticed some substantial delays in ndnping when RIB registration commands are sent to the forwarder.

Our tests use ndnping to track the RTTs between routers and when a node fails, the routing converges and new routes are registered with NFD.
What I saw in the logs was that even with our link-state routing implementation, two nodes that are directly connected were experiencing additional delay even though
their direct path was unaffected by the failed node.

I am able to replicate this result on my laptop from the command line. When I run an ndnping server and ndnping on my laptop, I see consistent RTTs. But, when I send
nfdc register commands at a relatively slow interval (0.5 s) at the same time, I see a large jump in the RTT.

Below is an example. I started the RIB registrations right after the ping with reference 810245465.

Content From /ndn - Ping Reference = 810245457   - Round Trip Time = 1.307 ms
Content From /ndn - Ping Reference = 810245458   - Round Trip Time = 1.296 ms
Content From /ndn - Ping Reference = 810245459   - Round Trip Time = 1.229 ms
Content From /ndn - Ping Reference = 810245460   - Round Trip Time = 1.291 ms
Content From /ndn - Ping Reference = 810245461   - Round Trip Time = 1.155 ms
Content From /ndn - Ping Reference = 810245462   - Round Trip Time = 1.251 ms
Content From /ndn - Ping Reference = 810245463   - Round Trip Time = 1.271 ms
Content From /ndn - Ping Reference = 810245464   - Round Trip Time = 1.436 ms
Content From /ndn - Ping Reference = 810245465   - Round Trip Time = 1.328 ms
Content From /ndn - Ping Reference = 810245466   - Round Trip Time = 1.22 ms
Content From /ndn - Ping Reference = 810245467   - Round Trip Time = 14.618 ms
Content From /ndn - Ping Reference = 810245468   - Round Trip Time = 1.255 ms
Content From /ndn - Ping Reference = 810245469   - Round Trip Time = 1.211 ms
Content From /ndn - Ping Reference = 810245470   - Round Trip Time = 0.854 ms
Content From /ndn - Ping Reference = 810245471   - Round Trip Time = 1.274 ms

I used this simple bash script to send the registration commands:
for i in `seq 1 25`; do
  nfdc register /a 258
  sleep 0.5
done

Has anyone else experienced this delay caused by registration commands? Any ideas to help reduce the RTT variance to stabilize our results?

Any comments or suggestions you can provide would be appreciated. Thanks.

--
Vince Lehman


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150424/a8331073/attachment.html>

From shijunxiao at email.arizona.edu  Fri Apr 24 11:38:41 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Fri, 24 Apr 2015 11:38:41 -0700
Subject: [Nfd-dev] RTT delay caused by RIB registration commands
In-Reply-To: <D10AB5AE-A329-49F3-A967-3CCF75C6B89F@memphis.edu>
References: <2E7F0681-E8C1-49F6-BAEA-8A48F3B4B4E8@memphis.edu>
	<D10AB5AE-A329-49F3-A967-3CCF75C6B89F@memphis.edu>
Message-ID: <CAOFH+ObVN985Ewms+c9v6azfEOjkb3JOY9mJayu0LTJCN20VGA@mail.gmail.com>

Hi Lan

Before I can suggest any code patches, additional experiment is needed to
confirm or reject the hypothesis in
http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2015-April/001049.html .

If you want to measure RTT changes due to route changes, one possible way
is to increase the link delay.
When the link delay is 10ms, a 10ms RTT change is 50% and appears
significant.
When the link delay is 500ms, a 10ms RTT change is 1% and appears
negligible.

Yours, Junxiao

On Fri, Apr 24, 2015 at 11:33 AM, Lan Wang (lanwang) <lanwang at memphis.edu>
wrote:

>  Basically, we saw a large jump in ndnping results between two nodes even
> though there was no path change for the path between those two nodes.  We
> found that it was because those nodes (or the intermediate ones) were busy
> updating their FIB (for other routes) -- each registration and
> unregistration of a route obviously took ~10ms for NRD/NFD to process.
>
>  We were interested in RTT changes due to route changes, so the extra
> delay caused by the route registrations is an undesirable side effect we'd
> like to remove (thus Vince's email).  So any suggestions on how to deal
> with this in our experiments are highly appreciated.
>
>  In the long term, we do need to address the problem of high processing
> delays of route registrations.
>
> Lan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150424/b116f66b/attachment.html>

From antil.janu at gmail.com  Sun Apr 26 13:06:36 2015
From: antil.janu at gmail.com (antil janu)
Date: Sun, 26 Apr 2015 13:06:36 -0700
Subject: [Nfd-dev] NFD Compilation error(?)
Message-ID: <CAHsjXorL2G51+JThyVtdGDu-O=giYRiz0jLgGELyeLJFH=V1=g@mail.gmail.com>

I am hitting this compilation error after upgrading the NFD source.

[ 40/121] Compiling daemon/mgmt/face-query-status-publisher.cpp
[ 44/121] Compiling daemon/fw/retx-suppression-fixed.cpp
[109/121] Compiling core/logger.cpp
[110/121] Compiling daemon/mgmt/channel-status-publisher.cpp
../core/logger.cpp: In static member function ?static const char*
nfd::Logger::now()?:
../core/logger.cpp:61:3: error: static assertion failed: "PRIdLEAST64 is
incompatible with microseconds::rep"
../core/logger.cpp:67:47: warning: format ?%ld? expects argument of type
?long int?, but argument 4 has type ?boost::chrono::duration<long long int,
boost::ratio<1ll, 1000000ll> >::rep {aka long long int}? [-Wformat]
../core/logger.cpp:67:47: warning: format ?%ld? expects argument of type
?long int?, but argument 5 has type ?boost::chrono::duration<long long int,
boost::ratio<1ll, 1000000ll> >::rep {aka long long int}? [-Wformat]


I am using below g++ compiler.

/usr/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/usr/bin/g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.6.4-6ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-gnu-unique-object --disable-libmudflap
--enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.4 (Ubuntu/Linaro 4.6.4-6ubuntu2)


configure log contained this three 'no' instances.

Checking for program 'tar'               : /bin/tar
Checking for program 'sphinx-build'      : /usr/bin/sphinx-build
Checking for std::is_default_constructible : no
Checking for std::is_move_constructible    : no
Checking for override specifier            : no
Checking for std::to_string                : yes
Checking for program 'bash'                : /bin/bash
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150426/6e0322b8/attachment.html>

From shijunxiao at email.arizona.edu  Sun Apr 26 13:27:52 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Sun, 26 Apr 2015 13:27:52 -0700
Subject: [Nfd-dev] NFD Compilation error(?)
In-Reply-To: <CAHsjXorL2G51+JThyVtdGDu-O=giYRiz0jLgGELyeLJFH=V1=g@mail.gmail.com>
References: <CAHsjXorL2G51+JThyVtdGDu-O=giYRiz0jLgGELyeLJFH=V1=g@mail.gmail.com>
Message-ID: <CAOFH+OYoQya4ULsKvo2k6QV0kn2DTs95pRu1_OsT_gTZdTvr-w@mail.gmail.com>

Hi antil

This looks similar to Bug 2651 http://redmine.named-data.net/issues/2651
Please delete all versions of Boost libraries, and reinstall only one
version of Boost libraries.

Yours, Junxiao
On Apr 26, 2015 1:07 PM, "antil janu" <antil.janu at gmail.com> wrote:

> I am hitting this compilation error after upgrading the NFD source.
>
> [ 40/121] Compiling daemon/mgmt/face-query-status-publisher.cpp
> [ 44/121] Compiling daemon/fw/retx-suppression-fixed.cpp
> [109/121] Compiling core/logger.cpp
> [110/121] Compiling daemon/mgmt/channel-status-publisher.cpp
> ../core/logger.cpp: In static member function ?static const char*
> nfd::Logger::now()?:
> ../core/logger.cpp:61:3: error: static assertion failed: "PRIdLEAST64 is
> incompatible with microseconds::rep"
> ../core/logger.cpp:67:47: warning: format ?%ld? expects argument of type
> ?long int?, but argument 4 has type ?boost::chrono::duration<long long int,
> boost::ratio<1ll, 1000000ll> >::rep {aka long long int}? [-Wformat]
> ../core/logger.cpp:67:47: warning: format ?%ld? expects argument of type
> ?long int?, but argument 5 has type ?boost::chrono::duration<long long int,
> boost::ratio<1ll, 1000000ll> >::rep {aka long long int}? [-Wformat]
>
>
> I am using below g++ compiler.
>
> /usr/bin/g++ -v
> Using built-in specs.
> COLLECT_GCC=/usr/bin/g++
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
> 4.6.4-6ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
> --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
> --program-suffix=-4.6 --enable-shared --enable-linker-build-id
> --with-system-zlib --libexecdir=/usr/lib --without-included-gettext
> --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
> --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
> --enable-libstdcxx-debug --enable-gnu-unique-object --disable-libmudflap
> --enable-plugin --enable-objc-gc --disable-werror --with-arch-32=i686
> --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
> --host=x86_64-linux-gnu --target=x86_64-linux-gnu
> Thread model: posix
> gcc version 4.6.4 (Ubuntu/Linaro 4.6.4-6ubuntu2)
>
>
> configure log contained this three 'no' instances.
>
> Checking for program 'tar'               : /bin/tar
> Checking for program 'sphinx-build'      : /usr/bin/sphinx-build
> Checking for std::is_default_constructible : no
> Checking for std::is_move_constructible    : no
> Checking for override specifier            : no
> Checking for std::to_string                : yes
> Checking for program 'bash'                : /bin/bash
>
>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150426/f3ed36b1/attachment.html>

From agawande at memphis.edu  Wed Apr 29 12:44:51 2015
From: agawande at memphis.edu (Ashlesh Gawande (agawande))
Date: Wed, 29 Apr 2015 19:44:51 +0000
Subject: [Nfd-dev] NLSR failed to connect with NFD in Banana
 Pro	(Raspbian OS)
In-Reply-To: <CAA5Vy7QpeLAk5dwHN_ncGHWTpE_7NBFAcYpHZwk-RJKu2oxTpQ@mail.gmail.com>
References: <CAA5Vy7RwA-0kZsSKvu+bqv+45aS0+wN_f+K963+Ez2d0eAh0DA@mail.gmail.com>
	<BB7514AB-4476-4C13-97A8-BE0F86B5D3A9@memphis.edu>
	<CAA5Vy7Sf_McVDqxidEPUY2SUGGHu1WwT7J_dZcfqrGxs_CRLEA@mail.gmail.com>
	<B4258BD6-2D1E-42EF-980B-47595C5173FF@memphis.edu>,
	<CAA5Vy7QpeLAk5dwHN_ncGHWTpE_7NBFAcYpHZwk-RJKu2oxTpQ@mail.gmail.com>
Message-ID: <1430336696395.71859@memphis.edu>

Hi


I got the same error on raspberry pi while trying to run NLSR and have filed a bug report. We are looking into it.

http://redmine.named-data.net/issues/2780


Regards

Ashlesh

________________________________
From: Nfd-dev <nfd-dev-bounces at lists.cs.ucla.edu> on behalf of Mahyuddin Husairi <mahyuddin at gmail.com>
Sent: Monday, April 13, 2015 5:05 PM
To: Lan Wang (lanwang)
Cc: nfd-dev at lists.cs.ucla.edu
Subject: Re: [Nfd-dev] NLSR failed to connect with NFD in Banana Pro (Raspbian OS)

Glad to hear that.
I think, implementing NDN on any arm chip and/or other embedded should be taken seriously by us to increase the adaptation of NDN. My research is related to mesh network on mobile device (im using BananaPro to represent wireless mobile device) and my hypothesis that by using NDN based dynamic routing, it will solve reliability, stability and energy efficiency issues facing by point to point based routing. Of course to develop my own dynamic routing implementation, NLSR is my starting point to understand how to do routing in NDN. Instead doing simulation which i've done it through ndnsim2, i want to evaluate NDN dynamic routing in real world/testbed. But it seems that i stuck with unknown problem.

On Tue, Apr 14, 2015 at 4:50 AM, Lan Wang (lanwang) <lanwang at memphis.edu<mailto:lanwang at memphis.edu>> wrote:
Someone has tried Raspberry Pi, but also had a problem.  We'll test NLSR in the lab with RPi's.  Maybe it'll help understand your problem as well.

Regarding the "ERROR: error while connecting to the forwarder", it is generated by ndn-cxx (NLSR uses ndn-cxx to connect to the forwarder).

Lan

On Apr 13, 2015, at 3:01 PM, Mahyuddin Husairi <mahyuddin at gmail.com<mailto:mahyuddin at gmail.com>>
 wrote:

Thanks for a reply.
1. Thanks for the explanation. Im aware that NLSR is communicating with NFD by using unix socket and we can change that to use tcp tunnel (unicast) by changing configuration inside client.conf but the same problem occur.
2. I tried both stable and latest version from github.
3. There is no problem during compilation (ndn-cxx, NFD and NLSR), except some assembler warning message
    /tmp/ccAiTF1c.s: Assembler messages:
    /tmp/ccAiTF1c.s:23842: Warning: swp{b} use is deprecated for ARMv6 and ARMv7
    /tmp/ccAiTF1c.s:24348: Warning: swp{b} use is deprecated for ARMv6 and ARMv7
5. Is there anybody already tried running both NFD and NLSR on any single board computer(SBC) such as Raspberry Pi or Banana Pi?


On Mon, Apr 13, 2015 at 10:53 PM, Lan Wang (lanwang) <lanwang at memphis.edu<mailto:lanwang at memphis.edu>> wrote:
Not sure what's the problem.  Just some info and

- Somehow NLSR has difficulty getting connected with NFD.  It needs to send Interest and receive Data through that face.  If I understand correctly, they use UNIX socket to connect by default (and there's a default file name corresponding to the UNIX socket in the NFD configuration).

- Where did you download NLSR?  The GitHub version https://github.com/named-data/NLSR  is the latest.  Were there any warnings or problems during the compile and installation?

Lan

On Apr 13, 2015, at 5:06 AM, Mahyuddin Husairi <mahyuddin at gmail.com<mailto:mahyuddin at gmail.com>>
 wrote:

I just successfully compile and install ndn-cxx, NFD and NLSR on Banana Pro (design and produced by LeMaker - http://www.lemaker.org/).

I can run NFD as usual and create face and register prefix using nfdc. After that i run several test using ndn-tlv-ping and ndn-traffic and everything is run smoothly.

The problem is, when i run NLSR, it will simply throw error message "ERROR: error while connecting to the forwarder" even though NFD is running. In nlsr log file it is just simply throw the same error message "ERROR: error while connecting to the forwarder". Something like below


20150413175010040 DEBUG: [HelloProtocol] Scheduling HELLO Interests in 10 seconds
20150413175010047 DEBUG: [nlsr] Process daemonized. Process id: 14975
20150413175010053 FATAL: [Main] ERROR: error while connecting to the forwarder
20150413175010057 DEBUG: [Fib] Fib::clean called


Seems like it will crash once NLSR start to setup Hello protocol schedule. So, because of lack of details in NLSR log message i tried strace to run NLSR and the output from strace are something like this


gettimeofday({1428918610, 40666}, NULL) = 0
write(10, "20150413175010040 DEBUG: [HelloP"..., 82) = 82
clock_gettime(CLOCK_MONOTONIC, {367502, 38604022}) = 0
clock_gettime(CLOCK_MONOTONIC, {367502, 39270498}) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb4cbc288) = 14975
gettimeofday({1428918610, 47614}, NULL) = 0
write(10, "20150413175010047 DEBUG: [nlsr] "..., 70) = 70
close(9)                                = 0
close(10)                               = 0
ERROR: error while connecting to the forwardermunmap(0xb6f5a000, 8192)                = 0


I'm using the same NFD and NLSR configuration setup that i successfully run on my ubuntu desktop. Is that related to libboost_random (boost library version is 1.49) or probably because Banana Pro is not using real hardware clock? I'm just clueless.


--
Human knowledge Belongs to The World
_______________________________________________
Nfd-dev mailing list
Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev




--
Human knowledge Belongs to The World




--
Human knowledge Belongs to The World
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150429/d941ba67/attachment.html>

From lanwang at memphis.edu  Wed Apr 29 14:43:25 2015
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Wed, 29 Apr 2015 21:43:25 +0000
Subject: [Nfd-dev] NLSR failed to connect with NFD in Banana
 Pro	(Raspbian OS)
In-Reply-To: <1430336696395.71859@memphis.edu>
References: <CAA5Vy7RwA-0kZsSKvu+bqv+45aS0+wN_f+K963+Ez2d0eAh0DA@mail.gmail.com>
	<BB7514AB-4476-4C13-97A8-BE0F86B5D3A9@memphis.edu>
	<CAA5Vy7Sf_McVDqxidEPUY2SUGGHu1WwT7J_dZcfqrGxs_CRLEA@mail.gmail.com>
	<B4258BD6-2D1E-42EF-980B-47595C5173FF@memphis.edu>,
	<CAA5Vy7QpeLAk5dwHN_ncGHWTpE_7NBFAcYpHZwk-RJKu2oxTpQ@mail.gmail.com>,
	<1430336696395.71859@memphis.edu>
Message-ID: <758A2589-4A0B-4A89-AE7F-FCBB9E8BF0CB@memphis.edu>

Just a clarification, this error seems to be related to OpenSSL (see the details in the redmine issue).  We do not know how to fix this, and would appreciate help from anyone familiar with raspberry pi.

Lan

On Apr 29, 2015, at 2:44 PM, Ashlesh Gawande (agawande) <agawande at memphis.edu<mailto:agawande at memphis.edu>> wrote:


Hi


I got the same error on raspberry pi while trying to run NLSR and have filed a bug report. We are looking into it.

http://redmine.named-data.net/issues/2780


Regards

Ashlesh

________________________________
From: Nfd-dev <nfd-dev-bounces at lists.cs.ucla.edu<mailto:nfd-dev-bounces at lists.cs.ucla.edu>> on behalf of Mahyuddin Husairi <mahyuddin at gmail.com<mailto:mahyuddin at gmail.com>>
Sent: Monday, April 13, 2015 5:05 PM
To: Lan Wang (lanwang)
Cc: nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>
Subject: Re: [Nfd-dev] NLSR failed to connect with NFD in Banana Pro (Raspbian OS)

Glad to hear that.
I think, implementing NDN on any arm chip and/or other embedded should be taken seriously by us to increase the adaptation of NDN. My research is related to mesh network on mobile device (im using BananaPro to represent wireless mobile device) and my hypothesis that by using NDN based dynamic routing, it will solve reliability, stability and energy efficiency issues facing by point to point based routing. Of course to develop my own dynamic routing implementation, NLSR is my starting point to understand how to do routing in NDN. Instead doing simulation which i've done it through ndnsim2, i want to evaluate NDN dynamic routing in real world/testbed. But it seems that i stuck with unknown problem.

On Tue, Apr 14, 2015 at 4:50 AM, Lan Wang (lanwang) <lanwang at memphis.edu<mailto:lanwang at memphis.edu>> wrote:
Someone has tried Raspberry Pi, but also had a problem.  We'll test NLSR in the lab with RPi's.  Maybe it'll help understand your problem as well.

Regarding the "ERROR: error while connecting to the forwarder", it is generated by ndn-cxx (NLSR uses ndn-cxx to connect to the forwarder).

Lan

On Apr 13, 2015, at 3:01 PM, Mahyuddin Husairi <mahyuddin at gmail.com<mailto:mahyuddin at gmail.com>>
 wrote:

Thanks for a reply.
1. Thanks for the explanation. Im aware that NLSR is communicating with NFD by using unix socket and we can change that to use tcp tunnel (unicast) by changing configuration inside client.conf but the same problem occur.
2. I tried both stable and latest version from github.
3. There is no problem during compilation (ndn-cxx, NFD and NLSR), except some assembler warning message
    /tmp/ccAiTF1c.s: Assembler messages:
    /tmp/ccAiTF1c.s:23842: Warning: swp{b} use is deprecated for ARMv6 and ARMv7
    /tmp/ccAiTF1c.s:24348: Warning: swp{b} use is deprecated for ARMv6 and ARMv7
5. Is there anybody already tried running both NFD and NLSR on any single board computer(SBC) such as Raspberry Pi or Banana Pi?


On Mon, Apr 13, 2015 at 10:53 PM, Lan Wang (lanwang) <lanwang at memphis.edu<mailto:lanwang at memphis.edu>> wrote:
Not sure what's the problem.  Just some info and

- Somehow NLSR has difficulty getting connected with NFD.  It needs to send Interest and receive Data through that face.  If I understand correctly, they use UNIX socket to connect by default (and there's a default file name corresponding to the UNIX socket in the NFD configuration).

- Where did you download NLSR?  The GitHub version https://github.com/named-data/NLSR  is the latest.  Were there any warnings or problems during the compile and installation?

Lan

On Apr 13, 2015, at 5:06 AM, Mahyuddin Husairi <mahyuddin at gmail.com<mailto:mahyuddin at gmail.com>>
 wrote:

I just successfully compile and install ndn-cxx, NFD and NLSR on Banana Pro (design and produced by LeMaker - http://www.lemaker.org/).

I can run NFD as usual and create face and register prefix using nfdc. After that i run several test using ndn-tlv-ping and ndn-traffic and everything is run smoothly.

The problem is, when i run NLSR, it will simply throw error message "ERROR: error while connecting to the forwarder" even though NFD is running. In nlsr log file it is just simply throw the same error message "ERROR: error while connecting to the forwarder". Something like below


20150413175010040 DEBUG: [HelloProtocol] Scheduling HELLO Interests in 10 seconds
20150413175010047 DEBUG: [nlsr] Process daemonized. Process id: 14975
20150413175010053 FATAL: [Main] ERROR: error while connecting to the forwarder
20150413175010057 DEBUG: [Fib] Fib::clean called


Seems like it will crash once NLSR start to setup Hello protocol schedule. So, because of lack of details in NLSR log message i tried strace to run NLSR and the output from strace are something like this


gettimeofday({1428918610, 40666}, NULL) = 0
write(10, "20150413175010040 DEBUG: [HelloP"..., 82) = 82
clock_gettime(CLOCK_MONOTONIC, {367502, 38604022}) = 0
clock_gettime(CLOCK_MONOTONIC, {367502, 39270498}) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb4cbc288) = 14975
gettimeofday({1428918610, 47614}, NULL) = 0
write(10, "20150413175010047 DEBUG: [nlsr] "..., 70) = 70
close(9)                                = 0
close(10)                               = 0
ERROR: error while connecting to the forwardermunmap(0xb6f5a000, 8192)                = 0


I'm using the same NFD and NLSR configuration setup that i successfully run on my ubuntu desktop. Is that related to libboost_random (boost library version is 1.49) or probably because Banana Pro is not using real hardware clock? I'm just clueless.


--
Human knowledge Belongs to The World
_______________________________________________
Nfd-dev mailing list
Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev




--
Human knowledge Belongs to The World




--
Human knowledge Belongs to The World
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150429/f2add80d/attachment.html>

From shijunxiao at email.arizona.edu  Thu Apr 30 12:19:36 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Thu, 30 Apr 2015 12:19:36 -0700
Subject: [Nfd-dev] PIB service causes remote registration of every prefix
Message-ID: <CAOFH+OZr5fgrLn=E5_fOAwL6FO-rVtG7x=hi_ikdAeE=PbCFPw@mail.gmail.com>

Dear folks
This message alerts a potential conflict between PIB service and remote
registration.

PIB service
PIB service publishes one or more certificates owned by a laptop user, by
answering Interests that requesting for those certificate.
In order to receive those Interests, PIB service needs to register prefixes
on laptop NFD.
PIB service may either (1) register the root prefix "ndn:/", or (2)
register one prefix per certificate.

The advantage of registering the root prefix is that PIB service only needs
one entry in NFD RIB and FIB.
The drawback is (a) PIB service will receive many unrelated Interests (b)
route inheritance flags 'CAPTURE' used by another app would prevent PIB
service from receive Interests for some certificate.

Due to those drawbacks, PIB service is designed to register one prefix per
certificate.

Remote registration
In order for a laptop to receive Interests from the network, NFD RIB
service can be configured to register local prefixes onto a connected
gateway router.
When a local app registers a route in RIB, the RIB will send a registration
command to the gateway if it is authorized to do so.

The conflict
When reading #2201 note-12
<http://redmine.named-data.net/issues/2201#note-12>, I realize that same
issue can happen with PIB service.

In hierarchical trust model, the user must own a certificate for a certain
namespace in order to register a prefix under that namespace.
And then, this certificate is expected to be published in PIB service,
which means PIB service is going to register a prefix for this certificate.
The route registered by PIB service in turn triggers NFD RIB service to
perform remote prefix registration.

The result is: every prefix owned by the user will be registered onto the
gateway router, even if no other app is using those prefixes.

Is it good or bad?
Argument can go both ways on whether the result above is good or bad.

Good: The network may want to retrieve those certificates, so it's correct
to register those prefixes onto the gateway router.
Bad: Remote registration is designed to register prefixes on demand when an
app wants to publish. PIB service could be perceived as "not a real app".
If every prefix is registered, it's no longer "on demand".

Possible solution
If we want to avoid remote registration for PIB service routes, we could
add NO_REMOTE_REGISTRATION flag in rib/register command.


Yours, Junxiao
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150430/d31766c2/attachment.html>