From vslehman at memphis.edu  Tue May  5 06:37:03 2015
From: vslehman at memphis.edu (Vince Lehman (vslehman))
Date: Tue, 5 May 2015 13:37:03 +0000
Subject: [Nfd-dev] RTT delay caused by RIB registration commands
In-Reply-To: <CAOFH+ObVN985Ewms+c9v6azfEOjkb3JOY9mJayu0LTJCN20VGA@mail.gmail.com>
References: <2E7F0681-E8C1-49F6-BAEA-8A48F3B4B4E8@memphis.edu>
	<D10AB5AE-A329-49F3-A967-3CCF75C6B89F@memphis.edu>
	<CAOFH+ObVN985Ewms+c9v6azfEOjkb3JOY9mJayu0LTJCN20VGA@mail.gmail.com>
Message-ID: <8DF5E537-B6CE-4B9E-BF73-EF826CC236AA@memphis.edu>

Hi Junxiao,

A registration for a new UDP face causes the RTT to increase slightly, ~2ms above the previous experiment:

Content From /ndn - Ping Reference = 477477776   - Round Trip Time = 0.778 ms
Content From /ndn - Ping Reference = 477477777   - Round Trip Time = 0.649 ms
Content From /ndn - Ping Reference = 477477778   - Round Trip Time = 16.614 ms
Content From /ndn - Ping Reference = 477477779   - Round Trip Time = 0.982 ms

A registration for a non-existent face ID causes a large increase in the RTT:

Content From /ndn - Ping Reference = 479746716   - Round Trip Time = 0.77 ms
Content From /ndn - Ping Reference = 479746717   - Round Trip Time = 0.695 ms
Content From /ndn - Ping Reference = 479746718   - Round Trip Time = 52.996 ms
Content From /ndn - Ping Reference = 479746719   - Round Trip Time = 0.808 ms

Since we simply want to update the expiration time for a particular namespace in the RIB, would there be any use for a protocol extension that allows for the expiration time for a namespace to be updated with one RIB command?
--
Vince Lehman

On Apr 24, 2015, at 1:38 PM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:

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<mailto: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/20150505/aa64e875/attachment.html>

From vslehman at memphis.edu  Tue May  5 13:46:37 2015
From: vslehman at memphis.edu (Vince Lehman (vslehman))
Date: Tue, 5 May 2015 20:46:37 +0000
Subject: [Nfd-dev] Jenkins FreeBSD node maintenance
Message-ID: <05DB0938-E897-4E10-8894-6206D7304560@memphis.edu>

Hi all,

We would like to bring down the Jenkins FreeBSD-10.1 node for maintenance on Thursday, May 7 from 1:00 PM - 5:00 PM CST.

Please let us know if this would inconvenience you, and if so, what maintenance time would be more preferable. Thanks.

--
Vince Lehman

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

From shijunxiao at email.arizona.edu  Wed May  6 15:26:55 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Wed, 6 May 2015 15:26:55 -0700
Subject: [Nfd-dev] PIB service causes remote registration of every prefix
In-Reply-To: <CAOFH+OZr5fgrLn=E5_fOAwL6FO-rVtG7x=hi_ikdAeE=PbCFPw@mail.gmail.com>
References: <CAOFH+OZr5fgrLn=E5_fOAwL6FO-rVtG7x=hi_ikdAeE=PbCFPw@mail.gmail.com>
Message-ID: <CAOFH+OavRZDyBy2ok8eGNSWv4BWmd+-WriKvCbaEkUYSNgTDmg@mail.gmail.com>

Dear folks

20150506 conference call discussed this problem.
We conclude that it's acceptable to remote register prefixes for all
certificates, because certificates should be made available on the networks
so that others can verify previously generated Data that references those
certificates.
No design change is needed.

Yours, Junxiao

On Thu, Apr 30, 2015 at 12:19 PM, Junxiao Shi <shijunxiao at email.arizona.edu>
wrote:

> 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/20150506/6e41e635/attachment.html>

From vslehman at memphis.edu  Wed May  6 16:04:45 2015
From: vslehman at memphis.edu (Vince Lehman (vslehman))
Date: Wed, 6 May 2015 23:04:45 +0000
Subject: [Nfd-dev] RTT delay caused by RIB registration commands
In-Reply-To: <8DF5E537-B6CE-4B9E-BF73-EF826CC236AA@memphis.edu>
References: <2E7F0681-E8C1-49F6-BAEA-8A48F3B4B4E8@memphis.edu>
	<D10AB5AE-A329-49F3-A967-3CCF75C6B89F@memphis.edu>
	<CAOFH+ObVN985Ewms+c9v6azfEOjkb3JOY9mJayu0LTJCN20VGA@mail.gmail.com>
	<8DF5E537-B6CE-4B9E-BF73-EF826CC236AA@memphis.edu>
Message-ID: <122E97D6-A2CF-4CBE-BD8A-CF82767241DA@memphis.edu>

At the NFD call today, it was suggested that I try our experiments with a different, quicker signing method for NFD?s management modules.

I ran the following three tests:

1.) Unmodified NFD to get baseline results
2.) NFD with management modules using KeyChain::signWithSha256 for control responses
3.) Test 2 + modified ndn::nfd::Controller in ndn-cxx so control commands are signed using KeyChain::signWithSha256

The results I collected suggest that signing is largely the cause of the RTT jumps.

1. ) Unchanged NFD using KeyChain::sign():

20150506T220013.546312 - Content From /ndn/edu/orange - Ping Reference = 358723384   - Round Trip Time = 7.54174 ms
20150506T220014.545910 - Content From /ndn/edu/orange - Ping Reference = 358723385   - Round Trip Time = 7.35931 ms
20150506T220015.549327 - Content From /ndn/edu/orange - Ping Reference = 358723386   - Round Trip Time = 10.755 ms
20150506T220016.569095 - Content From /ndn/edu/orange - Ping Reference = 358723387   - Round Trip Time = 26.909 ms
20150506T220017.554450 - Content From /ndn/edu/orange - Ping Reference = 358723388   - Round Trip Time = 15.8414 ms
20150506T220018.550272 - Content From /ndn/edu/orange - Ping Reference = 358723389   - Round Trip Time = 11.7576 ms
20150506T220019.594078 - Content From /ndn/edu/orange - Ping Reference = 358723390   - Round Trip Time = 52.0413 ms
20150506T220020.572899 - Content From /ndn/edu/orange - Ping Reference = 358723391   - Round Trip Time = 31.8473 ms
20150506T220021.568606 - Content From /ndn/edu/orange - Ping Reference = 358723392   - Round Trip Time = 29.9206 ms
20150506T220022.545620 - Content From /ndn/edu/orange - Ping Reference = 358723393   - Round Trip Time = 7.09895 ms
20150506T220023.551988 - Content From /ndn/edu/orange - Ping Reference = 358723394   - Round Trip Time = 13.4654 ms
20150506T220024.564711 - Content From /ndn/edu/orange - Ping Reference = 358723395   - Round Trip Time = 26.1983 ms
20150506T220025.590458 - Content From /ndn/edu/orange - Ping Reference = 358723396   - Round Trip Time = 51.8421 ms
20150506T220026.547079 - Content From /ndn/edu/orange - Ping Reference = 358723397   - Round Trip Time = 8.38067 ms
20150506T220027.546382 - Content From /ndn/edu/orange - Ping Reference = 358723398   - Round Trip Time = 7.7887 ms

2.) NFD Management using KeyChain::signWithSha256() for control responses:

20150506T220832.990110 - Content From /ndn/edu/orange - Ping Reference = 481750786   - Round Trip Time = 8.12952 ms
20150506T220833.989616 - Content From /ndn/edu/orange - Ping Reference = 481750787   - Round Trip Time = 7.27718 ms
20150506T220835.000043 - Content From /ndn/edu/orange - Ping Reference = 481750788   - Round Trip Time = 17.7199 ms
20150506T220835.997854 - Content From /ndn/edu/orange - Ping Reference = 481750789   - Round Trip Time = 15.8593 ms
20150506T220836.990831 - Content From /ndn/edu/orange - Ping Reference = 481750790   - Round Trip Time = 8.84247 ms
20150506T220838.011070 - Content From /ndn/edu/orange - Ping Reference = 481750791   - Round Trip Time = 17.0122 ms
20150506T220839.022594 - Content From /ndn/edu/orange - Ping Reference = 481750792   - Round Trip Time = 40.5401 ms
20150506T220839.996497 - Content From /ndn/edu/orange - Ping Reference = 481750793   - Round Trip Time = 13.9247 ms
20150506T220841.000317 - Content From /ndn/edu/orange - Ping Reference = 481750794   - Round Trip Time = 18.0118 ms
20150506T220841.990391 - Content From /ndn/edu/orange - Ping Reference = 481750795   - Round Trip Time = 8.36782 ms
20150506T220842.989631 - Content From /ndn/edu/orange - Ping Reference = 481750796   - Round Trip Time = 7.57163 ms
20150506T220843.990083 - Content From /ndn/edu/orange - Ping Reference = 481750797   - Round Trip Time = 7.9309 ms

3.) NFD Management using KeyChain::signWithSha256() and ndn::nfd::Controller::start() using KeyChain::signWithSha256:

20150506T224746.920419 - Content From /ndn/edu/orange - Ping Reference = 432571709   - Round Trip Time = 7.74707 ms
20150506T224747.920684 - Content From /ndn/edu/orange - Ping Reference = 432571710   - Round Trip Time = 8.08427 ms
20150506T224748.921073 - Content From /ndn/edu/orange - Ping Reference = 432571711   - Round Trip Time = 7.95967 ms
20150506T224749.920619 - Content From /ndn/edu/orange - Ping Reference = 432571712   - Round Trip Time = 7.78507 ms
20150506T224750.923189 - Content From /ndn/edu/orange - Ping Reference = 432571713   - Round Trip Time = 10.5592 ms
20150506T224751.920660 - Content From /ndn/edu/orange - Ping Reference = 432571714   - Round Trip Time = 7.73255 ms
20150506T224752.920939 - Content From /ndn/edu/orange - Ping Reference = 432571715   - Round Trip Time = 8.24211 ms
20150506T224753.923819 - Content From /ndn/edu/orange - Ping Reference = 432571716   - Round Trip Time = 9.19251 ms
20150506T224754.921798 - Content From /ndn/edu/orange - Ping Reference = 432571717   - Round Trip Time = 8.94248 ms
20150506T224755.924729 - Content From /ndn/edu/orange - Ping Reference = 432571718   - Round Trip Time = 12.0222 ms
20150506T224756.920302 - Content From /ndn/edu/orange - Ping Reference = 432571719   - Round Trip Time = 7.75629 ms


--
Vince Lehman

On May 5, 2015, at 8:37 AM, Vince Lehman (vslehman) <vslehman at memphis.edu<mailto:vslehman at memphis.edu>> wrote:

Hi Junxiao,

A registration for a new UDP face causes the RTT to increase slightly, ~2ms above the previous experiment:

Content From /ndn - Ping Reference = 477477776   - Round Trip Time = 0.778 ms
Content From /ndn - Ping Reference = 477477777   - Round Trip Time = 0.649 ms
Content From /ndn - Ping Reference = 477477778   - Round Trip Time = 16.614 ms
Content From /ndn - Ping Reference = 477477779   - Round Trip Time = 0.982 ms

A registration for a non-existent face ID causes a large increase in the RTT:

Content From /ndn - Ping Reference = 479746716   - Round Trip Time = 0.77 ms
Content From /ndn - Ping Reference = 479746717   - Round Trip Time = 0.695 ms
Content From /ndn - Ping Reference = 479746718   - Round Trip Time = 52.996 ms
Content From /ndn - Ping Reference = 479746719   - Round Trip Time = 0.808 ms

Since we simply want to update the expiration time for a particular namespace in the RIB, would there be any use for a protocol extension that allows for the expiration time for a namespace to be updated with one RIB command?
--
Vince Lehman

On Apr 24, 2015, at 1:38 PM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:

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


_______________________________________________
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/20150506/ee313c27/attachment.html>

From shijunxiao at email.ARIZONA.EDU  Wed May  6 17:04:13 2015
From: shijunxiao at email.ARIZONA.EDU (Junxiao Shi)
Date: Wed, 6 May 2015 17:04:13 -0700
Subject: [Nfd-dev] RTT delay caused by RIB registration commands
In-Reply-To: <122E97D6-A2CF-4CBE-BD8A-CF82767241DA@memphis.edu>
References: <2E7F0681-E8C1-49F6-BAEA-8A48F3B4B4E8@memphis.edu>
	<D10AB5AE-A329-49F3-A967-3CCF75C6B89F@memphis.edu>
	<CAOFH+ObVN985Ewms+c9v6azfEOjkb3JOY9mJayu0LTJCN20VGA@mail.gmail.com>
	<8DF5E537-B6CE-4B9E-BF73-EF826CC236AA@memphis.edu>
	<122E97D6-A2CF-4CBE-BD8A-CF82767241DA@memphis.edu>
Message-ID: <CAOFH+Obrs1_bNOqZhJyboFUuPxn6pz2E79vSW-+LEz4kEFYizw@mail.gmail.com>

Hi Vince

Summary from your logs:

   1. NFD=RSA, ndn::nfd::Controller=RSA: min 7.098ms, max 52.041ms
   2. NFD=SHA256, ndn::nfd::Controller=RSA: min 7.277ms, max 40.540ms
   3. NFD=SHA256, ndn::nfd::Controller=SHA256: min 7.732ms, max 12.022ms

This shows a correlation between signing algorithm and max RTT, but the
variance is much larger compared to the logs from Apr 23.
Are you using a different machine?
How many CPU cores does this machine have? There shouldn't be much
difference between 2 and 3 on a quad-core machine.

Also, please confirm you have changed ".sign(" to ".signWithSha256(" in all
these files for "NFD Management":

   - NFD/core/segment-publisher.hpp (for answering face query; unnecessary
   if nfdc is using a FaceId)
   - NFD/core/notification-stream.hpp (for generating face status change
   notifications)
   - NFD/daemon/mgmt/manager-base.cpp (for answering commands)


Yours, Junxiao

On Wed, May 6, 2015 at 4:04 PM, Vince Lehman (vslehman) <
vslehman at memphis.edu> wrote:

>  At the NFD call today, it was suggested that I try our experiments with a
> different, quicker signing method for NFD?s management modules.
>
>  I ran the following three tests:
>
>  1.) Unmodified NFD to get baseline results
> 2.) NFD with management modules using KeyChain::signWithSha256 for control
> responses
> 3.) Test 2 + modified ndn::nfd::Controller in ndn-cxx so control commands
> are signed using KeyChain::signWithSha256
>
>  The results I collected suggest that signing is largely the cause of the
> RTT jumps.
>
>  1. ) Unchanged NFD using KeyChain::sign():
>
>  20150506T220013.546312 - Content From /ndn/edu/orange - Ping Reference =
> 358723384   - Round Trip Time = 7.54174 ms
> 20150506T220014.545910 - Content From /ndn/edu/orange - Ping Reference =
> 358723385   - Round Trip Time = 7.35931 ms
> 20150506T220015.549327 - Content From /ndn/edu/orange - Ping Reference =
> 358723386   - Round Trip Time = 10.755 ms
> 20150506T220016.569095 - Content From /ndn/edu/orange - Ping Reference =
> 358723387   - Round Trip Time = 26.909 ms
> 20150506T220017.554450 - Content From /ndn/edu/orange - Ping Reference =
> 358723388   - Round Trip Time = 15.8414 ms
> 20150506T220018.550272 - Content From /ndn/edu/orange - Ping Reference =
> 358723389   - Round Trip Time = 11.7576 ms
> 20150506T220019.594078 - Content From /ndn/edu/orange - Ping Reference =
> 358723390   - Round Trip Time = 52.0413 ms
> 20150506T220020.572899 - Content From /ndn/edu/orange - Ping Reference =
> 358723391   - Round Trip Time = 31.8473 ms
> 20150506T220021.568606 - Content From /ndn/edu/orange - Ping Reference =
> 358723392   - Round Trip Time = 29.9206 ms
> 20150506T220022.545620 - Content From /ndn/edu/orange - Ping Reference =
> 358723393   - Round Trip Time = 7.09895 ms
> 20150506T220023.551988 - Content From /ndn/edu/orange - Ping Reference =
> 358723394   - Round Trip Time = 13.4654 ms
> 20150506T220024.564711 - Content From /ndn/edu/orange - Ping Reference =
> 358723395   - Round Trip Time = 26.1983 ms
> 20150506T220025.590458 - Content From /ndn/edu/orange - Ping Reference =
> 358723396   - Round Trip Time = 51.8421 ms
> 20150506T220026.547079 - Content From /ndn/edu/orange - Ping Reference =
> 358723397   - Round Trip Time = 8.38067 ms
> 20150506T220027.546382 - Content From /ndn/edu/orange - Ping Reference =
> 358723398   - Round Trip Time = 7.7887 ms
>
>  2.) NFD Management using KeyChain::signWithSha256() for control
> responses:
>
>  20150506T220832.990110 - Content From /ndn/edu/orange - Ping Reference =
> 481750786   - Round Trip Time = 8.12952 ms
> 20150506T220833.989616 - Content From /ndn/edu/orange - Ping Reference =
> 481750787   - Round Trip Time = 7.27718 ms
> 20150506T220835.000043 - Content From /ndn/edu/orange - Ping Reference =
> 481750788   - Round Trip Time = 17.7199 ms
> 20150506T220835.997854 - Content From /ndn/edu/orange - Ping Reference =
> 481750789   - Round Trip Time = 15.8593 ms
> 20150506T220836.990831 - Content From /ndn/edu/orange - Ping Reference =
> 481750790   - Round Trip Time = 8.84247 ms
> 20150506T220838.011070 - Content From /ndn/edu/orange - Ping Reference =
> 481750791   - Round Trip Time = 17.0122 ms
> 20150506T220839.022594 - Content From /ndn/edu/orange - Ping Reference =
> 481750792   - Round Trip Time = 40.5401 ms
> 20150506T220839.996497 - Content From /ndn/edu/orange - Ping Reference =
> 481750793   - Round Trip Time = 13.9247 ms
> 20150506T220841.000317 - Content From /ndn/edu/orange - Ping Reference =
> 481750794   - Round Trip Time = 18.0118 ms
> 20150506T220841.990391 - Content From /ndn/edu/orange - Ping Reference =
> 481750795   - Round Trip Time = 8.36782 ms
> 20150506T220842.989631 - Content From /ndn/edu/orange - Ping Reference =
> 481750796   - Round Trip Time = 7.57163 ms
> 20150506T220843.990083 - Content From /ndn/edu/orange - Ping Reference =
> 481750797   - Round Trip Time = 7.9309 ms
>
>  3.) NFD Management using KeyChain::signWithSha256() and
> ndn::nfd::Controller::start() using KeyChain::signWithSha256:
>
>  20150506T224746.920419 - Content From /ndn/edu/orange - Ping Reference =
> 432571709   - Round Trip Time = 7.74707 ms
> 20150506T224747.920684 - Content From /ndn/edu/orange - Ping Reference =
> 432571710   - Round Trip Time = 8.08427 ms
> 20150506T224748.921073 - Content From /ndn/edu/orange - Ping Reference =
> 432571711   - Round Trip Time = 7.95967 ms
> 20150506T224749.920619 - Content From /ndn/edu/orange - Ping Reference =
> 432571712   - Round Trip Time = 7.78507 ms
> 20150506T224750.923189 - Content From /ndn/edu/orange - Ping Reference =
> 432571713   - Round Trip Time = 10.5592 ms
> 20150506T224751.920660 - Content From /ndn/edu/orange - Ping Reference =
> 432571714   - Round Trip Time = 7.73255 ms
> 20150506T224752.920939 - Content From /ndn/edu/orange - Ping Reference =
> 432571715   - Round Trip Time = 8.24211 ms
> 20150506T224753.923819 - Content From /ndn/edu/orange - Ping Reference =
> 432571716   - Round Trip Time = 9.19251 ms
> 20150506T224754.921798 - Content From /ndn/edu/orange - Ping Reference =
> 432571717   - Round Trip Time = 8.94248 ms
> 20150506T224755.924729 - Content From /ndn/edu/orange - Ping Reference =
> 432571718   - Round Trip Time = 12.0222 ms
> 20150506T224756.920302 - Content From /ndn/edu/orange - Ping Reference =
> 432571719   - Round Trip Time = 7.75629 ms
>
>
> --
>  Vince Lehman
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150506/a7a30cd2/attachment.html>

From oran at cisco.com  Thu May  7 06:12:55 2015
From: oran at cisco.com (Dave Oran (oran))
Date: Thu, 7 May 2015 13:12:55 +0000
Subject: [Nfd-dev] PIB service causes remote registration of every prefix
In-Reply-To: <CAOFH+OavRZDyBy2ok8eGNSWv4BWmd+-WriKvCbaEkUYSNgTDmg@mail.gmail.com>
References: <CAOFH+OZr5fgrLn=E5_fOAwL6FO-rVtG7x=hi_ikdAeE=PbCFPw@mail.gmail.com>
	<CAOFH+OavRZDyBy2ok8eGNSWv4BWmd+-WriKvCbaEkUYSNgTDmg@mail.gmail.com>
Message-ID: <74C40FA4-C53D-46B6-8B2D-607241987594@cisco.com>


> On May 6, 2015, at 6:26 PM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:
> 
> Dear folks
> 
> 20150506 conference call discussed this problem.
> We conclude that it's acceptable to remote register prefixes for all certificates, because certificates should be made available on the networks so that others can verify previously generated Data that references those certificates.
> No design change is needed.
> 
Does this open up a cache poisoning attack?
Or a DoS attack against the routing to certificate stores?

> Yours, Junxiao
> 
> On Thu, Apr 30, 2015 at 12:19 PM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:
> 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, 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
> 
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev




From shijunxiao at email.ARIZONA.EDU  Thu May  7 07:02:22 2015
From: shijunxiao at email.ARIZONA.EDU (Junxiao Shi)
Date: Thu, 7 May 2015 07:02:22 -0700
Subject: [Nfd-dev] PIB service causes remote registration of every prefix
In-Reply-To: <74C40FA4-C53D-46B6-8B2D-607241987594@cisco.com>
References: <CAOFH+OZr5fgrLn=E5_fOAwL6FO-rVtG7x=hi_ikdAeE=PbCFPw@mail.gmail.com>
	<CAOFH+OavRZDyBy2ok8eGNSWv4BWmd+-WriKvCbaEkUYSNgTDmg@mail.gmail.com>
	<74C40FA4-C53D-46B6-8B2D-607241987594@cisco.com>
Message-ID: <CAOFH+OZU1P2fLi5xKsTR-Qn+NVW3M_JusqibLhnDn4Acg1GhqQ@mail.gmail.com>

Hi Dave

There's no risk of cache poisoning.
The gateway router registers a route to the laptop only if the laptop user
owns the prefix, as proved by a certificate.

There's no increased risk of DoS'ing the certificate store (PIB service).
The DoS risk is the same when a laptop registers at least one prefix onto
the gateway router.

Yours, Junxiao

On Thu, May 7, 2015 at 6:12 AM, Dave Oran (oran) <oran at cisco.com> wrote:

>
> > On May 6, 2015, at 6:26 PM, Junxiao Shi <shijunxiao at email.arizona.edu>
> wrote:
> > 20150506 conference call discussed this problem.
> > We conclude that it's acceptable to remote register prefixes for all
> certificates, because certificates should be made available on the networks
> so that others can verify previously generated Data that references those
> certificates.
> > No design change is needed.
> >
> Does this open up a cache poisoning attack?
> Or a DoS attack against the routing to certificate stores?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150507/241e3445/attachment.html>

From oran at cisco.com  Thu May  7 07:42:57 2015
From: oran at cisco.com (Dave Oran (oran))
Date: Thu, 7 May 2015 14:42:57 +0000
Subject: [Nfd-dev] PIB service causes remote registration of every prefix
In-Reply-To: <CAOFH+OZU1P2fLi5xKsTR-Qn+NVW3M_JusqibLhnDn4Acg1GhqQ@mail.gmail.com>
References: <CAOFH+OZr5fgrLn=E5_fOAwL6FO-rVtG7x=hi_ikdAeE=PbCFPw@mail.gmail.com>
	<CAOFH+OavRZDyBy2ok8eGNSWv4BWmd+-WriKvCbaEkUYSNgTDmg@mail.gmail.com>
	<74C40FA4-C53D-46B6-8B2D-607241987594@cisco.com>
	<CAOFH+OZU1P2fLi5xKsTR-Qn+NVW3M_JusqibLhnDn4Acg1GhqQ@mail.gmail.com>
Message-ID: <F0DF2DFC-C96D-461D-9915-DF1A4420F4FC@cisco.com>


> On May 7, 2015, at 10:02 AM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:
> 
> Hi Dave
> 
> There's no risk of cache poisoning.
> The gateway router registers a route to the laptop only if the laptop user owns the prefix, as proved by a certificate.
What you are saying is that the route registration is signed by a certificate specifically issued for that prefix to the user holding the corresponding private key, and this was done by a CA with authority over a shorter prefix, right?

What is the exact protocol machinery for registration? (sorry if this is obvious and written down somewhere and I haven?t seen it).

> 
> There's no increased risk of DoS'ing the certificate store (PIB service).
Agree
> The DoS risk is the same when a laptop registers at least one prefix onto the gateway router.
I?m not clear if there?s a hazard here. If the router checks that any prefix registered also has a path to the certificate registered and that the cert has been verified, I can see how this prevents DoS-by-fake-registrations. Is that in fact what?s done?

> 
> Yours, Junxiao
> 
> On Thu, May 7, 2015 at 6:12 AM, Dave Oran (oran) <oran at cisco.com> wrote:
> 
> > On May 6, 2015, at 6:26 PM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:
> > 20150506 conference call discussed this problem.
> > We conclude that it's acceptable to remote register prefixes for all certificates, because certificates should be made available on the networks so that others can verify previously generated Data that references those certificates.
> > No design change is needed.
> >
> Does this open up a cache poisoning attack?
> Or a DoS attack against the routing to certificate stores?
> 




From vslehman at memphis.edu  Mon May 11 09:21:27 2015
From: vslehman at memphis.edu (Vince Lehman (vslehman))
Date: Mon, 11 May 2015 16:21:27 +0000
Subject: [Nfd-dev] Jenkins OSX-10.9-64bit
Message-ID: <FB4FE56C-D226-4158-B80A-B57362F56D9F@memphis.edu>

Hi all,

It looks like there may be a compiler issue on the OSX-10.9-64bit-ucla-mavericks-10010 VM that shows up when building ndn-cxx.

Here is the log output:


Started by upstream project "NLSR<http://jenkins.named-data.net/job/NLSR/>" build number 538<http://jenkins.named-data.net/job/NLSR/538>
originally caused by:
 Retriggered by user vlehman1 at gmail.com<mailto:vlehman1 at gmail.com> for Gerrit: http://gerrit.named-data.net/2026
[EnvInject] - Loading node environment variables.
Building remotely on OSX-10.9-64bit-ucla-mavericks-10010<http://jenkins.named-data.net/computer/OSX-10.9-64bit-ucla-mavericks-10010> (Boost1.55 OSX-10.9-64bit OSX) in workspace /Users/jenkins/workspace/NLSR/label/OSX-10.9-64bit
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url ssh://jenkins at gerrit.named-data.net:29418/NLSR # timeout=10
Pruning obsolete local branches
Fetching upstream changes from ssh://jenkins at gerrit.named-data.net:29418/NLSR
 > git --version # timeout=10
using GIT_SSH to set credentials
 > git -c core.askpass=true fetch --tags --progress ssh://jenkins at gerrit.named-data.net:29418/NLSR refs/changes/26/2026/5 --prune
Checking out Revision 41b173ed54f9df81cf5d32778da66b07130b0e7c (master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 41b173ed54f9df81cf5d32778da66b07130b0e7c
 > git rev-parse FETCH_HEAD^{commit} # timeout=10
 > git rev-list 9630fbf4e03eaa91f7f7ed1e531b8bba1847fcba # timeout=10
Cleaning workspace
 > git rev-parse --verify HEAD # timeout=10
Resetting working tree
 > git reset --hard # timeout=10
 > git clean -fdx # timeout=10
run PrePostClean
running on OSX-10.9-64bit-ucla-mavericks-10010
clean on OSX-10.9-64bit-ucla-pistons-10003
[OSX-10.9-64bit] $ /bin/sh -xe /var/folders/dn/40ynwmgj3kvfpdtwhv5jlhc80000gn/T/hudson8268414739960411193.sh
+ ./.jenkins
Run: /Users/jenkins/workspace/NLSR/label/OSX-10.9-64bit/.jenkins.d/01-dependencies.sh
+ brew update
Already up-to-date.
+ brew upgrade
Warning: brew upgrade with no arguments will change behaviour soon!
It currently upgrades all formula but this will soon change to require '--all'.
Please update any workflows, documentation and scripts!
+ brew install boost pkg-config sqlite cryptopp log4cxx protobuf openssl
Warning: boost-1.58.0 already installed
Warning: pkg-config-0.28 already installed
Warning: sqlite-3.8.10.1 already installed
Warning: cryptopp-5.6.2 already installed
Warning: log4cxx-0.10.0 already installed
Warning: protobuf-2.6.1 already installed
Warning: openssl-1.0.2a-1 already installed
+ brew cleanup
+ has Ubuntu Boost1.55 OSX OSX-10.9-64bit OSX-10.9-64bit-ucla-mavericks-10010
+ local p=Ubuntu
+ shift
+ local x
+ for x in '"$@"'
+ [[ Boost1.55 == \U\b\u\n\t\u ]]
+ for x in '"$@"'
+ [[ OSX == \U\b\u\n\t\u ]]
+ for x in '"$@"'
+ [[ OSX-10.9-64bit == \U\b\u\n\t\u ]]
+ for x in '"$@"'
+ [[ OSX-10.9-64bit-ucla-mavericks-10010 == \U\b\u\n\t\u ]]
+ return 1
Run: /Users/jenkins/workspace/NLSR/label/OSX-10.9-64bit/.jenkins.d/10-ndn-cxx.sh
+ set -e
+ pushd /tmp
+ INSTALLED_VERSION=adadb7108dbec453b3d8b6c89fe8b9067e7651e4
+ sudo rm -Rf ndn-cxx-latest
+ git clone --depth 1 git://github.com/named-data/ndn-cxx ndn-cxx-latest
Cloning into 'ndn-cxx-latest'...
+ LATEST_VERSION=adadb7108dbec453b3d8b6c89fe8b9067e7651e4
+ [[ adadb7108dbec453b3d8b6c89fe8b9067e7651e4 != adadb7108dbec453b3d8b6c89fe8b9067e7651e4 ]]
+ sudo rm -Rf ndn-cxx-latest
+ sudo rm -Rf /usr/local/include/ndn-cxx
+ sudo rm -f '/usr/local/lib/libndn-cxx*'
+ sudo rm -f '/usr/local/lib/pkgconfig/libndn-cxx*'
+ pushd ndn-cxx
+ ./waf configure -j1 --color=yes --without-osx-keychain
Setting top to                           : /private/tmp/ndn-cxx
Setting out to                           : /private/tmp/ndn-cxx/build
Checking for 'clang++' (C++ compiler)    : /usr/bin/clang++
Checking supported CXXFLAGS              : -std=c++11 -Wno-error=unneeded-internal-declaration -Wno-error=deprecated-register -stdlib=libc++
Checking supported LINKFLAGS             : -stdlib=libc++
Checking supported CXXFLAGS              : -pedantic -Wall -O2 -g
Checking for program 'doxygen'           : /usr/local/bin/doxygen
Checking for program 'tar'               : /usr/bin/tar
Checking for program 'sphinx-build'      : /usr/local/bin/sphinx-build
Checking for std::is_default_constructible : yes
Checking for std::is_move_constructible    : yes
Checking for std::is_move_assignable       : yes
Checking for friend typename-specifier     : yes
Checking for override and final specifiers : yes
Checking for program 'sh'                  : /bin/sh
Checking for library pthread               : yes
Checking for library rt                    : not found
Checking for compiler flags ['-fPIC']      : yes
Checking for function getpass              : yes
Checking for rtnetlink                     : not found
Checking for framework CoreFoundation      : yes
Checking for framework CoreServices        : yes
Checking for framework Security            : yes
Checking for program 'pkg-config'          : /usr/local/bin/pkg-config
Checking for 'sqlite3'                     : yes
Checking Crypto++ lib                      : 562
Checking if CryptoPP library works         : yes
Checking boost includes                    : 1.58.0
Checking boost libs                        : ok
Checking for boost linkage                 : ok
'configure' finished successfully (16.395s)
+ ./waf -j1 --color=yes
Waf: Entering directory `/private/tmp/ndn-cxx/build'
[  2/119] Compiling src/common-pch.hpp
[ 29/119] Compiling tools/ndnsec/main.cpp
Stack dump:
0.      Program arguments: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -cc1 -triple x86_64-apple-macosx10.9.0 -emit-obj -disable-free -disable-llvm-verifier -main-file-name main.cpp -mrelocation-model pic -pic-level 2 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 241.9 -gdwarf-2 -coverage-file /private/tmp/ndn-cxx/build/tools/ndnsec/main.cpp.4.o -resource-dir /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.0 -include-pch /private/tmp/ndn-cxx/build/ndn-cxx.2.pch -D NDEBUG -I /private/tmp/ndn-cxx/build/tools/ndnsec -I /private/tmp/ndn-cxx/tools/ndnsec -I /private/tmp/ndn-cxx/build/src -I /private/tmp/ndn-cxx/src -I /usr/local/include -stdlib=libc++ -O2 -Wall -Wno-error=unneeded-internal-declaration -Wno-error=deprecated-register -pedantic -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /private/tmp/ndn-cxx/build -ferror-limit 19 -fmessage-length 0 -stack-protector 1 -mstackrealign -fblocks -fobjc-runtime=macosx-10.9.0 -fencode-extended-block-signature -fcxx-exceptions -fexceptions -fdiagnostics-show-option -vectorize-loops -vectorize-slp -o /private/tmp/ndn-cxx/build/tools/ndnsec/main.cpp.4.o -x c++ ../tools/ndnsec/main.cpp
1.      <eof> parser at end of file
2.      /usr/local/include/boost/date_time/date_parsing.hpp:104:5: instantiating function definition 'parse_date'
3.      /usr/local/include/boost/lexical_cast.hpp:37:19: instantiating function definition 'lexical_cast'
4.      /usr/local/include/boost/lexical_cast/try_lexical_convert.hpp:139:21: instantiating function definition 'try_lexical_convert'
5.      /usr/local/include/boost/lexical_cast/detail/converter_lexical.hpp:472:32: instantiating function definition 'try_convert'
clang: error: unable to execute command: Segmentation fault: 11
clang: error: clang frontend command failed due to signal (use -v to see invocation)
Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.3.0
Thread model: posix
clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script.
clang: note: diagnostic msg:
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /var/folders/dn/40ynwmgj3kvfpdtwhv5jlhc80000gn/T/main-23e6db.cpp
clang: note: diagnostic msg: /var/folders/dn/40ynwmgj3kvfpdtwhv5jlhc80000gn/T/main-23e6db.sh
clang: note: diagnostic msg:

********************

Waf: Leaving directory `/private/tmp/ndn-cxx/build'
Build failed
 -> task in '../bin/ndnsec' failed (exit status 254):
        {task 4375932560: cxx main.cpp -> main.cpp.4.o}
['/usr/bin/clang++', '-pedantic', '-Wall', '-O2', '-g', '-std=c++11', '-Wno-error=unneeded-internal-declaration', '-Wno-error=deprecated-register', '-stdlib=libc++', '-fPIC', '-include', '/private/tmp/ndn-cxx/build/ndn-cxx.2', '-I/private/tmp/ndn-cxx/build/tools/ndnsec', '-I/private/tmp/ndn-cxx/tools/ndnsec', '-I/private/tmp/ndn-cxx/build/src', '-I/private/tmp/ndn-cxx/src', '-I/usr/local/include', '-DNDEBUG', '../tools/ndnsec/main.cpp', '-c', '-o', '/private/tmp/ndn-cxx/build/tools/ndnsec/main.cpp.4.o']
Build step 'Execute shell' marked build as failure
Skipping Cobertura coverage report as build was not UNSTABLE or better ...
Finished: FAILURE




--
Vince Lehman

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

From alexander.afanasyev at UCLA.EDU  Mon May 11 10:58:57 2015
From: alexander.afanasyev at UCLA.EDU (Alex Afanasyev)
Date: Mon, 11 May 2015 10:58:57 -0700
Subject: [Nfd-dev] Jenkins OSX-10.9-64bit
In-Reply-To: <FB4FE56C-D226-4158-B80A-B57362F56D9F@memphis.edu>
References: <FB4FE56C-D226-4158-B80A-B57362F56D9F@memphis.edu>
Message-ID: <FF42D5C2-6A74-445C-96CF-7CCED4D0C45F@ucla.edu>

Hi Vince,

Other osx VMs seem to have a similar problem, I will try to investigate what?s wrong.  The thing that changed recently is that boost updated to version 1.58.

?
Alex

> On May 11, 2015, at 9:21 AM, Vince Lehman (vslehman) <vslehman at memphis.edu> wrote:
> 
> Hi all,
> 
> It looks like there may be a compiler issue on the OSX-10.9-64bit-ucla-mavericks-10010 VM that shows up when building ndn-cxx.
> 
> Here is the log output:
> 
> Started by upstream project "NLSR <http://jenkins.named-data.net/job/NLSR/>" build number 538 <http://jenkins.named-data.net/job/NLSR/538>
> originally caused by:
>  Retriggered by user vlehman1 at gmail.com <mailto:vlehman1 at gmail.com> for Gerrit: http://gerrit.named-data.net/2026 <http://gerrit.named-data.net/2026>
> [EnvInject] - Loading node environment variables.
> Building remotely on OSX-10.9-64bit-ucla-mavericks-10010 <http://jenkins.named-data.net/computer/OSX-10.9-64bit-ucla-mavericks-10010> (Boost1.55 OSX-10.9-64bit OSX) in workspace /Users/jenkins/workspace/NLSR/label/OSX-10.9-64bit
>  > git rev-parse --is-inside-work-tree # timeout=10
> Fetching changes from the remote Git repository
>  > git config remote.origin.url ssh://jenkins at gerrit.named-data.net:29418/NLSR <ssh://jenkins at gerrit.named-data.net:29418/NLSR> # timeout=10
> Pruning obsolete local branches
> Fetching upstream changes from ssh://jenkins at gerrit.named-data.net:29418/NLSR <ssh://jenkins at gerrit.named-data.net:29418/NLSR>
>  > git --version # timeout=10
> using GIT_SSH to set credentials
>  > git -c core.askpass=true fetch --tags --progress ssh://jenkins at gerrit.named-data.net:29418/NLSR <ssh://jenkins at gerrit.named-data.net:29418/NLSR> refs/changes/26/2026/5 --prune
> Checking out Revision 41b173ed54f9df81cf5d32778da66b07130b0e7c (master)
>  > git config core.sparsecheckout # timeout=10
>  > git checkout -f 41b173ed54f9df81cf5d32778da66b07130b0e7c
>  > git rev-parse FETCH_HEAD^{commit} # timeout=10
>  > git rev-list 9630fbf4e03eaa91f7f7ed1e531b8bba1847fcba # timeout=10
> Cleaning workspace
>  > git rev-parse --verify HEAD # timeout=10
> Resetting working tree
>  > git reset --hard # timeout=10
>  > git clean -fdx # timeout=10
> run PrePostClean
> running on OSX-10.9-64bit-ucla-mavericks-10010
> clean on OSX-10.9-64bit-ucla-pistons-10003
> [OSX-10.9-64bit] $ /bin/sh -xe /var/folders/dn/40ynwmgj3kvfpdtwhv5jlhc80000gn/T/hudson8268414739960411193.sh
> + ./.jenkins
> Run: /Users/jenkins/workspace/NLSR/label/OSX-10.9-64bit/.jenkins.d/01-dependencies.sh
> + brew update
> Already up-to-date.
> + brew upgrade
> Warning: brew upgrade with no arguments will change behaviour soon!
> It currently upgrades all formula but this will soon change to require '--all'.
> Please update any workflows, documentation and scripts!
> + brew install boost pkg-config sqlite cryptopp log4cxx protobuf openssl
> Warning: boost-1.58.0 already installed
> Warning: pkg-config-0.28 already installed
> Warning: sqlite-3.8.10.1 already installed
> Warning: cryptopp-5.6.2 already installed
> Warning: log4cxx-0.10.0 already installed
> Warning: protobuf-2.6.1 already installed
> Warning: openssl-1.0.2a-1 already installed
> + brew cleanup
> + has Ubuntu Boost1.55 OSX OSX-10.9-64bit OSX-10.9-64bit-ucla-mavericks-10010
> + local p=Ubuntu
> + shift
> + local x
> + for x in '"$@"'
> + [[ Boost1.55 == \U\b\u\n\t\u ]]
> + for x in '"$@"'
> + [[ OSX == \U\b\u\n\t\u ]]
> + for x in '"$@"'
> + [[ OSX-10.9-64bit == \U\b\u\n\t\u ]]
> + for x in '"$@"'
> + [[ OSX-10.9-64bit-ucla-mavericks-10010 == \U\b\u\n\t\u ]]
> + return 1
> Run: /Users/jenkins/workspace/NLSR/label/OSX-10.9-64bit/.jenkins.d/10-ndn-cxx.sh
> + set -e
> + pushd /tmp
> + INSTALLED_VERSION=adadb7108dbec453b3d8b6c89fe8b9067e7651e4
> + sudo rm -Rf ndn-cxx-latest
> + git clone --depth 1 git://github.com/named-data/ndn-cxx <git://github.com/named-data/ndn-cxx> ndn-cxx-latest
> Cloning into 'ndn-cxx-latest'...
> + LATEST_VERSION=adadb7108dbec453b3d8b6c89fe8b9067e7651e4
> + [[ adadb7108dbec453b3d8b6c89fe8b9067e7651e4 != adadb7108dbec453b3d8b6c89fe8b9067e7651e4 ]]
> + sudo rm -Rf ndn-cxx-latest
> + sudo rm -Rf /usr/local/include/ndn-cxx
> + sudo rm -f '/usr/local/lib/libndn-cxx*'
> + sudo rm -f '/usr/local/lib/pkgconfig/libndn-cxx*'
> + pushd ndn-cxx
> + ./waf configure -j1 --color=yes --without-osx-keychain
> Setting top to                           : /private/tmp/ndn-cxx
> Setting out to                           : /private/tmp/ndn-cxx/build
> Checking for 'clang++' (C++ compiler)    : /usr/bin/clang++
> Checking supported CXXFLAGS              : -std=c++11 -Wno-error=unneeded-internal-declaration -Wno-error=deprecated-register -stdlib=libc++
> Checking supported LINKFLAGS             : -stdlib=libc++
> Checking supported CXXFLAGS              : -pedantic -Wall -O2 -g
> Checking for program 'doxygen'           : /usr/local/bin/doxygen
> Checking for program 'tar'               : /usr/bin/tar
> Checking for program 'sphinx-build'      : /usr/local/bin/sphinx-build
> Checking for std::is_default_constructible : yes
> Checking for std::is_move_constructible    : yes
> Checking for std::is_move_assignable       : yes
> Checking for friend typename-specifier     : yes
> Checking for override and final specifiers : yes
> Checking for program 'sh'                  : /bin/sh
> Checking for library pthread               : yes
> Checking for library rt                    : not found
> Checking for compiler flags ['-fPIC']      : yes
> Checking for function getpass              : yes
> Checking for rtnetlink                     : not found
> Checking for framework CoreFoundation      : yes
> Checking for framework CoreServices        : yes
> Checking for framework Security            : yes
> Checking for program 'pkg-config'          : /usr/local/bin/pkg-config
> Checking for 'sqlite3'                     : yes
> Checking Crypto++ lib                      : 562
> Checking if CryptoPP library works         : yes
> Checking boost includes                    : 1.58.0
> Checking boost libs                        : ok
> Checking for boost linkage                 : ok
> 'configure' finished successfully (16.395s)
> + ./waf -j1 --color=yes
> Waf: Entering directory `/private/tmp/ndn-cxx/build'
> [  2/119] Compiling src/common-pch.hpp
> [ 29/119] Compiling tools/ndnsec/main.cpp
> Stack dump:
> 0.	Program arguments: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -cc1 -triple x86_64-apple-macosx10.9.0 -emit-obj -disable-free -disable-llvm-verifier -main-file-name main.cpp -mrelocation-model pic -pic-level 2 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 241.9 -gdwarf-2 -coverage-file /private/tmp/ndn-cxx/build/tools/ndnsec/main.cpp.4.o -resource-dir /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.0 -include-pch /private/tmp/ndn-cxx/build/ndn-cxx.2.pch -D NDEBUG -I /private/tmp/ndn-cxx/build/tools/ndnsec -I /private/tmp/ndn-cxx/tools/ndnsec -I /private/tmp/ndn-cxx/build/src -I /private/tmp/ndn-cxx/src -I /usr/local/include -stdlib=libc++ -O2 -Wall -Wno-error=unneeded-internal-declaration -Wno-error=deprecated-register -pedantic -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /private/tmp/ndn-cxx/build -ferror-limit 19 -fmessage-length 0 -stack-protector 1 -mstackrealign -fblocks -fobjc-runtime=macosx-10.9.0 -fencode-extended-block-signature -fcxx-exceptions -fexceptions -fdiagnostics-show-option -vectorize-loops -vectorize-slp -o /private/tmp/ndn-cxx/build/tools/ndnsec/main.cpp.4.o -x c++ ../tools/ndnsec/main.cpp
> 1.	<eof> parser at end of file
> 2.	/usr/local/include/boost/date_time/date_parsing.hpp:104:5: instantiating function definition 'parse_date'
> 3.	/usr/local/include/boost/lexical_cast.hpp:37:19: instantiating function definition 'lexical_cast'
> 4.	/usr/local/include/boost/lexical_cast/try_lexical_convert.hpp:139:21: instantiating function definition 'try_lexical_convert'
> 5.	/usr/local/include/boost/lexical_cast/detail/converter_lexical.hpp:472:32: instantiating function definition 'try_convert'
> clang: error: unable to execute command: Segmentation fault: 11
> clang: error: clang frontend command failed due to signal (use -v to see invocation)
> Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)
> Target: x86_64-apple-darwin13.3.0
> Thread model: posix
> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ <http://developer.apple.com/bugreporter/> and include the crash backtrace, preprocessed source, and associated run script.
> clang: note: diagnostic msg:
> ********************
> 
> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
> Preprocessed source(s) and associated run script(s) are located at:
> clang: note: diagnostic msg: /var/folders/dn/40ynwmgj3kvfpdtwhv5jlhc80000gn/T/main-23e6db.cpp
> clang: note: diagnostic msg: /var/folders/dn/40ynwmgj3kvfpdtwhv5jlhc80000gn/T/main-23e6db.sh
> clang: note: diagnostic msg:
> 
> ********************
> 
> Waf: Leaving directory `/private/tmp/ndn-cxx/build'
> Build failed
>  -> task in '../bin/ndnsec' failed (exit status 254):
> 	{task 4375932560: cxx main.cpp -> main.cpp.4.o}
> ['/usr/bin/clang++', '-pedantic', '-Wall', '-O2', '-g', '-std=c++11', '-Wno-error=unneeded-internal-declaration', '-Wno-error=deprecated-register', '-stdlib=libc++', '-fPIC', '-include', '/private/tmp/ndn-cxx/build/ndn-cxx.2', '-I/private/tmp/ndn-cxx/build/tools/ndnsec', '-I/private/tmp/ndn-cxx/tools/ndnsec', '-I/private/tmp/ndn-cxx/build/src', '-I/private/tmp/ndn-cxx/src', '-I/usr/local/include', '-DNDEBUG', '../tools/ndnsec/main.cpp', '-c', '-o', '/private/tmp/ndn-cxx/build/tools/ndnsec/main.cpp.4.o']
> Build step 'Execute shell' marked build as failure
> Skipping Cobertura coverage report as build was not UNSTABLE or better ...
> Finished: FAILURE
> 
> 
> 
> 
> --
> Vince Lehman
> 
> _______________________________________________
> 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/20150511/97f93e44/attachment.html>
-------------- 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/20150511/97f93e44/attachment.bin>

From anilj.mailing at gmail.com  Mon May 11 11:20:37 2015
From: anilj.mailing at gmail.com (Anil Jangam)
Date: Mon, 11 May 2015 11:20:37 -0700
Subject: [Nfd-dev] Querying pending Interest in PIT.
Message-ID: <CAHVD1iaSrO6zg=O9wGYYnX9GNSW09VdOzo3MEZcr9dSdpyUrJA@mail.gmail.com>

Hi,

I have a requirement where I need to check the state of PIT and find out or
manage specific set of pending interests given the name.

I checked the management control interface of NFD, which mainly talks about
Face, Fib and Strategy. I did not find anything specific to PIT.

Are there APIs available or do we have to develop a manager for PIT as
well? Is that feasible?

Regards,
/anil.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150511/e11e0bfb/attachment.html>

From shijunxiao at email.arizona.edu  Mon May 11 13:25:03 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Mon, 11 May 2015 13:25:03 -0700
Subject: [Nfd-dev] PIB service causes remote registration of every prefix
In-Reply-To: <F0DF2DFC-C96D-461D-9915-DF1A4420F4FC@cisco.com>
References: <CAOFH+OZr5fgrLn=E5_fOAwL6FO-rVtG7x=hi_ikdAeE=PbCFPw@mail.gmail.com>
	<CAOFH+OavRZDyBy2ok8eGNSWv4BWmd+-WriKvCbaEkUYSNgTDmg@mail.gmail.com>
	<74C40FA4-C53D-46B6-8B2D-607241987594@cisco.com>
	<CAOFH+OZU1P2fLi5xKsTR-Qn+NVW3M_JusqibLhnDn4Acg1GhqQ@mail.gmail.com>
	<F0DF2DFC-C96D-461D-9915-DF1A4420F4FC@cisco.com>
Message-ID: <CAOFH+OZZC+u_pztrYRjKXoaX2ifq1kiDJ=0LuPZJzcvieFOwDw@mail.gmail.com>

Hi Dave

Yes, the laptop's certificate is issued by a CA who has authority over a
shorter prefix.
For example, CA=/ndn/edu/arizona, laptop has /ndn/edu/arizona/cs/shijunxiao
certificate issued by /ndn/edu/arizona. This laptop would be allowed to
register /ndn/edu/arizona/cs/shijunxiao, or a prefix under this namespace.

Remote prefix registration uses the same RIB Management protocol <
http://redmine.named-data.net/projects/nfd/wiki/RibMgmt>.


The laptop's top level certificate is published by the CA, and is already
accessible from the router before the registration.
The router will verify the trust chain before accepting the registration.

Yours, Junxiao

On Thu, May 7, 2015 at 7:42 AM, Dave Oran (oran) <oran at cisco.com> wrote:

>
> > On May 7, 2015, at 10:02 AM, Junxiao Shi <shijunxiao at email.arizona.edu>
> wrote:
> >
> > Hi Dave
> >
> > There's no risk of cache poisoning.
> > The gateway router registers a route to the laptop only if the laptop
> user owns the prefix, as proved by a certificate.
> What you are saying is that the route registration is signed by a
> certificate specifically issued for that prefix to the user holding the
> corresponding private key, and this was done by a CA with authority over a
> shorter prefix, right?
>
> What is the exact protocol machinery for registration? (sorry if this is
> obvious and written down somewhere and I haven?t seen it).
>
> >
> > There's no increased risk of DoS'ing the certificate store (PIB service).
> Agree
> > The DoS risk is the same when a laptop registers at least one prefix
> onto the gateway router.
> I?m not clear if there?s a hazard here. If the router checks that any
> prefix registered also has a path to the certificate registered and that
> the cert has been verified, I can see how this prevents
> DoS-by-fake-registrations. Is that in fact what?s done?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150511/e36b6093/attachment.html>

From alexander.afanasyev at UCLA.EDU  Mon May 11 15:41:03 2015
From: alexander.afanasyev at UCLA.EDU (Alex Afanasyev)
Date: Mon, 11 May 2015 15:41:03 -0700
Subject: [Nfd-dev] Soon to be released: new revision of NFD developer's guide
Message-ID: <E1377DCD-A57E-410F-B48B-A4064432C3F1@ucla.edu>

Hi guys,

We are planning to do release of the slightly updated revision of the NFD?s developer?s guide alongside the new versions of NFD and ndn-cxx.

Can you please take a look and, if you have cycles, fix bugs and add/clarify description (git at git.irl.cs.ucla.edu:papers/nfd-docs.git repo).

?
Alex

-------------- 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/20150511/5ea1791a/attachment.bin>

From alexander.afanasyev at UCLA.EDU  Mon May 11 15:47:01 2015
From: alexander.afanasyev at UCLA.EDU (Alex Afanasyev)
Date: Mon, 11 May 2015 15:47:01 -0700
Subject: [Nfd-dev] Querying pending Interest in PIT.
In-Reply-To: <CAHVD1iaSrO6zg=O9wGYYnX9GNSW09VdOzo3MEZcr9dSdpyUrJA@mail.gmail.com>
References: <CAHVD1iaSrO6zg=O9wGYYnX9GNSW09VdOzo3MEZcr9dSdpyUrJA@mail.gmail.com>
Message-ID: <A7AD778C-3412-41CA-9C20-57616434ACD0@ucla.edu>

Hi Anil,

Currently, NFD management protocol only has an API to retrieve total number of PIT entries (the number you can see with nfd-status -s).  To get what you need, you may need to implement additional manager, e.g., similar to FaceQueryStatusPublisher (daemon/mgmt/face-query-status-publisher.hpp|cpp).

?
Alex

> On May 11, 2015, at 11:20 AM, Anil Jangam <anilj.mailing at gmail.com> wrote:
> 
> Hi,
> 
> I have a requirement where I need to check the state of PIT and find out or manage specific set of pending interests given the name.
> 
> I checked the management control interface of NFD, which mainly talks about Face, Fib and Strategy. I did not find anything specific to PIT.
> 
> Are there APIs available or do we have to develop a manager for PIT as well? Is that feasible?
> 
> Regards,
> /anil.

-------------- 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/20150511/f10ead9d/attachment.bin>

From alexander.afanasyev at UCLA.EDU  Mon May 11 16:05:05 2015
From: alexander.afanasyev at UCLA.EDU (Alex Afanasyev)
Date: Mon, 11 May 2015 16:05:05 -0700
Subject: [Nfd-dev] Jenkins OSX-10.9-64bit
In-Reply-To: <FF42D5C2-6A74-445C-96CF-7CCED4D0C45F@ucla.edu>
References: <FB4FE56C-D226-4158-B80A-B57362F56D9F@memphis.edu>
	<FF42D5C2-6A74-445C-96CF-7CCED4D0C45F@ucla.edu>
Message-ID: <09B89271-4E2B-43AA-B59D-30258CB92514@ucla.edu>

Hi Vince and all,

I fixed the issue by upgrading compiler on OSX 10.10, but the same new version is not (yet) available for 10.9.  I made a workaround (http://gerrit.named-data.net/#/c/2030/ <http://gerrit.named-data.net/#/c/2030/>) that should address the issue for old OSX platforms.  After the code is merged, NLSR build should succeed.

?
Alex

> On May 11, 2015, at 10:58 AM, Alex Afanasyev <alexander.afanasyev at ucla.edu> wrote:
> 
> Hi Vince,
> 
> Other osx VMs seem to have a similar problem, I will try to investigate what?s wrong.  The thing that changed recently is that boost updated to version 1.58.
> 
> ?
> Alex
> 
>> On May 11, 2015, at 9:21 AM, Vince Lehman (vslehman) <vslehman at memphis.edu <mailto:vslehman at memphis.edu>> wrote:
>> 
>> Hi all,
>> 
>> It looks like there may be a compiler issue on the OSX-10.9-64bit-ucla-mavericks-10010 VM that shows up when building ndn-cxx.
>> 
>> Here is the log output:
>> 
>> Started by upstream project "NLSR <http://jenkins.named-data.net/job/NLSR/>" build number 538 <http://jenkins.named-data.net/job/NLSR/538>
>> originally caused by:
>>  Retriggered by user vlehman1 at gmail.com <mailto:vlehman1 at gmail.com> for Gerrit: http://gerrit.named-data.net/2026 <http://gerrit.named-data.net/2026>
>> [EnvInject] - Loading node environment variables.
>> Building remotely on OSX-10.9-64bit-ucla-mavericks-10010 <http://jenkins.named-data.net/computer/OSX-10.9-64bit-ucla-mavericks-10010> (Boost1.55 OSX-10.9-64bit OSX) in workspace /Users/jenkins/workspace/NLSR/label/OSX-10.9-64bit
>>  > git rev-parse --is-inside-work-tree # timeout=10
>> Fetching changes from the remote Git repository
>>  > git config remote.origin.url ssh://jenkins at gerrit.named-data.net:29418/NLSR <ssh://jenkins at gerrit.named-data.net:29418/NLSR> # timeout=10
>> Pruning obsolete local branches
>> Fetching upstream changes from ssh://jenkins at gerrit.named-data.net:29418/NLSR <ssh://jenkins at gerrit.named-data.net:29418/NLSR>
>>  > git --version # timeout=10
>> using GIT_SSH to set credentials
>>  > git -c core.askpass=true fetch --tags --progress ssh://jenkins at gerrit.named-data.net:29418/NLSR <ssh://jenkins at gerrit.named-data.net:29418/NLSR> refs/changes/26/2026/5 --prune
>> Checking out Revision 41b173ed54f9df81cf5d32778da66b07130b0e7c (master)
>>  > git config core.sparsecheckout # timeout=10
>>  > git checkout -f 41b173ed54f9df81cf5d32778da66b07130b0e7c
>>  > git rev-parse FETCH_HEAD^{commit} # timeout=10
>>  > git rev-list 9630fbf4e03eaa91f7f7ed1e531b8bba1847fcba # timeout=10
>> Cleaning workspace
>>  > git rev-parse --verify HEAD # timeout=10
>> Resetting working tree
>>  > git reset --hard # timeout=10
>>  > git clean -fdx # timeout=10
>> run PrePostClean
>> running on OSX-10.9-64bit-ucla-mavericks-10010
>> clean on OSX-10.9-64bit-ucla-pistons-10003
>> [OSX-10.9-64bit] $ /bin/sh -xe /var/folders/dn/40ynwmgj3kvfpdtwhv5jlhc80000gn/T/hudson8268414739960411193.sh
>> + ./.jenkins
>> Run: /Users/jenkins/workspace/NLSR/label/OSX-10.9-64bit/.jenkins.d/01-dependencies.sh
>> + brew update
>> Already up-to-date.
>> + brew upgrade
>> Warning: brew upgrade with no arguments will change behaviour soon!
>> It currently upgrades all formula but this will soon change to require '--all'.
>> Please update any workflows, documentation and scripts!
>> + brew install boost pkg-config sqlite cryptopp log4cxx protobuf openssl
>> Warning: boost-1.58.0 already installed
>> Warning: pkg-config-0.28 already installed
>> Warning: sqlite-3.8.10.1 already installed
>> Warning: cryptopp-5.6.2 already installed
>> Warning: log4cxx-0.10.0 already installed
>> Warning: protobuf-2.6.1 already installed
>> Warning: openssl-1.0.2a-1 already installed
>> + brew cleanup
>> + has Ubuntu Boost1.55 OSX OSX-10.9-64bit OSX-10.9-64bit-ucla-mavericks-10010
>> + local p=Ubuntu
>> + shift
>> + local x
>> + for x in '"$@"'
>> + [[ Boost1.55 == \U\b\u\n\t\u ]]
>> + for x in '"$@"'
>> + [[ OSX == \U\b\u\n\t\u ]]
>> + for x in '"$@"'
>> + [[ OSX-10.9-64bit == \U\b\u\n\t\u ]]
>> + for x in '"$@"'
>> + [[ OSX-10.9-64bit-ucla-mavericks-10010 == \U\b\u\n\t\u ]]
>> + return 1
>> Run: /Users/jenkins/workspace/NLSR/label/OSX-10.9-64bit/.jenkins.d/10-ndn-cxx.sh
>> + set -e
>> + pushd /tmp
>> + INSTALLED_VERSION=adadb7108dbec453b3d8b6c89fe8b9067e7651e4
>> + sudo rm -Rf ndn-cxx-latest
>> + git clone --depth 1 git://github.com/named-data/ndn-cxx <git://github.com/named-data/ndn-cxx> ndn-cxx-latest
>> Cloning into 'ndn-cxx-latest'...
>> + LATEST_VERSION=adadb7108dbec453b3d8b6c89fe8b9067e7651e4
>> + [[ adadb7108dbec453b3d8b6c89fe8b9067e7651e4 != adadb7108dbec453b3d8b6c89fe8b9067e7651e4 ]]
>> + sudo rm -Rf ndn-cxx-latest
>> + sudo rm -Rf /usr/local/include/ndn-cxx
>> + sudo rm -f '/usr/local/lib/libndn-cxx*'
>> + sudo rm -f '/usr/local/lib/pkgconfig/libndn-cxx*'
>> + pushd ndn-cxx
>> + ./waf configure -j1 --color=yes --without-osx-keychain
>> Setting top to                           : /private/tmp/ndn-cxx
>> Setting out to                           : /private/tmp/ndn-cxx/build
>> Checking for 'clang++' (C++ compiler)    : /usr/bin/clang++
>> Checking supported CXXFLAGS              : -std=c++11 -Wno-error=unneeded-internal-declaration -Wno-error=deprecated-register -stdlib=libc++
>> Checking supported LINKFLAGS             : -stdlib=libc++
>> Checking supported CXXFLAGS              : -pedantic -Wall -O2 -g
>> Checking for program 'doxygen'           : /usr/local/bin/doxygen
>> Checking for program 'tar'               : /usr/bin/tar
>> Checking for program 'sphinx-build'      : /usr/local/bin/sphinx-build
>> Checking for std::is_default_constructible : yes
>> Checking for std::is_move_constructible    : yes
>> Checking for std::is_move_assignable       : yes
>> Checking for friend typename-specifier     : yes
>> Checking for override and final specifiers : yes
>> Checking for program 'sh'                  : /bin/sh
>> Checking for library pthread               : yes
>> Checking for library rt                    : not found
>> Checking for compiler flags ['-fPIC']      : yes
>> Checking for function getpass              : yes
>> Checking for rtnetlink                     : not found
>> Checking for framework CoreFoundation      : yes
>> Checking for framework CoreServices        : yes
>> Checking for framework Security            : yes
>> Checking for program 'pkg-config'          : /usr/local/bin/pkg-config
>> Checking for 'sqlite3'                     : yes
>> Checking Crypto++ lib                      : 562
>> Checking if CryptoPP library works         : yes
>> Checking boost includes                    : 1.58.0
>> Checking boost libs                        : ok
>> Checking for boost linkage                 : ok
>> 'configure' finished successfully (16.395s)
>> + ./waf -j1 --color=yes
>> Waf: Entering directory `/private/tmp/ndn-cxx/build'
>> [  2/119] Compiling src/common-pch.hpp
>> [ 29/119] Compiling tools/ndnsec/main.cpp
>> Stack dump:
>> 0.	Program arguments: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -cc1 -triple x86_64-apple-macosx10.9.0 -emit-obj -disable-free -disable-llvm-verifier -main-file-name main.cpp -mrelocation-model pic -pic-level 2 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 241.9 -gdwarf-2 -coverage-file /private/tmp/ndn-cxx/build/tools/ndnsec/main.cpp.4.o -resource-dir /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.0 -include-pch /private/tmp/ndn-cxx/build/ndn-cxx.2.pch -D NDEBUG -I /private/tmp/ndn-cxx/build/tools/ndnsec -I /private/tmp/ndn-cxx/tools/ndnsec -I /private/tmp/ndn-cxx/build/src -I /private/tmp/ndn-cxx/src -I /usr/local/include -stdlib=libc++ -O2 -Wall -Wno-error=unneeded-internal-declaration -Wno-error=deprecated-register -pedantic -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /private/tmp/ndn-cxx/build -ferror-limit 19 -fmessage-length 0 -stack-protector 1 -mstackrealign -fblocks -fobjc-runtime=macosx-10.9.0 -fencode-extended-block-signature -fcxx-exceptions -fexceptions -fdiagnostics-show-option -vectorize-loops -vectorize-slp -o /private/tmp/ndn-cxx/build/tools/ndnsec/main.cpp.4.o -x c++ ../tools/ndnsec/main.cpp
>> 1.	<eof> parser at end of file
>> 2.	/usr/local/include/boost/date_time/date_parsing.hpp:104:5: instantiating function definition 'parse_date'
>> 3.	/usr/local/include/boost/lexical_cast.hpp:37:19: instantiating function definition 'lexical_cast'
>> 4.	/usr/local/include/boost/lexical_cast/try_lexical_convert.hpp:139:21: instantiating function definition 'try_lexical_convert'
>> 5.	/usr/local/include/boost/lexical_cast/detail/converter_lexical.hpp:472:32: instantiating function definition 'try_convert'
>> clang: error: unable to execute command: Segmentation fault: 11
>> clang: error: clang frontend command failed due to signal (use -v to see invocation)
>> Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)
>> Target: x86_64-apple-darwin13.3.0
>> Thread model: posix
>> clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ <http://developer.apple.com/bugreporter/> and include the crash backtrace, preprocessed source, and associated run script.
>> clang: note: diagnostic msg:
>> ********************
>> 
>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
>> Preprocessed source(s) and associated run script(s) are located at:
>> clang: note: diagnostic msg: /var/folders/dn/40ynwmgj3kvfpdtwhv5jlhc80000gn/T/main-23e6db.cpp
>> clang: note: diagnostic msg: /var/folders/dn/40ynwmgj3kvfpdtwhv5jlhc80000gn/T/main-23e6db.sh
>> clang: note: diagnostic msg:
>> 
>> ********************
>> 
>> Waf: Leaving directory `/private/tmp/ndn-cxx/build'
>> Build failed
>>  -> task in '../bin/ndnsec' failed (exit status 254):
>> 	{task 4375932560: cxx main.cpp -> main.cpp.4.o}
>> ['/usr/bin/clang++', '-pedantic', '-Wall', '-O2', '-g', '-std=c++11', '-Wno-error=unneeded-internal-declaration', '-Wno-error=deprecated-register', '-stdlib=libc++', '-fPIC', '-include', '/private/tmp/ndn-cxx/build/ndn-cxx.2', '-I/private/tmp/ndn-cxx/build/tools/ndnsec', '-I/private/tmp/ndn-cxx/tools/ndnsec', '-I/private/tmp/ndn-cxx/build/src', '-I/private/tmp/ndn-cxx/src', '-I/usr/local/include', '-DNDEBUG', '../tools/ndnsec/main.cpp', '-c', '-o', '/private/tmp/ndn-cxx/build/tools/ndnsec/main.cpp.4.o']
>> Build step 'Execute shell' marked build as failure
>> Skipping Cobertura coverage report as build was not UNSTABLE or better ...
>> Finished: FAILURE
>> 
>> 
>> 
>> 
>> --
>> Vince Lehman
>> 
>> _______________________________________________
>> 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/20150511/4215c452/attachment.html>
-------------- 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/20150511/4215c452/attachment.bin>

From vslehman at memphis.edu  Tue May 12 08:47:08 2015
From: vslehman at memphis.edu (Vince Lehman (vslehman))
Date: Tue, 12 May 2015 15:47:08 +0000
Subject: [Nfd-dev] RTT delay caused by RIB registration commands
In-Reply-To: <CAOFH+Obrs1_bNOqZhJyboFUuPxn6pz2E79vSW-+LEz4kEFYizw@mail.gmail.com>
References: <2E7F0681-E8C1-49F6-BAEA-8A48F3B4B4E8@memphis.edu>
	<D10AB5AE-A329-49F3-A967-3CCF75C6B89F@memphis.edu>
	<CAOFH+ObVN985Ewms+c9v6azfEOjkb3JOY9mJayu0LTJCN20VGA@mail.gmail.com>
	<8DF5E537-B6CE-4B9E-BF73-EF826CC236AA@memphis.edu>
	<122E97D6-A2CF-4CBE-BD8A-CF82767241DA@memphis.edu>
	<CAOFH+Obrs1_bNOqZhJyboFUuPxn6pz2E79vSW-+LEz4kEFYizw@mail.gmail.com>
Message-ID: <64330686-43E4-4F97-A343-50CD0E55D670@memphis.edu>

This shows a correlation between signing algorithm and max RTT, but the variance is much larger compared to the logs from Apr 23.
Are you using a different machine?

Yes, I should have been more clear. The results in the previous email are from our routing experiments where we originally encountered the problem.

How many CPU cores does this machine have? There shouldn't be much difference between 2 and 3 on a quad-core machine.

The machine has 4 cores. The difference between tests 2 and 3 are due to the change in the library which would also affect NLSR. When NLSR sends the RIB registration commands, they are also signed using signWithSha256.

Also, please confirm you have changed ".sign(" to ".signWithSha256(" in all these files for "NFD Management":

  *   NFD/core/segment-publisher.hpp (for answering face query; unnecessary if nfdc is using a FaceId)
  *   NFD/core/notification-stream.hpp (for generating face status change notifications)
  *   NFD/daemon/mgmt/manager-base.cpp (for answering commands)

Yes, I have modified each of these files for tests 2 and 3.

--
Vince Lehman

On May 6, 2015, at 7:04 PM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:

Hi Vince

Summary from your logs:

  1.  NFD=RSA, ndn::nfd::Controller=RSA: min 7.098ms, max 52.041ms
  2.  NFD=SHA256, ndn::nfd::Controller=RSA: min 7.277ms, max 40.540ms
  3.  NFD=SHA256, ndn::nfd::Controller=SHA256: min 7.732ms, max 12.022ms

This shows a correlation between signing algorithm and max RTT, but the variance is much larger compared to the logs from Apr 23.
Are you using a different machine?
How many CPU cores does this machine have? There shouldn't be much difference between 2 and 3 on a quad-core machine.

Also, please confirm you have changed ".sign(" to ".signWithSha256(" in all these files for "NFD Management":

  *   NFD/core/segment-publisher.hpp (for answering face query; unnecessary if nfdc is using a FaceId)
  *   NFD/core/notification-stream.hpp (for generating face status change notifications)
  *   NFD/daemon/mgmt/manager-base.cpp (for answering commands)

Yours, Junxiao

On Wed, May 6, 2015 at 4:04 PM, Vince Lehman (vslehman) <vslehman at memphis.edu<mailto:vslehman at memphis.edu>> wrote:
At the NFD call today, it was suggested that I try our experiments with a different, quicker signing method for NFD?s management modules.

I ran the following three tests:

1.) Unmodified NFD to get baseline results
2.) NFD with management modules using KeyChain::signWithSha256 for control responses
3.) Test 2 + modified ndn::nfd::Controller in ndn-cxx so control commands are signed using KeyChain::signWithSha256

The results I collected suggest that signing is largely the cause of the RTT jumps.

1. ) Unchanged NFD using KeyChain::sign():

20150506T220013.546312 - Content From /ndn/edu/orange - Ping Reference = 358723384   - Round Trip Time = 7.54174 ms
20150506T220014.545910 - Content From /ndn/edu/orange - Ping Reference = 358723385   - Round Trip Time = 7.35931 ms
20150506T220015.549327 - Content From /ndn/edu/orange - Ping Reference = 358723386   - Round Trip Time = 10.755 ms
20150506T220016.569095 - Content From /ndn/edu/orange - Ping Reference = 358723387   - Round Trip Time = 26.909 ms
20150506T220017.554450 - Content From /ndn/edu/orange - Ping Reference = 358723388   - Round Trip Time = 15.8414 ms
20150506T220018.550272 - Content From /ndn/edu/orange - Ping Reference = 358723389   - Round Trip Time = 11.7576 ms
20150506T220019.594078 - Content From /ndn/edu/orange - Ping Reference = 358723390   - Round Trip Time = 52.0413 ms
20150506T220020.572899 - Content From /ndn/edu/orange - Ping Reference = 358723391   - Round Trip Time = 31.8473 ms
20150506T220021.568606 - Content From /ndn/edu/orange - Ping Reference = 358723392   - Round Trip Time = 29.9206 ms
20150506T220022.545620 - Content From /ndn/edu/orange - Ping Reference = 358723393   - Round Trip Time = 7.09895 ms
20150506T220023.551988 - Content From /ndn/edu/orange - Ping Reference = 358723394   - Round Trip Time = 13.4654 ms
20150506T220024.564711 - Content From /ndn/edu/orange - Ping Reference = 358723395   - Round Trip Time = 26.1983 ms
20150506T220025.590458 - Content From /ndn/edu/orange - Ping Reference = 358723396   - Round Trip Time = 51.8421 ms
20150506T220026.547079 - Content From /ndn/edu/orange - Ping Reference = 358723397   - Round Trip Time = 8.38067 ms
20150506T220027.546382 - Content From /ndn/edu/orange - Ping Reference = 358723398   - Round Trip Time = 7.7887 ms

2.) NFD Management using KeyChain::signWithSha256() for control responses:

20150506T220832.990110 - Content From /ndn/edu/orange - Ping Reference = 481750786   - Round Trip Time = 8.12952 ms
20150506T220833.989616 - Content From /ndn/edu/orange - Ping Reference = 481750787   - Round Trip Time = 7.27718 ms
20150506T220835.000043 - Content From /ndn/edu/orange - Ping Reference = 481750788   - Round Trip Time = 17.7199 ms
20150506T220835.997854 - Content From /ndn/edu/orange - Ping Reference = 481750789   - Round Trip Time = 15.8593 ms
20150506T220836.990831 - Content From /ndn/edu/orange - Ping Reference = 481750790   - Round Trip Time = 8.84247 ms
20150506T220838.011070 - Content From /ndn/edu/orange - Ping Reference = 481750791   - Round Trip Time = 17.0122 ms
20150506T220839.022594 - Content From /ndn/edu/orange - Ping Reference = 481750792   - Round Trip Time = 40.5401 ms
20150506T220839.996497 - Content From /ndn/edu/orange - Ping Reference = 481750793   - Round Trip Time = 13.9247 ms
20150506T220841.000317 - Content From /ndn/edu/orange - Ping Reference = 481750794   - Round Trip Time = 18.0118 ms
20150506T220841.990391 - Content From /ndn/edu/orange - Ping Reference = 481750795   - Round Trip Time = 8.36782 ms
20150506T220842.989631 - Content From /ndn/edu/orange - Ping Reference = 481750796   - Round Trip Time = 7.57163 ms
20150506T220843.990083 - Content From /ndn/edu/orange - Ping Reference = 481750797   - Round Trip Time = 7.9309 ms

3.) NFD Management using KeyChain::signWithSha256() and ndn::nfd::Controller::start() using KeyChain::signWithSha256:

20150506T224746.920419 - Content From /ndn/edu/orange - Ping Reference = 432571709   - Round Trip Time = 7.74707 ms
20150506T224747.920684 - Content From /ndn/edu/orange - Ping Reference = 432571710   - Round Trip Time = 8.08427 ms
20150506T224748.921073 - Content From /ndn/edu/orange - Ping Reference = 432571711   - Round Trip Time = 7.95967 ms
20150506T224749.920619 - Content From /ndn/edu/orange - Ping Reference = 432571712   - Round Trip Time = 7.78507 ms
20150506T224750.923189 - Content From /ndn/edu/orange - Ping Reference = 432571713   - Round Trip Time = 10.5592 ms
20150506T224751.920660 - Content From /ndn/edu/orange - Ping Reference = 432571714   - Round Trip Time = 7.73255 ms
20150506T224752.920939 - Content From /ndn/edu/orange - Ping Reference = 432571715   - Round Trip Time = 8.24211 ms
20150506T224753.923819 - Content From /ndn/edu/orange - Ping Reference = 432571716   - Round Trip Time = 9.19251 ms
20150506T224754.921798 - Content From /ndn/edu/orange - Ping Reference = 432571717   - Round Trip Time = 8.94248 ms
20150506T224755.924729 - Content From /ndn/edu/orange - Ping Reference = 432571718   - Round Trip Time = 12.0222 ms
20150506T224756.920302 - Content From /ndn/edu/orange - Ping Reference = 432571719   - Round Trip Time = 7.75629 ms


--
Vince Lehman

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

From alexander.afanasyev at UCLA.EDU  Tue May 12 21:07:03 2015
From: alexander.afanasyev at UCLA.EDU (Alex Afanasyev)
Date: Tue, 12 May 2015 21:07:03 -0700
Subject: [Nfd-dev] New technical reports released
Message-ID: <83AEA43A-6F60-4B38-84D4-05F904554E85@ucla.edu>

Hi all,

I want to let everybody know that we released the following new NDN technical reports:

- Revision 4 of "NFD Developer?s Guide"
http://named-data.net/publications/techreports/ndn-0021-4-nfd-developer-guide/

- "Packet Fragmentation in NDN: Why NDN Uses Hop-By-Hop Fragmentation? from NDN Memo series
http://named-data.net/publications/techreports/ndn-0032-1-ndn-memo-fragmentation/


Alex Afanasyev
---
Internet Research Laboratory
University of California, Los Angeles
http://lasr.cs.ucla.edu/afanasyev/index.html

-------------- 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/20150512/0c7cd4c2/attachment.bin>

From alexander.afanasyev at UCLA.EDU  Tue May 12 23:17:00 2015
From: alexander.afanasyev at UCLA.EDU (Alex Afanasyev)
Date: Tue, 12 May 2015 23:17:00 -0700
Subject: [Nfd-dev] NFD 0.3.2 and ndn-cxx 0.3.2 released
Message-ID: <624FAD65-4A9A-4E6F-ABE3-115160C92899@ucla.edu>

Dear all,

We are pleased to announce release of version 0.3.2 of Named Data Networking
Forwarding Daemon (NFD) and ndn-cxx library.

The detailed notes for the releases:
 - for NFD: http://named-data.net/doc/NFD/0.3.2/RELEASE_NOTES.html
 - for ndn-cxx library: http://named-data.net/doc/ndn-cxx/0.3.2/RELEASE_NOTES.html

Source code, instruction how to install pre-compiled binaries on Ubuntu
Linux (12.04, 14.04, and 15.04), how to install NDN software using MacPort
packages or HomeBrew on OS X, tutorials, HOWTOs, a FAQ and other useful
resources are available on official webpages of NFD and ndn-cxx:
 - http://named-data.net/doc/NFD/0.3.2/
 - http://named-data.net/doc/ndn-cxx/0.3.2/

We also have updated the NFD developer's guide to match the new release:
- http://named-data.net/publications/techreports/ndn-0021-4-nfd-developer-guide/.

* * *

The NDN/NFD Team:
  Alexander Afanasyev, Junxiao Shi, Beichuan Zhang, Lixia Zhang, Ilya
  Moiseenko, Yingdi Yu, Wentao Shang, Yanbiao Li, Spyridon Mastorakis, Yi
  Huang, Jerald Paul Abraham, Steve DiBenedetto, Chengyu Fan, Christos
  Papadopoulos, Davide Pesavento, Giulio Grassi, Giovanni Pau, Hang Zhang,
  Tian Song, Haowei Yuan, Hila Ben Abraham, Patrick Crowley, Syed Obaid Amin,
  Vince Lehman, Lan Wang, and others (http://named-data.net/project/participants/)

-------------- 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/20150512/48ae4c93/attachment.bin>

From shijunxiao at email.arizona.edu  Wed May 13 15:43:49 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Wed, 13 May 2015 15:43:49 -0700
Subject: [Nfd-dev] Querying pending Interest in PIT.
In-Reply-To: <CAHVD1iaSrO6zg=O9wGYYnX9GNSW09VdOzo3MEZcr9dSdpyUrJA@mail.gmail.com>
References: <CAHVD1iaSrO6zg=O9wGYYnX9GNSW09VdOzo3MEZcr9dSdpyUrJA@mail.gmail.com>
Message-ID: <CAOFH+Oaw4eEcAptUf_AnZcVYfY5BYp96M+0rW2ZVWC8UXVzbLw@mail.gmail.com>

Hi Anil

What context are you programming in?

   - a forwarding strategy, or
   - a monitoring tool, or
   - a ndnSIM scenario?


StatusDataset may not be the best choice, because requesting a
StatusDataset involves sending Interests which would affect PIT state.

Yours, Junxiao

On Mon, May 11, 2015 at 11:20 AM, Anil Jangam <anilj.mailing at gmail.com>
wrote:

> Hi,
>
> I have a requirement where I need to check the state of PIT and find out
> or manage specific set of pending interests given the name.
>
> I checked the management control interface of NFD, which mainly talks
> about Face, Fib and Strategy. I did not find anything specific to PIT.
>
> Are there APIs available or do we have to develop a manager for PIT as
> well? Is that feasible?
>
> Regards,
> /anil.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150513/9b116269/attachment.html>

From anilj.mailing at gmail.com  Wed May 13 16:36:20 2015
From: anilj.mailing at gmail.com (Anil Jangam)
Date: Wed, 13 May 2015 16:36:20 -0700
Subject: [Nfd-dev] Querying pending Interest in PIT.
In-Reply-To: <CAOFH+Oaw4eEcAptUf_AnZcVYfY5BYp96M+0rW2ZVWC8UXVzbLw@mail.gmail.com>
References: <CAHVD1iaSrO6zg=O9wGYYnX9GNSW09VdOzo3MEZcr9dSdpyUrJA@mail.gmail.com>
	<CAOFH+Oaw4eEcAptUf_AnZcVYfY5BYp96M+0rW2ZVWC8UXVzbLw@mail.gmail.com>
Message-ID: <CAHVD1ibOe4m7x1mExHt3H5xYFota7WS_aUEV3069mfkqGqjsKQ@mail.gmail.com>

Junxiao,

I guess it is a forwarding strategy scenario. But it is for sure, I do not
want PIT state change while I am querying it. Also, it is a local
application running over given NFD, which is querying the PIT state. I mean
both the querying app and NFD are coexisting on the same host.

/anil.

On Wed, May 13, 2015 at 3:43 PM, Junxiao Shi <shijunxiao at email.arizona.edu>
wrote:

> Hi Anil
>
> What context are you programming in?
>
>    - a forwarding strategy, or
>    - a monitoring tool, or
>    - a ndnSIM scenario?
>
>
> StatusDataset may not be the best choice, because requesting a
> StatusDataset involves sending Interests which would affect PIT state.
>
> Yours, Junxiao
>
>
> On Mon, May 11, 2015 at 11:20 AM, Anil Jangam <anilj.mailing at gmail.com>
> wrote:
>
>> Hi,
>>
>> I have a requirement where I need to check the state of PIT and find out
>> or manage specific set of pending interests given the name.
>>
>> I checked the management control interface of NFD, which mainly talks
>> about Face, Fib and Strategy. I did not find anything specific to PIT.
>>
>> Are there APIs available or do we have to develop a manager for PIT as
>> well? Is that feasible?
>>
>> Regards,
>> /anil.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150513/763651c2/attachment.html>

From anilj.mailing at gmail.com  Wed May 13 18:02:34 2015
From: anilj.mailing at gmail.com (Anil Jangam)
Date: Wed, 13 May 2015 18:02:34 -0700
Subject: [Nfd-dev] Querying pending Interest in PIT.
In-Reply-To: <CAHVD1ibOe4m7x1mExHt3H5xYFota7WS_aUEV3069mfkqGqjsKQ@mail.gmail.com>
References: <CAHVD1iaSrO6zg=O9wGYYnX9GNSW09VdOzo3MEZcr9dSdpyUrJA@mail.gmail.com>
	<CAOFH+Oaw4eEcAptUf_AnZcVYfY5BYp96M+0rW2ZVWC8UXVzbLw@mail.gmail.com>
	<CAHVD1ibOe4m7x1mExHt3H5xYFota7WS_aUEV3069mfkqGqjsKQ@mail.gmail.com>
Message-ID: <CAHVD1iZjWWqVE5qtxGqbCqZZxsEDGtTGbJWVXGGy=MNygf3s0Q@mail.gmail.com>

Hello Junxiao,

What's the best approach to implement this feature then? Do you have any
recommendation?

/anil
On May 13, 2015 4:36 PM, "Anil Jangam" <anilj.mailing at gmail.com> wrote:

> Junxiao,
>
> I guess it is a forwarding strategy scenario. But it is for sure, I do
> not want PIT state change while I am querying it. Also, it is a local
> application running over given NFD, which is querying the PIT state. I mean
> both the querying app and NFD are coexisting on the same host.
>
> /anil.
>
> On Wed, May 13, 2015 at 3:43 PM, Junxiao Shi <shijunxiao at email.arizona.edu
> > wrote:
>
>> Hi Anil
>>
>> What context are you programming in?
>>
>>    - a forwarding strategy, or
>>    - a monitoring tool, or
>>    - a ndnSIM scenario?
>>
>>
>> StatusDataset may not be the best choice, because requesting a
>> StatusDataset involves sending Interests which would affect PIT state.
>>
>> Yours, Junxiao
>>
>>
>> On Mon, May 11, 2015 at 11:20 AM, Anil Jangam <anilj.mailing at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I have a requirement where I need to check the state of PIT and find out
>>> or manage specific set of pending interests given the name.
>>>
>>> I checked the management control interface of NFD, which mainly talks
>>> about Face, Fib and Strategy. I did not find anything specific to PIT.
>>>
>>> Are there APIs available or do we have to develop a manager for PIT as
>>> well? Is that feasible?
>>>
>>> Regards,
>>> /anil.
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150513/99124c49/attachment.html>

From shijunxiao at email.arizona.edu  Wed May 13 19:58:51 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Wed, 13 May 2015 19:58:51 -0700
Subject: [Nfd-dev] Querying pending Interest in PIT.
In-Reply-To: <CAHVD1ibOe4m7x1mExHt3H5xYFota7WS_aUEV3069mfkqGqjsKQ@mail.gmail.com>
References: <CAHVD1iaSrO6zg=O9wGYYnX9GNSW09VdOzo3MEZcr9dSdpyUrJA@mail.gmail.com>
	<CAOFH+Oaw4eEcAptUf_AnZcVYfY5BYp96M+0rW2ZVWC8UXVzbLw@mail.gmail.com>
	<CAHVD1ibOe4m7x1mExHt3H5xYFota7WS_aUEV3069mfkqGqjsKQ@mail.gmail.com>
Message-ID: <CAOFH+OZmY0JHmDBzOLs7zOW0XuN5pVR2U0qq05MRoj6remniOA@mail.gmail.com>

Hi Anil

It appears that you aren't sure whether a forwarding strategy is the
appropriate place for this feature.
Please give more context on the requirement: what are you trying to
achieve, and why do you need to enumerate PIT entries.

Yours, Junxiao

On Wed, May 13, 2015 at 4:36 PM, Anil Jangam <anilj.mailing at gmail.com>
wrote:

> Junxiao,
>
> I guess it is a forwarding strategy scenario. But it is for sure, I do
> not want PIT state change while I am querying it. Also, it is a local
> application running over given NFD, which is querying the PIT state. I mean
> both the querying app and NFD are coexisting on the same host.
>
> /anil.
>
> On Wed, May 13, 2015 at 3:43 PM, Junxiao Shi <shijunxiao at email.arizona.edu
> > wrote:
>
>> Hi Anil
>>
>> What context are you programming in?
>>
>>    - a forwarding strategy, or
>>    - a monitoring tool, or
>>    - a ndnSIM scenario?
>>
>>
>> StatusDataset may not be the best choice, because requesting a
>> StatusDataset involves sending Interests which would affect PIT state.
>>
>> Yours, Junxiao
>>
>>
>> On Mon, May 11, 2015 at 11:20 AM, Anil Jangam <anilj.mailing at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I have a requirement where I need to check the state of PIT and find out
>>> or manage specific set of pending interests given the name.
>>>
>>> I checked the management control interface of NFD, which mainly talks
>>> about Face, Fib and Strategy. I did not find anything specific to PIT.
>>>
>>> Are there APIs available or do we have to develop a manager for PIT as
>>> well? Is that feasible?
>>>
>>> Regards,
>>> /anil.
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150513/5bf5adc3/attachment.html>

From anilj.mailing at gmail.com  Wed May 13 20:15:26 2015
From: anilj.mailing at gmail.com (Anil Jangam)
Date: Wed, 13 May 2015 20:15:26 -0700
Subject: [Nfd-dev] Querying pending Interest in PIT.
In-Reply-To: <CAOFH+OZmY0JHmDBzOLs7zOW0XuN5pVR2U0qq05MRoj6remniOA@mail.gmail.com>
References: <CAHVD1iaSrO6zg=O9wGYYnX9GNSW09VdOzo3MEZcr9dSdpyUrJA@mail.gmail.com>
	<CAOFH+Oaw4eEcAptUf_AnZcVYfY5BYp96M+0rW2ZVWC8UXVzbLw@mail.gmail.com>
	<CAHVD1ibOe4m7x1mExHt3H5xYFota7WS_aUEV3069mfkqGqjsKQ@mail.gmail.com>
	<CAOFH+OZmY0JHmDBzOLs7zOW0XuN5pVR2U0qq05MRoj6remniOA@mail.gmail.com>
Message-ID: <CAHVD1iYOa6Agv9SwXAg31PY=rge2j4FcBqiK1BeLXYpN6fv47w@mail.gmail.com>

Ok, I would say it is a monitoring scenario. I am trying to write an
application, where it checks for specific pending interests in a router,
and guide it to fetch it from the location which application might already
know of. This is very rough thought as of now. But the bottom line is that
I need to find out the pending interests on router and corresponding
content names.

Hope this is helps.

/anil.


On Wed, May 13, 2015 at 7:58 PM, Junxiao Shi <shijunxiao at email.arizona.edu>
wrote:

> Hi Anil
>
> It appears that you aren't sure whether a forwarding strategy is the
> appropriate place for this feature.
> Please give more context on the requirement: what are you trying to
> achieve, and why do you need to enumerate PIT entries.
>
> Yours, Junxiao
>
>
> On Wed, May 13, 2015 at 4:36 PM, Anil Jangam <anilj.mailing at gmail.com>
> wrote:
>
>> Junxiao,
>>
>> I guess it is a forwarding strategy scenario. But it is for sure, I do
>> not want PIT state change while I am querying it. Also, it is a local
>> application running over given NFD, which is querying the PIT state. I mean
>> both the querying app and NFD are coexisting on the same host.
>>
>> /anil.
>>
>> On Wed, May 13, 2015 at 3:43 PM, Junxiao Shi <
>> shijunxiao at email.arizona.edu> wrote:
>>
>>> Hi Anil
>>>
>>> What context are you programming in?
>>>
>>>    - a forwarding strategy, or
>>>    - a monitoring tool, or
>>>    - a ndnSIM scenario?
>>>
>>>
>>> StatusDataset may not be the best choice, because requesting a
>>> StatusDataset involves sending Interests which would affect PIT state.
>>>
>>> Yours, Junxiao
>>>
>>>
>>> On Mon, May 11, 2015 at 11:20 AM, Anil Jangam <anilj.mailing at gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I have a requirement where I need to check the state of PIT and find
>>>> out or manage specific set of pending interests given the name.
>>>>
>>>> I checked the management control interface of NFD, which mainly talks
>>>> about Face, Fib and Strategy. I did not find anything specific to PIT.
>>>>
>>>> Are there APIs available or do we have to develop a manager for PIT as
>>>> well? Is that feasible?
>>>>
>>>> Regards,
>>>> /anil.
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150513/b9dbe9b8/attachment.html>

From shijunxiao at email.arizona.edu  Wed May 13 20:20:11 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Wed, 13 May 2015 20:20:11 -0700
Subject: [Nfd-dev] Querying pending Interest in PIT.
In-Reply-To: <CAHVD1iYOa6Agv9SwXAg31PY=rge2j4FcBqiK1BeLXYpN6fv47w@mail.gmail.com>
References: <CAHVD1iaSrO6zg=O9wGYYnX9GNSW09VdOzo3MEZcr9dSdpyUrJA@mail.gmail.com>
	<CAOFH+Oaw4eEcAptUf_AnZcVYfY5BYp96M+0rW2ZVWC8UXVzbLw@mail.gmail.com>
	<CAHVD1ibOe4m7x1mExHt3H5xYFota7WS_aUEV3069mfkqGqjsKQ@mail.gmail.com>
	<CAOFH+OZmY0JHmDBzOLs7zOW0XuN5pVR2U0qq05MRoj6remniOA@mail.gmail.com>
	<CAHVD1iYOa6Agv9SwXAg31PY=rge2j4FcBqiK1BeLXYpN6fv47w@mail.gmail.com>
Message-ID: <CAOFH+OYF+o19JFMNCLnXS9C38xRQU_tiFc5nYt0Y8qzhyFSsKQ@mail.gmail.com>

Hi Anil

Suppose your program is informed of a specific pending Interest, how does
the program know where to guide the Interest?
If the location is already known, it should be installed into the RIB.

Yours, Junxiao

On Wed, May 13, 2015 at 8:15 PM, Anil Jangam <anilj.mailing at gmail.com>
wrote:

> Ok, I would say it is a monitoring scenario. I am trying to write an
> application, where it checks for specific pending interests in a router,
> and guide it to fetch it from the location which application might already
> know of. This is very rough thought as of now. But the bottom line is that
> I need to find out the pending interests on router and corresponding
> content names.
>
> Hope this is helps.
>
> /anil.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150513/8d6fc775/attachment.html>

From joaopapereira at gmail.com  Thu May 14 14:21:25 2015
From: joaopapereira at gmail.com (Joao Pereira)
Date: Thu, 14 May 2015 21:21:25 +0000
Subject: [Nfd-dev] New arrival
Message-ID: <CAAq25NSNyS+LuphXCCR055ebHNtkQ7SDTeha2j3tAJYtWjtruA@mail.gmail.com>

Hello,
Been reading around the website about the project and it got me interested.
Would like to know if it is open to community contributions or not. If it
is open if you have specific WoW defined in order to contribute.

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

From dibenede at cs.colostate.edu  Thu May 14 14:26:18 2015
From: dibenede at cs.colostate.edu (Steve DiBenedetto)
Date: Thu, 14 May 2015 15:26:18 -0600
Subject: [Nfd-dev] New arrival
In-Reply-To: <CAAq25NSNyS+LuphXCCR055ebHNtkQ7SDTeha2j3tAJYtWjtruA@mail.gmail.com>
References: <CAAq25NSNyS+LuphXCCR055ebHNtkQ7SDTeha2j3tAJYtWjtruA@mail.gmail.com>
Message-ID: <CAG95NwsGgGXqAbzqrWswu280c+5f9MR74VdDXKRp3RRtAZyiAw@mail.gmail.com>

Hi!

We are absolutely open to community contributions (but I'm not familiar
with the term "WoW"). What kinds of things are you interested in working on?

We keep our issue trackers and wikis at http://redmine.named-data.net and
code review at http://gerrit.named-data.net/#/q/status:open . Please use
the gerrit repos instead of the github ones.

-Steve



On Thu, May 14, 2015 at 3:21 PM, Joao Pereira <joaopapereira at gmail.com>
wrote:

> Hello,
> Been reading around the website about the project and it got me
> interested. Would like to know if it is open to community contributions or
> not. If it is open if you have specific WoW defined in order to contribute.
>
> Best Regards
>
> _______________________________________________
> 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/20150514/ecefa0e8/attachment.html>

From alexander.afanasyev at ucla.edu  Thu May 14 14:28:59 2015
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Thu, 14 May 2015 14:28:59 -0700
Subject: [Nfd-dev] New arrival
In-Reply-To: <CAAq25NSNyS+LuphXCCR055ebHNtkQ7SDTeha2j3tAJYtWjtruA@mail.gmail.com>
References: <CAAq25NSNyS+LuphXCCR055ebHNtkQ7SDTeha2j3tAJYtWjtruA@mail.gmail.com>
Message-ID: <8CF0CBFB-48ED-4EDB-ABE2-50A8E3195122@ucla.edu>

Hi Joao,

Thanks for your interest!  Yes, all of our projects highly welcome all community contributions.

For most of the software, we are using redmine (http://redmine.named-data.net/ <http://redmine.named-data.net/>) to initiate and track feature requests and bug reports, as well to discuss particular issues and design choices.   The code itself can be submitted to our code review system (and everybody welcome to participate in the code review process itself) to our gerrit system (http://gerrit.named-data.net <http://gerrit.named-data.net/>).  All the agreed upon code is then merged and replicated in a few different places, including our github repository (https://github.com/named-data <https://github.com/named-data>).

Are you interested in some specific project?

?
Alex

> On May 14, 2015, at 2:21 PM, Joao Pereira <joaopapereira at gmail.com> wrote:
> 
> Hello,
> Been reading around the website about the project and it got me interested. Would like to know if it is open to community contributions or not. If it is open if you have specific WoW defined in order to contribute.
> 
> Best Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150514/9a6a9fdc/attachment.html>
-------------- 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/20150514/9a6a9fdc/attachment.bin>

From anilj.mailing at gmail.com  Thu May 14 21:45:49 2015
From: anilj.mailing at gmail.com (Anil Jangam)
Date: Thu, 14 May 2015 21:45:49 -0700
Subject: [Nfd-dev] Starting NFD locally from compiled sources.
Message-ID: <CAHVD1iacY=5G7Up1_L0GsXOPLyCUKYr1qe-3o7BZvCg2=ydv6g@mail.gmail.com>

Hi,

I am attempting to run 'nfd' from compiled binary. However, I am running
into a following problem. (see the last line).

sudo ./build/bin/nfd --config ./ndn_conf/nfd.conf
1431664563.044290 INFO: [StrategyChoice] setDefaultStrategy
/localhost/nfd/strategy/best-route/%FD%03
1431664563.044910 INFO: [InternalFace] registering callback for
/localhost/nfd/fib
1431664563.045027 INFO: [InternalFace] registering callback for
/localhost/nfd/faces
1431664563.045111 INFO: [InternalFace] registering callback for
/localhost/nfd/strategy-choice
1431664563.045207 INFO: [InternalFace] registering callback for
/localhost/nfd/status
1431664563.045289 INFO: [FaceTable] Added face id=1 remote=internal://
local=internal://
1431664563.049813 INFO: [CommandValidator] Giving privilege "faces" to
identity /localhost/daemons/nfd/ksk-1430084088432
1431664563.049861 INFO: [CommandValidator] Giving privilege "fib" to
identity /localhost/daemons/nfd/ksk-1430084088432
1431664563.049886 INFO: [CommandValidator] Giving privilege
"strategy-choice" to identity /localhost/daemons/nfd/ksk-1430084088432
1431664563.049917 WARNING: [CommandValidator] Wildcard identity is intended
for demo purpose only and SHOULD NOT be used in production environment
1431664563.049943 INFO: [CommandValidator] Giving privilege "faces" to
identity wildcard
1431664563.049969 INFO: [CommandValidator] Giving privilege
"strategy-choice" to identity wildcard
1431664563.050159 INFO: [TablesConfigSection] Setting CS max packets to
65536
1431664563.050738 INFO: [MulticastUdpFace] [id=-1,local=udp4://
10.0.0.37:56363,remote=udp4://224.0.23.170:56363] Creating face
1431664563.050818 INFO: [FaceTable] Added face id=256 remote=udp4://
224.0.23.170:56363 local=udp4://10.0.0.37:56363
1431664563.053394 INFO: [EthernetFace]
[id=-1,local=dev://wlan0,remote=ether://[01:00:5e:00:17:aa]] Creating face
on wlan0/60:36:dd:a8:11:73
1431664563.081330 INFO: [FaceTable] Added face id=257
remote=ether://[01:00:5e:00:17:aa] local=dev://wlan0
1431664563.090395 INFO: [EthernetFace]
[id=-1,local=dev://eth0,remote=ether://[01:00:5e:00:17:aa]] Creating face
on eth0/e0:db:55:d6:eb:e3
1431664563.105145 INFO: [FaceTable] Added face id=258
remote=ether://[01:00:5e:00:17:aa] local=dev://eth0
1431664563.115727 INFO: [CommandValidator] Giving privilege "faces" to
identity /localhost/daemons/nfd/ksk-1430084088432
1431664563.116162 INFO: [CommandValidator] Giving privilege "fib" to
identity /localhost/daemons/nfd/ksk-1430084088432
1431664563.116575 INFO: [CommandValidator] Giving privilege
"strategy-choice" to identity /localhost/daemons/nfd/ksk-1430084088432
1431664563.116942 WARNING: [CommandValidator] Wildcard identity is intended
for demo purpose only and SHOULD NOT be used in production environment
1431664563.117065 INFO: [CommandValidator] Giving privilege "faces" to
identity wildcard
1431664563.117297 INFO: [CommandValidator] Giving privilege
"strategy-choice" to identity wildcard
1431664563.117670 INFO: [FaceTable] Added face id=255 remote=null://
local=null://
1431664563.122135 INFO: [FaceTable] Added face id=254
remote=contentstore:// local=contentstore://
1431664563.124781 INFO: [PrivilegeHelper] dropped to effective uid=116
gid=126
1431664563.127378 INFO: [UnixStreamFace]
[id=-1,local=unix:///run/nfd.sock,remote=fd://25] Creating face
1431664563.127473 INFO: [FaceTable] Added face id=259 remote=fd://25
local=unix:///run/nfd.sock
1431664563.127904 FATAL: [NFD] FileStore: error opening file for reading:
/home/anilj1/.ndn/ndnsec-tpm-file/%JAmVmylSjFZutfeCI1dUvGgM+kOffJmUp3kLgktBVQ=.pri

I also tried after changing the grp and owner of the /home/anilj1/.ndn to
'root' but yet it did not help. Is something missing here?

One thing I am not sure when the .ndn folder is created? Is it created
first time by the nfd process after it is started? What if I remove this
folder before I start nfd locally?

Also is it possible to run nfd from a local user and not with sudo
proviledges?

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

From lanwang at memphis.edu  Thu May 14 21:57:23 2015
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Fri, 15 May 2015 04:57:23 +0000
Subject: [Nfd-dev] Starting NFD locally from compiled sources.
In-Reply-To: <CAHVD1iacY=5G7Up1_L0GsXOPLyCUKYr1qe-3o7BZvCg2=ydv6g@mail.gmail.com>
References: <CAHVD1iacY=5G7Up1_L0GsXOPLyCUKYr1qe-3o7BZvCg2=ydv6g@mail.gmail.com>
Message-ID: <5DE0044E-A508-48D1-8F6B-827C94059487@memphis.edu>

What are the permissions of the .ndn directory and the files in it?

Lan

On May 14, 2015, at 11:45 PM, Anil Jangam <anilj.mailing at gmail.com<mailto:anilj.mailing at gmail.com>>
 wrote:

Hi,

I am attempting to run 'nfd' from compiled binary. However, I am running into a following problem. (see the last line).

sudo ./build/bin/nfd --config ./ndn_conf/nfd.conf
1431664563.044290 INFO: [StrategyChoice] setDefaultStrategy /localhost/nfd/strategy/best-route/%FD%03
1431664563.044910 INFO: [InternalFace] registering callback for /localhost/nfd/fib
1431664563.045027 INFO: [InternalFace] registering callback for /localhost/nfd/faces
1431664563.045111 INFO: [InternalFace] registering callback for /localhost/nfd/strategy-choice
1431664563.045207 INFO: [InternalFace] registering callback for /localhost/nfd/status
1431664563.045289 INFO: [FaceTable] Added face id=1 remote=internal:// local=internal://
1431664563.049813 INFO: [CommandValidator] Giving privilege "faces" to identity /localhost/daemons/nfd/ksk-1430084088432
1431664563.049861 INFO: [CommandValidator] Giving privilege "fib" to identity /localhost/daemons/nfd/ksk-1430084088432
1431664563.049886 INFO: [CommandValidator] Giving privilege "strategy-choice" to identity /localhost/daemons/nfd/ksk-1430084088432
1431664563.049917 WARNING: [CommandValidator] Wildcard identity is intended for demo purpose only and SHOULD NOT be used in production environment
1431664563.049943 INFO: [CommandValidator] Giving privilege "faces" to identity wildcard
1431664563.049969 INFO: [CommandValidator] Giving privilege "strategy-choice" to identity wildcard
1431664563.050159 INFO: [TablesConfigSection] Setting CS max packets to 65536
1431664563.050738 INFO: [MulticastUdpFace] [id=-1,local=udp4://10.0.0.37:56363<http://10.0.0.37:56363/>,remote=udp4://224.0.23.170:56363<http://224.0.23.170:56363/>] Creating face
1431664563.050818 INFO: [FaceTable] Added face id=256 remote=udp4://224.0.23.170:56363<http://224.0.23.170:56363/> local=udp4://10.0.0.37:56363<http://10.0.0.37:56363/>
1431664563.053394 INFO: [EthernetFace] [id=-1,local=dev://wlan0,remote=ether://[01:00:5e:00:17:aa]] Creating face on wlan0/60:36:dd:a8:11:73
1431664563.081330 INFO: [FaceTable] Added face id=257 remote=ether://[01:00:5e:00:17:aa] local=dev://wlan0
1431664563.090395 INFO: [EthernetFace] [id=-1,local=dev://eth0,remote=ether://[01:00:5e:00:17:aa]] Creating face on eth0/e0:db:55:d6:eb:e3
1431664563.105145 INFO: [FaceTable] Added face id=258 remote=ether://[01:00:5e:00:17:aa] local=dev://eth0
1431664563.115727 INFO: [CommandValidator] Giving privilege "faces" to identity /localhost/daemons/nfd/ksk-1430084088432
1431664563.116162 INFO: [CommandValidator] Giving privilege "fib" to identity /localhost/daemons/nfd/ksk-1430084088432
1431664563.116575 INFO: [CommandValidator] Giving privilege "strategy-choice" to identity /localhost/daemons/nfd/ksk-1430084088432
1431664563.116942 WARNING: [CommandValidator] Wildcard identity is intended for demo purpose only and SHOULD NOT be used in production environment
1431664563.117065 INFO: [CommandValidator] Giving privilege "faces" to identity wildcard
1431664563.117297 INFO: [CommandValidator] Giving privilege "strategy-choice" to identity wildcard
1431664563.117670 INFO: [FaceTable] Added face id=255 remote=null:// local=null://
1431664563.122135 INFO: [FaceTable] Added face id=254 remote=contentstore:// local=contentstore://
1431664563.124781 INFO: [PrivilegeHelper] dropped to effective uid=116 gid=126
1431664563.127378 INFO: [UnixStreamFace] [id=-1,local=unix:///run/nfd.sock,remote=fd://25] Creating face
1431664563.127473 INFO: [FaceTable] Added face id=259 remote=fd://25 local=unix:///run/nfd.sock
1431664563.127904 FATAL: [NFD] FileStore: error opening file for reading: /home/anilj1/.ndn/ndnsec-tpm-file/%JAmVmylSjFZutfeCI1dUvGgM+kOffJmUp3kLgktBVQ=.pri

I also tried after changing the grp and owner of the /home/anilj1/.ndn to 'root' but yet it did not help. Is something missing here?

One thing I am not sure when the .ndn folder is created? Is it created first time by the nfd process after it is started? What if I remove this folder before I start nfd locally?

Also is it possible to run nfd from a local user and not with sudo proviledges?

/anil.

_______________________________________________
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/20150515/7871f5e2/attachment.html>

From anilj.mailing at gmail.com  Thu May 14 22:10:03 2015
From: anilj.mailing at gmail.com (Anil Jangam)
Date: Thu, 14 May 2015 22:10:03 -0700
Subject: [Nfd-dev] Starting NFD locally from compiled sources.
In-Reply-To: <5DE0044E-A508-48D1-8F6B-827C94059487@memphis.edu>
References: <CAHVD1iacY=5G7Up1_L0GsXOPLyCUKYr1qe-3o7BZvCg2=ydv6g@mail.gmail.com>
	<5DE0044E-A508-48D1-8F6B-827C94059487@memphis.edu>
Message-ID: <CAHVD1iYD265TPjpSo70hGJkYjamSEgzTY-C-RBuHOPZvko3dmw@mail.gmail.com>

Hi Prof Wang,

Ok.. it was: -r-------- 1 anilj1 anilj1 1643 Apr 26 12:35
%JAmVmylSjFZutfeCI1dUvGgM+kOffJmUp3kLgktBVQ=.pri

After added READ permissions to all, it is now throwing following errorr.

1431666355.351034 INFO: [RemoteRegistrator] Load remote_register section in
rib section
1431666355.351254 INFO: [RemoteRegistrator] Load remote_register section in
rib section
1431666355.351316 INFO: [RibManager] Listening on: /localhost/nfd/rib
1431666355.358148 INFO: [RibManager] Start monitoring face create/destroy
events
1431666355.370436 FATAL: [NFD] Error in setting interest filter
(/localhost/nfd/rib): Unauthorized command

Ideally, I am trying to run the 'nfd' in debug mode, either from Eclipse or
from command line gdb, to do a step wise execution. I want to understand
certain part of the code. Any pointers for this case will help.

/anil.


On Thu, May 14, 2015 at 9:57 PM, Lan Wang (lanwang) <lanwang at memphis.edu>
wrote:

>  What are the permissions of the .ndn directory and the files in it?
>
> Lan
>
>  On May 14, 2015, at 11:45 PM, Anil Jangam <anilj.mailing at gmail.com>
>  wrote:
>
>  Hi,
>
>  I am attempting to run 'nfd' from compiled binary. However, I am running
> into a following problem. (see the last line).
>
>  sudo ./build/bin/nfd --config ./ndn_conf/nfd.conf
> 1431664563.044290 INFO: [StrategyChoice] setDefaultStrategy
> /localhost/nfd/strategy/best-route/%FD%03
> 1431664563.044910 INFO: [InternalFace] registering callback for
> /localhost/nfd/fib
> 1431664563.045027 INFO: [InternalFace] registering callback for
> /localhost/nfd/faces
> 1431664563.045111 INFO: [InternalFace] registering callback for
> /localhost/nfd/strategy-choice
> 1431664563.045207 INFO: [InternalFace] registering callback for
> /localhost/nfd/status
> 1431664563.045289 INFO: [FaceTable] Added face id=1 remote=internal://
> local=internal://
> 1431664563.049813 INFO: [CommandValidator] Giving privilege "faces" to
> identity /localhost/daemons/nfd/ksk-1430084088432
> 1431664563.049861 INFO: [CommandValidator] Giving privilege "fib" to
> identity /localhost/daemons/nfd/ksk-1430084088432
> 1431664563.049886 INFO: [CommandValidator] Giving privilege
> "strategy-choice" to identity /localhost/daemons/nfd/ksk-1430084088432
> 1431664563.049917 WARNING: [CommandValidator] Wildcard identity is
> intended for demo purpose only and SHOULD NOT be used in production
> environment
> 1431664563.049943 INFO: [CommandValidator] Giving privilege "faces" to
> identity wildcard
> 1431664563.049969 INFO: [CommandValidator] Giving privilege
> "strategy-choice" to identity wildcard
> 1431664563.050159 INFO: [TablesConfigSection] Setting CS max packets to
> 65536
> 1431664563.050738 INFO: [MulticastUdpFace] [id=-1,local=udp4://
> 10.0.0.37:56363,remote=udp4://224.0.23.170:56363] Creating face
> 1431664563.050818 INFO: [FaceTable] Added face id=256 remote=udp4://
> 224.0.23.170:56363 local=udp4://10.0.0.37:56363
> 1431664563.053394 INFO: [EthernetFace] [id=-1,local=
> dev://wlan0,remote=ether://[01:00:5e:00:17:aa]] Creating face on
> wlan0/60:36:dd:a8:11:73
> 1431664563.081330 INFO: [FaceTable] Added face id=257 remote=
> ether://[01:00:5e:00:17:aa] local=dev://wlan0
> 1431664563.090395 INFO: [EthernetFace] [id=-1,local=
> dev://eth0,remote=ether://[01:00:5e:00:17:aa]] Creating face on
> eth0/e0:db:55:d6:eb:e3
> 1431664563.105145 INFO: [FaceTable] Added face id=258 remote=
> ether://[01:00:5e:00:17:aa] local=dev://eth0
> 1431664563.115727 INFO: [CommandValidator] Giving privilege "faces" to
> identity /localhost/daemons/nfd/ksk-1430084088432
> 1431664563.116162 INFO: [CommandValidator] Giving privilege "fib" to
> identity /localhost/daemons/nfd/ksk-1430084088432
> 1431664563.116575 INFO: [CommandValidator] Giving privilege
> "strategy-choice" to identity /localhost/daemons/nfd/ksk-1430084088432
> 1431664563.116942 WARNING: [CommandValidator] Wildcard identity is
> intended for demo purpose only and SHOULD NOT be used in production
> environment
> 1431664563.117065 INFO: [CommandValidator] Giving privilege "faces" to
> identity wildcard
> 1431664563.117297 INFO: [CommandValidator] Giving privilege
> "strategy-choice" to identity wildcard
> 1431664563.117670 INFO: [FaceTable] Added face id=255 remote=null://
> local=null://
> 1431664563.122135 INFO: [FaceTable] Added face id=254
> remote=contentstore:// local=contentstore://
> 1431664563.124781 INFO: [PrivilegeHelper] dropped to effective uid=116
> gid=126
> 1431664563.127378 INFO: [UnixStreamFace] [id=-1,local=
> unix:///run/nfd.sock,remote=fd://25] Creating face
> 1431664563.127473 INFO: [FaceTable] Added face id=259 remote=fd://25
> local=unix:///run/nfd.sock
> 1431664563.127904 FATAL: [NFD] FileStore: error opening file for reading:
> /home/anilj1/.ndn/ndnsec-tpm-file/%JAmVmylSjFZutfeCI1dUvGgM+kOffJmUp3kLgktBVQ=.pri
>
>  I also tried after changing the grp and owner of the /home/anilj1/.ndn
> to 'root' but yet it did not help. Is something missing here?
>
>  One thing I am not sure when the .ndn folder is created? Is it created
> first time by the nfd process after it is started? What if I remove this
> folder before I start nfd locally?
>
>  Also is it possible to run nfd from a local user and not with sudo
> proviledges?
>
>  /anil.
>
>   _______________________________________________
> 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/20150514/aaa93bcb/attachment.html>

From lanwang at memphis.edu  Thu May 14 22:13:09 2015
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Fri, 15 May 2015 05:13:09 +0000
Subject: [Nfd-dev] Starting NFD locally from compiled sources.
In-Reply-To: <CAHVD1iYD265TPjpSo70hGJkYjamSEgzTY-C-RBuHOPZvko3dmw@mail.gmail.com>
References: <CAHVD1iacY=5G7Up1_L0GsXOPLyCUKYr1qe-3o7BZvCg2=ydv6g@mail.gmail.com>
	<5DE0044E-A508-48D1-8F6B-827C94059487@memphis.edu>
	<CAHVD1iYD265TPjpSo70hGJkYjamSEgzTY-C-RBuHOPZvko3dmw@mail.gmail.com>
Message-ID: <7849D8D0-C275-4257-B92E-D36D155CF3E0@memphis.edu>

What about adding w permission to the user and r permission to group and other?

Lan

On May 15, 2015, at 12:10 AM, Anil Jangam <anilj.mailing at gmail.com<mailto:anilj.mailing at gmail.com>>
 wrote:

Hi Prof Wang,

Ok.. it was: -r-------- 1 anilj1 anilj1 1643 Apr 26 12:35 %JAmVmylSjFZutfeCI1dUvGgM+kOffJmUp3kLgktBVQ=.pri

After added READ permissions to all, it is now throwing following errorr.

1431666355.351034 INFO: [RemoteRegistrator] Load remote_register section in rib section
1431666355.351254 INFO: [RemoteRegistrator] Load remote_register section in rib section
1431666355.351316 INFO: [RibManager] Listening on: /localhost/nfd/rib
1431666355.358148 INFO: [RibManager] Start monitoring face create/destroy events
1431666355.370436 FATAL: [NFD] Error in setting interest filter (/localhost/nfd/rib): Unauthorized command

Ideally, I am trying to run the 'nfd' in debug mode, either from Eclipse or from command line gdb, to do a step wise execution. I want to understand certain part of the code. Any pointers for this case will help.

/anil.


On Thu, May 14, 2015 at 9:57 PM, Lan Wang (lanwang) <lanwang at memphis.edu<mailto:lanwang at memphis.edu>> wrote:
What are the permissions of the .ndn directory and the files in it?

Lan

On May 14, 2015, at 11:45 PM, Anil Jangam <anilj.mailing at gmail.com<mailto:anilj.mailing at gmail.com>>
 wrote:

Hi,

I am attempting to run 'nfd' from compiled binary. However, I am running into a following problem. (see the last line).

sudo ./build/bin/nfd --config ./ndn_conf/nfd.conf
1431664563.044290 INFO: [StrategyChoice] setDefaultStrategy /localhost/nfd/strategy/best-route/%FD%03
1431664563.044910 INFO: [InternalFace] registering callback for /localhost/nfd/fib
1431664563.045027 INFO: [InternalFace] registering callback for /localhost/nfd/faces
1431664563.045111 INFO: [InternalFace] registering callback for /localhost/nfd/strategy-choice
1431664563.045207 INFO: [InternalFace] registering callback for /localhost/nfd/status
1431664563.045289 INFO: [FaceTable] Added face id=1 remote=internal:// local=internal://
1431664563.049813 INFO: [CommandValidator] Giving privilege "faces" to identity /localhost/daemons/nfd/ksk-1430084088432
1431664563.049861 INFO: [CommandValidator] Giving privilege "fib" to identity /localhost/daemons/nfd/ksk-1430084088432
1431664563.049886 INFO: [CommandValidator] Giving privilege "strategy-choice" to identity /localhost/daemons/nfd/ksk-1430084088432
1431664563.049917 WARNING: [CommandValidator] Wildcard identity is intended for demo purpose only and SHOULD NOT be used in production environment
1431664563.049943 INFO: [CommandValidator] Giving privilege "faces" to identity wildcard
1431664563.049969 INFO: [CommandValidator] Giving privilege "strategy-choice" to identity wildcard
1431664563.050159 INFO: [TablesConfigSection] Setting CS max packets to 65536
1431664563.050738 INFO: [MulticastUdpFace] [id=-1,local=udp4://10.0.0.37:56363<http://10.0.0.37:56363/>,remote=udp4://224.0.23.170:56363<http://224.0.23.170:56363/>] Creating face
1431664563.050818 INFO: [FaceTable] Added face id=256 remote=udp4://224.0.23.170:56363<http://224.0.23.170:56363/> local=udp4://10.0.0.37:56363<http://10.0.0.37:56363/>
1431664563.053394 INFO: [EthernetFace] [id=-1,local=dev://wlan0,remote=ether://[01:00:5e:00:17:aa]] Creating face on wlan0/60:36:dd:a8:11:73
1431664563.081330 INFO: [FaceTable] Added face id=257 remote=ether://[01:00:5e:00:17:aa] local=dev://wlan0
1431664563.090395 INFO: [EthernetFace] [id=-1,local=dev://eth0,remote=ether://[01:00:5e:00:17:aa]] Creating face on eth0/e0:db:55:d6:eb:e3
1431664563.105145 INFO: [FaceTable] Added face id=258 remote=ether://[01:00:5e:00:17:aa] local=dev://eth0
1431664563.115727 INFO: [CommandValidator] Giving privilege "faces" to identity /localhost/daemons/nfd/ksk-1430084088432
1431664563.116162 INFO: [CommandValidator] Giving privilege "fib" to identity /localhost/daemons/nfd/ksk-1430084088432
1431664563.116575 INFO: [CommandValidator] Giving privilege "strategy-choice" to identity /localhost/daemons/nfd/ksk-1430084088432
1431664563.116942 WARNING: [CommandValidator] Wildcard identity is intended for demo purpose only and SHOULD NOT be used in production environment
1431664563.117065 INFO: [CommandValidator] Giving privilege "faces" to identity wildcard
1431664563.117297 INFO: [CommandValidator] Giving privilege "strategy-choice" to identity wildcard
1431664563.117670 INFO: [FaceTable] Added face id=255 remote=null:// local=null://
1431664563.122135 INFO: [FaceTable] Added face id=254 remote=contentstore:// local=contentstore://
1431664563.124781 INFO: [PrivilegeHelper] dropped to effective uid=116 gid=126
1431664563.127378 INFO: [UnixStreamFace] [id=-1,local=unix:///run/nfd.sock,remote=fd://25] Creating face
1431664563.127473 INFO: [FaceTable] Added face id=259 remote=fd://25 local=unix:///run/nfd.sock
1431664563.127904 FATAL: [NFD] FileStore: error opening file for reading: /home/anilj1/.ndn/ndnsec-tpm-file/%JAmVmylSjFZutfeCI1dUvGgM+kOffJmUp3kLgktBVQ=.pri

I also tried after changing the grp and owner of the /home/anilj1/.ndn to 'root' but yet it did not help. Is something missing here?

One thing I am not sure when the .ndn folder is created? Is it created first time by the nfd process after it is started? What if I remove this folder before I start nfd locally?

Also is it possible to run nfd from a local user and not with sudo proviledges?

/anil.

_______________________________________________
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/20150515/a6025687/attachment.html>

From anilj.mailing at gmail.com  Thu May 14 22:26:59 2015
From: anilj.mailing at gmail.com (Anil Jangam)
Date: Thu, 14 May 2015 22:26:59 -0700
Subject: [Nfd-dev] Starting NFD locally from compiled sources.
In-Reply-To: <7849D8D0-C275-4257-B92E-D36D155CF3E0@memphis.edu>
References: <CAHVD1iacY=5G7Up1_L0GsXOPLyCUKYr1qe-3o7BZvCg2=ydv6g@mail.gmail.com>
	<5DE0044E-A508-48D1-8F6B-827C94059487@memphis.edu>
	<CAHVD1iYD265TPjpSo70hGJkYjamSEgzTY-C-RBuHOPZvko3dmw@mail.gmail.com>
	<7849D8D0-C275-4257-B92E-D36D155CF3E0@memphis.edu>
Message-ID: <CAHVD1iav0_sfz8EGQLz1c1qQQF-U5K-8P6XcTMCSQ0uUXfOxMw@mail.gmail.com>

Well, just to be sure, I gave 777 as follows..

anilj1 at insp5521:~/sandbox/NFD$ ls -Rl /home/anilj1/.ndn
/home/anilj1/.ndn:
total 32
-rwxrwxrwx 1 anilj1 anilj1   985 May 14 22:22 client.conf
-rwxrwxrwx 1 anilj1 anilj1 18432 May  5 00:17 ndnsec-public-info.db
drwxrwxrwx 2 anilj1 anilj1  4096 May  5 00:17 ndnsec-tpm-file

/home/anilj1/.ndn/ndnsec-tpm-file:
total 20
-rwxrwxrwx 1 anilj1 anilj1 1643 Apr 26 12:35
%JAmVmylSjFZutfeCI1dUvGgM+kOffJmUp3kLgktBVQ=.pri
-rwxrwxrwx 1 anilj1 anilj1  398 Apr 26 12:35
%JAmVmylSjFZutfeCI1dUvGgM+kOffJmUp3kLgktBVQ=.pub
-rwxrwxrwx 1 anilj1 anilj1  208 May  5 00:17 mapping.txt
-rwxrwxrwx 1 anilj1 anilj1 1643 May  5 00:17
rkDt+b7SPQxsx4yL3t%bB4fou2FT1DzhKcpYWfe6Hwo=.pri
-rwxrwxrwx 1 anilj1 anilj1  398 May  5 00:17
rkDt+b7SPQxsx4yL3t%bB4fou2FT1DzhKcpYWfe6Hwo=.pub


But still the same error.

1431667575.326153 INFO: [RemoteRegistrator] Load remote_register section in
rib section
1431667575.326258 INFO: [RibManager] Listening on: /localhost/nfd/rib
1431667575.334410 INFO: [RibManager] Start monitoring face create/destroy
events
1431667575.345949 FATAL: [NFD] Error in setting interest filter
(/localhost/nfd/rib): Unauthorized command


/anil.



On Thu, May 14, 2015 at 10:13 PM, Lan Wang (lanwang) <lanwang at memphis.edu>
wrote:

>  What about adding w permission to the user and r permission to group and
> other?
>
> Lan
>
>  On May 15, 2015, at 12:10 AM, Anil Jangam <anilj.mailing at gmail.com>
>  wrote:
>
>  Hi Prof Wang,
>
>  Ok.. it was: -r-------- 1 anilj1 anilj1 1643 Apr 26 12:35
> %JAmVmylSjFZutfeCI1dUvGgM+kOffJmUp3kLgktBVQ=.pri
>
>  After added READ permissions to all, it is now throwing following
> errorr.
>
>  1431666355.351034 INFO: [RemoteRegistrator] Load remote_register section
> in rib section
> 1431666355.351254 INFO: [RemoteRegistrator] Load remote_register section
> in rib section
> 1431666355.351316 INFO: [RibManager] Listening on: /localhost/nfd/rib
> 1431666355.358148 INFO: [RibManager] Start monitoring face create/destroy
> events
> 1431666355.370436 FATAL: [NFD] Error in setting interest filter
> (/localhost/nfd/rib): Unauthorized command
>
>  Ideally, I am trying to run the 'nfd' in debug mode, either from Eclipse
> or from command line gdb, to do a step wise execution. I want to understand
> certain part of the code. Any pointers for this case will help.
>
>  /anil.
>
>
> On Thu, May 14, 2015 at 9:57 PM, Lan Wang (lanwang) <lanwang at memphis.edu>
> wrote:
>
>> What are the permissions of the .ndn directory and the files in it?
>>
>> Lan
>>
>>  On May 14, 2015, at 11:45 PM, Anil Jangam <anilj.mailing at gmail.com>
>>  wrote:
>>
>>   Hi,
>>
>>  I am attempting to run 'nfd' from compiled binary. However, I am
>> running into a following problem. (see the last line).
>>
>>  sudo ./build/bin/nfd --config ./ndn_conf/nfd.conf
>> 1431664563.044290 INFO: [StrategyChoice] setDefaultStrategy
>> /localhost/nfd/strategy/best-route/%FD%03
>> 1431664563.044910 INFO: [InternalFace] registering callback for
>> /localhost/nfd/fib
>> 1431664563.045027 INFO: [InternalFace] registering callback for
>> /localhost/nfd/faces
>> 1431664563.045111 INFO: [InternalFace] registering callback for
>> /localhost/nfd/strategy-choice
>> 1431664563.045207 INFO: [InternalFace] registering callback for
>> /localhost/nfd/status
>> 1431664563.045289 INFO: [FaceTable] Added face id=1 remote=internal://
>> local=internal://
>> 1431664563.049813 INFO: [CommandValidator] Giving privilege "faces" to
>> identity /localhost/daemons/nfd/ksk-1430084088432
>> 1431664563.049861 INFO: [CommandValidator] Giving privilege "fib" to
>> identity /localhost/daemons/nfd/ksk-1430084088432
>> 1431664563.049886 INFO: [CommandValidator] Giving privilege
>> "strategy-choice" to identity /localhost/daemons/nfd/ksk-1430084088432
>> 1431664563.049917 WARNING: [CommandValidator] Wildcard identity is
>> intended for demo purpose only and SHOULD NOT be used in production
>> environment
>> 1431664563.049943 INFO: [CommandValidator] Giving privilege "faces" to
>> identity wildcard
>> 1431664563.049969 INFO: [CommandValidator] Giving privilege
>> "strategy-choice" to identity wildcard
>> 1431664563.050159 INFO: [TablesConfigSection] Setting CS max packets to
>> 65536
>> 1431664563.050738 INFO: [MulticastUdpFace] [id=-1,local=udp4://
>> 10.0.0.37:56363,remote=udp4://224.0.23.170:56363] Creating face
>> 1431664563.050818 INFO: [FaceTable] Added face id=256 remote=udp4://
>> 224.0.23.170:56363 local=udp4://10.0.0.37:56363
>> 1431664563.053394 INFO: [EthernetFace] [id=-1,local=
>> dev://wlan0,remote=ether://[01:00:5e:00:17:aa]] Creating face on
>> wlan0/60:36:dd:a8:11:73
>> 1431664563.081330 INFO: [FaceTable] Added face id=257 remote=
>> ether://[01:00:5e:00:17:aa] local=dev://wlan0
>> 1431664563.090395 INFO: [EthernetFace] [id=-1,local=
>> dev://eth0,remote=ether://[01:00:5e:00:17:aa]] Creating face on
>> eth0/e0:db:55:d6:eb:e3
>> 1431664563.105145 INFO: [FaceTable] Added face id=258 remote=
>> ether://[01:00:5e:00:17:aa] local=dev://eth0
>> 1431664563.115727 INFO: [CommandValidator] Giving privilege "faces" to
>> identity /localhost/daemons/nfd/ksk-1430084088432
>> 1431664563.116162 INFO: [CommandValidator] Giving privilege "fib" to
>> identity /localhost/daemons/nfd/ksk-1430084088432
>> 1431664563.116575 INFO: [CommandValidator] Giving privilege
>> "strategy-choice" to identity /localhost/daemons/nfd/ksk-1430084088432
>> 1431664563.116942 WARNING: [CommandValidator] Wildcard identity is
>> intended for demo purpose only and SHOULD NOT be used in production
>> environment
>> 1431664563.117065 INFO: [CommandValidator] Giving privilege "faces" to
>> identity wildcard
>> 1431664563.117297 INFO: [CommandValidator] Giving privilege
>> "strategy-choice" to identity wildcard
>> 1431664563.117670 INFO: [FaceTable] Added face id=255 remote=null://
>> local=null://
>> 1431664563.122135 INFO: [FaceTable] Added face id=254
>> remote=contentstore:// local=contentstore://
>> 1431664563.124781 INFO: [PrivilegeHelper] dropped to effective uid=116
>> gid=126
>> 1431664563.127378 INFO: [UnixStreamFace] [id=-1,local=
>> unix:///run/nfd.sock,remote=fd://25] Creating face
>> 1431664563.127473 INFO: [FaceTable] Added face id=259 remote=fd://25
>> local=unix:///run/nfd.sock
>> 1431664563.127904 FATAL: [NFD] FileStore: error opening file for reading:
>> /home/anilj1/.ndn/ndnsec-tpm-file/%JAmVmylSjFZutfeCI1dUvGgM+kOffJmUp3kLgktBVQ=.pri
>>
>>  I also tried after changing the grp and owner of the /home/anilj1/.ndn
>> to 'root' but yet it did not help. Is something missing here?
>>
>>  One thing I am not sure when the .ndn folder is created? Is it created
>> first time by the nfd process after it is started? What if I remove this
>> folder before I start nfd locally?
>>
>>  Also is it possible to run nfd from a local user and not with sudo
>> proviledges?
>>
>>  /anil.
>>
>>    _______________________________________________
>> 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/20150514/f552d3fd/attachment.html>

From anilj.mailing at gmail.com  Thu May 14 22:29:07 2015
From: anilj.mailing at gmail.com (Anil Jangam)
Date: Thu, 14 May 2015 22:29:07 -0700
Subject: [Nfd-dev] Starting NFD locally from compiled sources.
In-Reply-To: <CAHVD1iav0_sfz8EGQLz1c1qQQF-U5K-8P6XcTMCSQ0uUXfOxMw@mail.gmail.com>
References: <CAHVD1iacY=5G7Up1_L0GsXOPLyCUKYr1qe-3o7BZvCg2=ydv6g@mail.gmail.com>
	<5DE0044E-A508-48D1-8F6B-827C94059487@memphis.edu>
	<CAHVD1iYD265TPjpSo70hGJkYjamSEgzTY-C-RBuHOPZvko3dmw@mail.gmail.com>
	<7849D8D0-C275-4257-B92E-D36D155CF3E0@memphis.edu>
	<CAHVD1iav0_sfz8EGQLz1c1qQQF-U5K-8P6XcTMCSQ0uUXfOxMw@mail.gmail.com>
Message-ID: <CAHVD1iY6p48pUTjp0DMrH0QE_s=jFD_-t3bsAKeFqC5pKA57yw@mail.gmail.com>

Or is it the case that nfd-start internally starts the nfd as superuser
(sudo), and it is expecting the group and ownership accordingly. All the
files under /home/anilj1/.ndn belongs to different user and group than
root.

/anil.

On Thu, May 14, 2015 at 10:26 PM, Anil Jangam <anilj.mailing at gmail.com>
wrote:

> Well, just to be sure, I gave 777 as follows..
>
> anilj1 at insp5521:~/sandbox/NFD$ ls -Rl /home/anilj1/.ndn
> /home/anilj1/.ndn:
> total 32
> -rwxrwxrwx 1 anilj1 anilj1   985 May 14 22:22 client.conf
> -rwxrwxrwx 1 anilj1 anilj1 18432 May  5 00:17 ndnsec-public-info.db
> drwxrwxrwx 2 anilj1 anilj1  4096 May  5 00:17 ndnsec-tpm-file
>
> /home/anilj1/.ndn/ndnsec-tpm-file:
> total 20
> -rwxrwxrwx 1 anilj1 anilj1 1643 Apr 26 12:35
> %JAmVmylSjFZutfeCI1dUvGgM+kOffJmUp3kLgktBVQ=.pri
> -rwxrwxrwx 1 anilj1 anilj1  398 Apr 26 12:35
> %JAmVmylSjFZutfeCI1dUvGgM+kOffJmUp3kLgktBVQ=.pub
> -rwxrwxrwx 1 anilj1 anilj1  208 May  5 00:17 mapping.txt
> -rwxrwxrwx 1 anilj1 anilj1 1643 May  5 00:17
> rkDt+b7SPQxsx4yL3t%bB4fou2FT1DzhKcpYWfe6Hwo=.pri
> -rwxrwxrwx 1 anilj1 anilj1  398 May  5 00:17
> rkDt+b7SPQxsx4yL3t%bB4fou2FT1DzhKcpYWfe6Hwo=.pub
>
>
> But still the same error.
>
> 1431667575.326153 INFO: [RemoteRegistrator] Load remote_register section
> in rib section
> 1431667575.326258 INFO: [RibManager] Listening on: /localhost/nfd/rib
> 1431667575.334410 INFO: [RibManager] Start monitoring face create/destroy
> events
> 1431667575.345949 FATAL: [NFD] Error in setting interest filter
> (/localhost/nfd/rib): Unauthorized command
>
>
> /anil.
>
>
>
> On Thu, May 14, 2015 at 10:13 PM, Lan Wang (lanwang) <lanwang at memphis.edu>
> wrote:
>
>>  What about adding w permission to the user and r permission to group and
>> other?
>>
>> Lan
>>
>>  On May 15, 2015, at 12:10 AM, Anil Jangam <anilj.mailing at gmail.com>
>>  wrote:
>>
>>  Hi Prof Wang,
>>
>>  Ok.. it was: -r-------- 1 anilj1 anilj1 1643 Apr 26 12:35
>> %JAmVmylSjFZutfeCI1dUvGgM+kOffJmUp3kLgktBVQ=.pri
>>
>>  After added READ permissions to all, it is now throwing following
>> errorr.
>>
>>  1431666355.351034 INFO: [RemoteRegistrator] Load remote_register
>> section in rib section
>> 1431666355.351254 INFO: [RemoteRegistrator] Load remote_register section
>> in rib section
>> 1431666355.351316 INFO: [RibManager] Listening on: /localhost/nfd/rib
>> 1431666355.358148 INFO: [RibManager] Start monitoring face create/destroy
>> events
>> 1431666355.370436 FATAL: [NFD] Error in setting interest filter
>> (/localhost/nfd/rib): Unauthorized command
>>
>>  Ideally, I am trying to run the 'nfd' in debug mode, either from
>> Eclipse or from command line gdb, to do a step wise execution. I want to
>> understand certain part of the code. Any pointers for this case will help.
>>
>>  /anil.
>>
>>
>> On Thu, May 14, 2015 at 9:57 PM, Lan Wang (lanwang) <lanwang at memphis.edu>
>> wrote:
>>
>>> What are the permissions of the .ndn directory and the files in it?
>>>
>>> Lan
>>>
>>>  On May 14, 2015, at 11:45 PM, Anil Jangam <anilj.mailing at gmail.com>
>>>  wrote:
>>>
>>>   Hi,
>>>
>>>  I am attempting to run 'nfd' from compiled binary. However, I am
>>> running into a following problem. (see the last line).
>>>
>>>  sudo ./build/bin/nfd --config ./ndn_conf/nfd.conf
>>> 1431664563.044290 INFO: [StrategyChoice] setDefaultStrategy
>>> /localhost/nfd/strategy/best-route/%FD%03
>>> 1431664563.044910 INFO: [InternalFace] registering callback for
>>> /localhost/nfd/fib
>>> 1431664563.045027 INFO: [InternalFace] registering callback for
>>> /localhost/nfd/faces
>>> 1431664563.045111 INFO: [InternalFace] registering callback for
>>> /localhost/nfd/strategy-choice
>>> 1431664563.045207 INFO: [InternalFace] registering callback for
>>> /localhost/nfd/status
>>> 1431664563.045289 INFO: [FaceTable] Added face id=1 remote=internal://
>>> local=internal://
>>> 1431664563.049813 INFO: [CommandValidator] Giving privilege "faces" to
>>> identity /localhost/daemons/nfd/ksk-1430084088432
>>> 1431664563.049861 INFO: [CommandValidator] Giving privilege "fib" to
>>> identity /localhost/daemons/nfd/ksk-1430084088432
>>> 1431664563.049886 INFO: [CommandValidator] Giving privilege
>>> "strategy-choice" to identity /localhost/daemons/nfd/ksk-1430084088432
>>> 1431664563.049917 WARNING: [CommandValidator] Wildcard identity is
>>> intended for demo purpose only and SHOULD NOT be used in production
>>> environment
>>> 1431664563.049943 INFO: [CommandValidator] Giving privilege "faces" to
>>> identity wildcard
>>> 1431664563.049969 INFO: [CommandValidator] Giving privilege
>>> "strategy-choice" to identity wildcard
>>> 1431664563.050159 INFO: [TablesConfigSection] Setting CS max packets to
>>> 65536
>>> 1431664563.050738 INFO: [MulticastUdpFace] [id=-1,local=udp4://
>>> 10.0.0.37:56363,remote=udp4://224.0.23.170:56363] Creating face
>>> 1431664563.050818 INFO: [FaceTable] Added face id=256 remote=udp4://
>>> 224.0.23.170:56363 local=udp4://10.0.0.37:56363
>>> 1431664563.053394 INFO: [EthernetFace] [id=-1,local=
>>> dev://wlan0,remote=ether://[01:00:5e:00:17:aa]] Creating face on
>>> wlan0/60:36:dd:a8:11:73
>>> 1431664563.081330 INFO: [FaceTable] Added face id=257 remote=
>>> ether://[01:00:5e:00:17:aa] local=dev://wlan0
>>> 1431664563.090395 INFO: [EthernetFace] [id=-1,local=
>>> dev://eth0,remote=ether://[01:00:5e:00:17:aa]] Creating face on
>>> eth0/e0:db:55:d6:eb:e3
>>> 1431664563.105145 INFO: [FaceTable] Added face id=258 remote=
>>> ether://[01:00:5e:00:17:aa] local=dev://eth0
>>> 1431664563.115727 INFO: [CommandValidator] Giving privilege "faces" to
>>> identity /localhost/daemons/nfd/ksk-1430084088432
>>> 1431664563.116162 INFO: [CommandValidator] Giving privilege "fib" to
>>> identity /localhost/daemons/nfd/ksk-1430084088432
>>> 1431664563.116575 INFO: [CommandValidator] Giving privilege
>>> "strategy-choice" to identity /localhost/daemons/nfd/ksk-1430084088432
>>> 1431664563.116942 WARNING: [CommandValidator] Wildcard identity is
>>> intended for demo purpose only and SHOULD NOT be used in production
>>> environment
>>> 1431664563.117065 INFO: [CommandValidator] Giving privilege "faces" to
>>> identity wildcard
>>> 1431664563.117297 INFO: [CommandValidator] Giving privilege
>>> "strategy-choice" to identity wildcard
>>> 1431664563.117670 INFO: [FaceTable] Added face id=255 remote=null://
>>> local=null://
>>> 1431664563.122135 INFO: [FaceTable] Added face id=254
>>> remote=contentstore:// local=contentstore://
>>> 1431664563.124781 INFO: [PrivilegeHelper] dropped to effective uid=116
>>> gid=126
>>> 1431664563.127378 INFO: [UnixStreamFace] [id=-1,local=
>>> unix:///run/nfd.sock,remote=fd://25] Creating face
>>> 1431664563.127473 INFO: [FaceTable] Added face id=259 remote=fd://25
>>> local=unix:///run/nfd.sock
>>> 1431664563.127904 FATAL: [NFD] FileStore: error opening file for
>>> reading:
>>> /home/anilj1/.ndn/ndnsec-tpm-file/%JAmVmylSjFZutfeCI1dUvGgM+kOffJmUp3kLgktBVQ=.pri
>>>
>>>  I also tried after changing the grp and owner of the /home/anilj1/.ndn
>>> to 'root' but yet it did not help. Is something missing here?
>>>
>>>  One thing I am not sure when the .ndn folder is created? Is it created
>>> first time by the nfd process after it is started? What if I remove this
>>> folder before I start nfd locally?
>>>
>>>  Also is it possible to run nfd from a local user and not with sudo
>>> proviledges?
>>>
>>>  /anil.
>>>
>>>    _______________________________________________
>>> 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/20150514/979a2fb2/attachment.html>

From anilj.mailing at gmail.com  Thu May 14 22:31:25 2015
From: anilj.mailing at gmail.com (Anil Jangam)
Date: Thu, 14 May 2015 22:31:25 -0700
Subject: [Nfd-dev] Querying pending Interest in PIT.
In-Reply-To: <CAOFH+OYF+o19JFMNCLnXS9C38xRQU_tiFc5nYt0Y8qzhyFSsKQ@mail.gmail.com>
References: <CAHVD1iaSrO6zg=O9wGYYnX9GNSW09VdOzo3MEZcr9dSdpyUrJA@mail.gmail.com>
	<CAOFH+Oaw4eEcAptUf_AnZcVYfY5BYp96M+0rW2ZVWC8UXVzbLw@mail.gmail.com>
	<CAHVD1ibOe4m7x1mExHt3H5xYFota7WS_aUEV3069mfkqGqjsKQ@mail.gmail.com>
	<CAOFH+OZmY0JHmDBzOLs7zOW0XuN5pVR2U0qq05MRoj6remniOA@mail.gmail.com>
	<CAHVD1iYOa6Agv9SwXAg31PY=rge2j4FcBqiK1BeLXYpN6fv47w@mail.gmail.com>
	<CAOFH+OYF+o19JFMNCLnXS9C38xRQU_tiFc5nYt0Y8qzhyFSsKQ@mail.gmail.com>
Message-ID: <CAHVD1iYxifXQX0Qv1Tj0OBDSytSVTnFFAS=RcYXVOnDWzuaOzg@mail.gmail.com>

Hello Junxiao,

I think it is not always necessary (or possible) that content location is
already known. I am sure there are such situations (e.g. mobility). I agree
with you that if the location is already known, it should be installed into
the RIB (that's the most obvious action for sure), but it is applicable for
the new incoming Interest traffic which eventually becomes pending. I am
trying to address the already pending ones. I hope I am more clear.

For now, lets assume that application is aware of where the content is.
Question is: how can it query PIT for pending interests and guide them to
the correct source?

/anil.


On Wed, May 13, 2015 at 8:20 PM, Junxiao Shi <shijunxiao at email.arizona.edu>
wrote:

> Hi Anil
>
> Suppose your program is informed of a specific pending Interest, how does
> the program know where to guide the Interest?
> If the location is already known, it should be installed into the RIB.
>
> Yours, Junxiao
>
> On Wed, May 13, 2015 at 8:15 PM, Anil Jangam <anilj.mailing at gmail.com>
> wrote:
>
>> Ok, I would say it is a monitoring scenario. I am trying to write an
>> application, where it checks for specific pending interests in a router,
>> and guide it to fetch it from the location which application might already
>> know of. This is very rough thought as of now. But the bottom line is that
>> I need to find out the pending interests on router and corresponding
>> content names.
>>
>> Hope this is helps.
>>
>> /anil.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150514/78caea02/attachment.html>

From dibenede at cs.colostate.edu  Fri May 15 05:47:42 2015
From: dibenede at cs.colostate.edu (Steve DiBenedetto)
Date: Fri, 15 May 2015 06:47:42 -0600
Subject: [Nfd-dev] Starting NFD locally from compiled sources.
In-Reply-To: <CAHVD1iY6p48pUTjp0DMrH0QE_s=jFD_-t3bsAKeFqC5pKA57yw@mail.gmail.com>
References: <CAHVD1iacY=5G7Up1_L0GsXOPLyCUKYr1qe-3o7BZvCg2=ydv6g@mail.gmail.com>
	<5DE0044E-A508-48D1-8F6B-827C94059487@memphis.edu>
	<CAHVD1iYD265TPjpSo70hGJkYjamSEgzTY-C-RBuHOPZvko3dmw@mail.gmail.com>
	<7849D8D0-C275-4257-B92E-D36D155CF3E0@memphis.edu>
	<CAHVD1iav0_sfz8EGQLz1c1qQQF-U5K-8P6XcTMCSQ0uUXfOxMw@mail.gmail.com>
	<CAHVD1iY6p48pUTjp0DMrH0QE_s=jFD_-t3bsAKeFqC5pKA57yw@mail.gmail.com>
Message-ID: <CAG95NwvLBM=YwLOWfWYMen-VvhythNkUZXH686o=KL-hLTNpyg@mail.gmail.com>

>From your original message, it looks like you're trying to run NFD with a
custom configuration file. Could you please post it? I'm wondering if
there's a problem with the security/authorization settings.

On Thu, May 14, 2015 at 11:29 PM, Anil Jangam <anilj.mailing at gmail.com>
wrote:

> Or is it the case that nfd-start internally starts the nfd as superuser
> (sudo), and it is expecting the group and ownership accordingly. All the
> files under /home/anilj1/.ndn belongs to different user and group than
> root.
>
> /anil.
>
> On Thu, May 14, 2015 at 10:26 PM, Anil Jangam <anilj.mailing at gmail.com>
> wrote:
>
>> Well, just to be sure, I gave 777 as follows..
>>
>> anilj1 at insp5521:~/sandbox/NFD$ ls -Rl /home/anilj1/.ndn
>> /home/anilj1/.ndn:
>> total 32
>> -rwxrwxrwx 1 anilj1 anilj1   985 May 14 22:22 client.conf
>> -rwxrwxrwx 1 anilj1 anilj1 18432 May  5 00:17 ndnsec-public-info.db
>> drwxrwxrwx 2 anilj1 anilj1  4096 May  5 00:17 ndnsec-tpm-file
>>
>> /home/anilj1/.ndn/ndnsec-tpm-file:
>> total 20
>> -rwxrwxrwx 1 anilj1 anilj1 1643 Apr 26 12:35
>> %JAmVmylSjFZutfeCI1dUvGgM+kOffJmUp3kLgktBVQ=.pri
>> -rwxrwxrwx 1 anilj1 anilj1  398 Apr 26 12:35
>> %JAmVmylSjFZutfeCI1dUvGgM+kOffJmUp3kLgktBVQ=.pub
>> -rwxrwxrwx 1 anilj1 anilj1  208 May  5 00:17 mapping.txt
>> -rwxrwxrwx 1 anilj1 anilj1 1643 May  5 00:17
>> rkDt+b7SPQxsx4yL3t%bB4fou2FT1DzhKcpYWfe6Hwo=.pri
>> -rwxrwxrwx 1 anilj1 anilj1  398 May  5 00:17
>> rkDt+b7SPQxsx4yL3t%bB4fou2FT1DzhKcpYWfe6Hwo=.pub
>>
>>
>> But still the same error.
>>
>> 1431667575.326153 INFO: [RemoteRegistrator] Load remote_register section
>> in rib section
>> 1431667575.326258 INFO: [RibManager] Listening on: /localhost/nfd/rib
>> 1431667575.334410 INFO: [RibManager] Start monitoring face create/destroy
>> events
>> 1431667575.345949 FATAL: [NFD] Error in setting interest filter
>> (/localhost/nfd/rib): Unauthorized command
>>
>>
>> /anil.
>>
>>
>>
>> On Thu, May 14, 2015 at 10:13 PM, Lan Wang (lanwang) <lanwang at memphis.edu
>> > wrote:
>>
>>>  What about adding w permission to the user and r permission to group
>>> and other?
>>>
>>> Lan
>>>
>>>  On May 15, 2015, at 12:10 AM, Anil Jangam <anilj.mailing at gmail.com>
>>>  wrote:
>>>
>>>  Hi Prof Wang,
>>>
>>>  Ok.. it was: -r-------- 1 anilj1 anilj1 1643 Apr 26 12:35
>>> %JAmVmylSjFZutfeCI1dUvGgM+kOffJmUp3kLgktBVQ=.pri
>>>
>>>  After added READ permissions to all, it is now throwing following
>>> errorr.
>>>
>>>  1431666355.351034 INFO: [RemoteRegistrator] Load remote_register
>>> section in rib section
>>> 1431666355.351254 INFO: [RemoteRegistrator] Load remote_register section
>>> in rib section
>>> 1431666355.351316 INFO: [RibManager] Listening on: /localhost/nfd/rib
>>> 1431666355.358148 INFO: [RibManager] Start monitoring face
>>> create/destroy events
>>> 1431666355.370436 FATAL: [NFD] Error in setting interest filter
>>> (/localhost/nfd/rib): Unauthorized command
>>>
>>>  Ideally, I am trying to run the 'nfd' in debug mode, either from
>>> Eclipse or from command line gdb, to do a step wise execution. I want to
>>> understand certain part of the code. Any pointers for this case will help.
>>>
>>>  /anil.
>>>
>>>
>>> On Thu, May 14, 2015 at 9:57 PM, Lan Wang (lanwang) <lanwang at memphis.edu
>>> > wrote:
>>>
>>>> What are the permissions of the .ndn directory and the files in it?
>>>>
>>>> Lan
>>>>
>>>>  On May 14, 2015, at 11:45 PM, Anil Jangam <anilj.mailing at gmail.com>
>>>>  wrote:
>>>>
>>>>   Hi,
>>>>
>>>>  I am attempting to run 'nfd' from compiled binary. However, I am
>>>> running into a following problem. (see the last line).
>>>>
>>>>  sudo ./build/bin/nfd --config ./ndn_conf/nfd.conf
>>>> 1431664563.044290 INFO: [StrategyChoice] setDefaultStrategy
>>>> /localhost/nfd/strategy/best-route/%FD%03
>>>> 1431664563.044910 INFO: [InternalFace] registering callback for
>>>> /localhost/nfd/fib
>>>> 1431664563.045027 INFO: [InternalFace] registering callback for
>>>> /localhost/nfd/faces
>>>> 1431664563.045111 INFO: [InternalFace] registering callback for
>>>> /localhost/nfd/strategy-choice
>>>> 1431664563.045207 INFO: [InternalFace] registering callback for
>>>> /localhost/nfd/status
>>>> 1431664563.045289 INFO: [FaceTable] Added face id=1 remote=internal://
>>>> local=internal://
>>>> 1431664563.049813 INFO: [CommandValidator] Giving privilege "faces" to
>>>> identity /localhost/daemons/nfd/ksk-1430084088432
>>>> 1431664563.049861 INFO: [CommandValidator] Giving privilege "fib" to
>>>> identity /localhost/daemons/nfd/ksk-1430084088432
>>>> 1431664563.049886 INFO: [CommandValidator] Giving privilege
>>>> "strategy-choice" to identity /localhost/daemons/nfd/ksk-1430084088432
>>>> 1431664563.049917 WARNING: [CommandValidator] Wildcard identity is
>>>> intended for demo purpose only and SHOULD NOT be used in production
>>>> environment
>>>> 1431664563.049943 INFO: [CommandValidator] Giving privilege "faces" to
>>>> identity wildcard
>>>> 1431664563.049969 INFO: [CommandValidator] Giving privilege
>>>> "strategy-choice" to identity wildcard
>>>> 1431664563.050159 INFO: [TablesConfigSection] Setting CS max packets to
>>>> 65536
>>>> 1431664563.050738 INFO: [MulticastUdpFace] [id=-1,local=udp4://
>>>> 10.0.0.37:56363,remote=udp4://224.0.23.170:56363] Creating face
>>>> 1431664563.050818 INFO: [FaceTable] Added face id=256 remote=udp4://
>>>> 224.0.23.170:56363 local=udp4://10.0.0.37:56363
>>>> 1431664563.053394 INFO: [EthernetFace] [id=-1,local=
>>>> dev://wlan0,remote=ether://[01:00:5e:00:17:aa]] Creating face on
>>>> wlan0/60:36:dd:a8:11:73
>>>> 1431664563.081330 INFO: [FaceTable] Added face id=257 remote=
>>>> ether://[01:00:5e:00:17:aa] local=dev://wlan0
>>>> 1431664563.090395 INFO: [EthernetFace] [id=-1,local=
>>>> dev://eth0,remote=ether://[01:00:5e:00:17:aa]] Creating face on
>>>> eth0/e0:db:55:d6:eb:e3
>>>> 1431664563.105145 INFO: [FaceTable] Added face id=258 remote=
>>>> ether://[01:00:5e:00:17:aa] local=dev://eth0
>>>> 1431664563.115727 INFO: [CommandValidator] Giving privilege "faces" to
>>>> identity /localhost/daemons/nfd/ksk-1430084088432
>>>> 1431664563.116162 INFO: [CommandValidator] Giving privilege "fib" to
>>>> identity /localhost/daemons/nfd/ksk-1430084088432
>>>> 1431664563.116575 INFO: [CommandValidator] Giving privilege
>>>> "strategy-choice" to identity /localhost/daemons/nfd/ksk-1430084088432
>>>> 1431664563.116942 WARNING: [CommandValidator] Wildcard identity is
>>>> intended for demo purpose only and SHOULD NOT be used in production
>>>> environment
>>>> 1431664563.117065 INFO: [CommandValidator] Giving privilege "faces" to
>>>> identity wildcard
>>>> 1431664563.117297 INFO: [CommandValidator] Giving privilege
>>>> "strategy-choice" to identity wildcard
>>>> 1431664563.117670 INFO: [FaceTable] Added face id=255 remote=null://
>>>> local=null://
>>>> 1431664563.122135 INFO: [FaceTable] Added face id=254
>>>> remote=contentstore:// local=contentstore://
>>>> 1431664563.124781 INFO: [PrivilegeHelper] dropped to effective uid=116
>>>> gid=126
>>>> 1431664563.127378 INFO: [UnixStreamFace] [id=-1,local=
>>>> unix:///run/nfd.sock,remote=fd://25] Creating face
>>>> 1431664563.127473 INFO: [FaceTable] Added face id=259 remote=fd://25
>>>> local=unix:///run/nfd.sock
>>>> 1431664563.127904 FATAL: [NFD] FileStore: error opening file for
>>>> reading:
>>>> /home/anilj1/.ndn/ndnsec-tpm-file/%JAmVmylSjFZutfeCI1dUvGgM+kOffJmUp3kLgktBVQ=.pri
>>>>
>>>>  I also tried after changing the grp and owner of
>>>> the /home/anilj1/.ndn to 'root' but yet it did not help. Is something
>>>> missing here?
>>>>
>>>>  One thing I am not sure when the .ndn folder is created? Is it
>>>> created first time by the nfd process after it is started? What if I remove
>>>> this folder before I start nfd locally?
>>>>
>>>>  Also is it possible to run nfd from a local user and not with sudo
>>>> proviledges?
>>>>
>>>>  /anil.
>>>>
>>>>    _______________________________________________
>>>> 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/20150515/f3e1a9da/attachment.html>

From joaopapereira at gmail.com  Fri May 15 06:31:31 2015
From: joaopapereira at gmail.com (Joao Pereira)
Date: Fri, 15 May 2015 13:31:31 +0000
Subject: [Nfd-dev] New arrival
In-Reply-To: <8CF0CBFB-48ED-4EDB-ABE2-50A8E3195122@ucla.edu>
References: <CAAq25NSNyS+LuphXCCR055ebHNtkQ7SDTeha2j3tAJYtWjtruA@mail.gmail.com>
	<8CF0CBFB-48ED-4EDB-ABE2-50A8E3195122@ucla.edu>
Message-ID: <CAAq25NTmGYMVVaV7Qab1eux9Qe_Yv7wTWJn80dHy=Jr-nVfpKA@mail.gmail.com>

Hello,
I am a C++, Python developer and prefer core part of the applications. I
saw there are a couple of open issue in NFD and maybe I can contribute to
it.
What I wanted to know is if you have any kind of process for solving
problems, or if I can just look into one bug and push a commit to gerrit to
solve it. Is there any rule in terms of messages in the commits, in order
to identify the problem?
Is there any order to solve the issues, maybe using the roadmap?

BR

On Thu, 14 May 2015 at 17:29 Alex Afanasyev <alexander.afanasyev at ucla.edu>
wrote:

> Hi Joao,
>
> Thanks for your interest!  Yes, all of our projects highly welcome all
> community contributions.
>
> For most of the software, we are using redmine (
> http://redmine.named-data.net/) to initiate and track feature requests
> and bug reports, as well to discuss particular issues and design choices.
> The code itself can be submitted to our code review system (and everybody
> welcome to participate in the code review process itself) to our gerrit
> system (http://gerrit.named-data.net).  All the agreed upon code is then
> merged and replicated in a few different places, including our github
> repository (https://github.com/named-data).
>
> Are you interested in some specific project?
>
> ?
> Alex
>
> On May 14, 2015, at 2:21 PM, Joao Pereira <joaopapereira at gmail.com> wrote:
>
> Hello,
> Been reading around the website about the project and it got me
> interested. Would like to know if it is open to community contributions or
> not. If it is open if you have specific WoW defined in order to contribute.
>
> Best Regards
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150515/1a06ebcb/attachment.html>

From anilj.mailing at gmail.com  Fri May 15 07:21:25 2015
From: anilj.mailing at gmail.com (Anil Jangam)
Date: Fri, 15 May 2015 07:21:25 -0700
Subject: [Nfd-dev] Starting NFD locally from compiled sources.
In-Reply-To: <CAG95NwvLBM=YwLOWfWYMen-VvhythNkUZXH686o=KL-hLTNpyg@mail.gmail.com>
References: <CAHVD1iacY=5G7Up1_L0GsXOPLyCUKYr1qe-3o7BZvCg2=ydv6g@mail.gmail.com>
	<5DE0044E-A508-48D1-8F6B-827C94059487@memphis.edu>
	<CAHVD1iYD265TPjpSo70hGJkYjamSEgzTY-C-RBuHOPZvko3dmw@mail.gmail.com>
	<7849D8D0-C275-4257-B92E-D36D155CF3E0@memphis.edu>
	<CAHVD1iav0_sfz8EGQLz1c1qQQF-U5K-8P6XcTMCSQ0uUXfOxMw@mail.gmail.com>
	<CAHVD1iY6p48pUTjp0DMrH0QE_s=jFD_-t3bsAKeFqC5pKA57yw@mail.gmail.com>
	<CAG95NwvLBM=YwLOWfWYMen-VvhythNkUZXH686o=KL-hLTNpyg@mail.gmail.com>
Message-ID: <CAHVD1iZa4oCQ7DR2_mbWcGOAM=u0BXFNPOWOBEMw51ZXDDP0Gg@mail.gmail.com>

Attached it here Steve.

Its the same one I get which is available when you installed nfd from
precompiled binary (sudo apt-get install nfd). So when I compile nfd from
sources, its the latest code, and I am not sure which version precompiled
binary is. Does configuration different between the two?

My next step is to run the nfd in debug mode. Can you please also suggest
steps for the same? Preferably debug nfd in Eclipse.

/anil.


On Fri, May 15, 2015 at 5:47 AM, Steve DiBenedetto <
dibenede at cs.colostate.edu> wrote:

> From your original message, it looks like you're trying to run NFD with a
> custom configuration file. Could you please post it? I'm wondering if
> there's a problem with the security/authorization settings.
>
> On Thu, May 14, 2015 at 11:29 PM, Anil Jangam <anilj.mailing at gmail.com>
> wrote:
>
>> Or is it the case that nfd-start internally starts the nfd as superuser
>> (sudo), and it is expecting the group and ownership accordingly. All the
>> files under /home/anilj1/.ndn belongs to different user and group than
>> root.
>>
>> /anil.
>>
>> On Thu, May 14, 2015 at 10:26 PM, Anil Jangam <anilj.mailing at gmail.com>
>> wrote:
>>
>>> Well, just to be sure, I gave 777 as follows..
>>>
>>> anilj1 at insp5521:~/sandbox/NFD$ ls -Rl /home/anilj1/.ndn
>>> /home/anilj1/.ndn:
>>> total 32
>>> -rwxrwxrwx 1 anilj1 anilj1   985 May 14 22:22 client.conf
>>> -rwxrwxrwx 1 anilj1 anilj1 18432 May  5 00:17 ndnsec-public-info.db
>>> drwxrwxrwx 2 anilj1 anilj1  4096 May  5 00:17 ndnsec-tpm-file
>>>
>>> /home/anilj1/.ndn/ndnsec-tpm-file:
>>> total 20
>>> -rwxrwxrwx 1 anilj1 anilj1 1643 Apr 26 12:35
>>> %JAmVmylSjFZutfeCI1dUvGgM+kOffJmUp3kLgktBVQ=.pri
>>> -rwxrwxrwx 1 anilj1 anilj1  398 Apr 26 12:35
>>> %JAmVmylSjFZutfeCI1dUvGgM+kOffJmUp3kLgktBVQ=.pub
>>> -rwxrwxrwx 1 anilj1 anilj1  208 May  5 00:17 mapping.txt
>>> -rwxrwxrwx 1 anilj1 anilj1 1643 May  5 00:17
>>> rkDt+b7SPQxsx4yL3t%bB4fou2FT1DzhKcpYWfe6Hwo=.pri
>>> -rwxrwxrwx 1 anilj1 anilj1  398 May  5 00:17
>>> rkDt+b7SPQxsx4yL3t%bB4fou2FT1DzhKcpYWfe6Hwo=.pub
>>>
>>>
>>> But still the same error.
>>>
>>> 1431667575.326153 INFO: [RemoteRegistrator] Load remote_register section
>>> in rib section
>>> 1431667575.326258 INFO: [RibManager] Listening on: /localhost/nfd/rib
>>> 1431667575.334410 INFO: [RibManager] Start monitoring face
>>> create/destroy events
>>> 1431667575.345949 FATAL: [NFD] Error in setting interest filter
>>> (/localhost/nfd/rib): Unauthorized command
>>>
>>>
>>> /anil.
>>>
>>>
>>>
>>> On Thu, May 14, 2015 at 10:13 PM, Lan Wang (lanwang) <
>>> lanwang at memphis.edu> wrote:
>>>
>>>>  What about adding w permission to the user and r permission to group
>>>> and other?
>>>>
>>>> Lan
>>>>
>>>>  On May 15, 2015, at 12:10 AM, Anil Jangam <anilj.mailing at gmail.com>
>>>>  wrote:
>>>>
>>>>  Hi Prof Wang,
>>>>
>>>>  Ok.. it was: -r-------- 1 anilj1 anilj1 1643 Apr 26 12:35
>>>> %JAmVmylSjFZutfeCI1dUvGgM+kOffJmUp3kLgktBVQ=.pri
>>>>
>>>>  After added READ permissions to all, it is now throwing following
>>>> errorr.
>>>>
>>>>  1431666355.351034 INFO: [RemoteRegistrator] Load remote_register
>>>> section in rib section
>>>> 1431666355.351254 INFO: [RemoteRegistrator] Load remote_register
>>>> section in rib section
>>>> 1431666355.351316 INFO: [RibManager] Listening on: /localhost/nfd/rib
>>>> 1431666355.358148 INFO: [RibManager] Start monitoring face
>>>> create/destroy events
>>>> 1431666355.370436 FATAL: [NFD] Error in setting interest filter
>>>> (/localhost/nfd/rib): Unauthorized command
>>>>
>>>>  Ideally, I am trying to run the 'nfd' in debug mode, either from
>>>> Eclipse or from command line gdb, to do a step wise execution. I want to
>>>> understand certain part of the code. Any pointers for this case will help.
>>>>
>>>>  /anil.
>>>>
>>>>
>>>> On Thu, May 14, 2015 at 9:57 PM, Lan Wang (lanwang) <
>>>> lanwang at memphis.edu> wrote:
>>>>
>>>>> What are the permissions of the .ndn directory and the files in it?
>>>>>
>>>>> Lan
>>>>>
>>>>>  On May 14, 2015, at 11:45 PM, Anil Jangam <anilj.mailing at gmail.com>
>>>>>  wrote:
>>>>>
>>>>>   Hi,
>>>>>
>>>>>  I am attempting to run 'nfd' from compiled binary. However, I am
>>>>> running into a following problem. (see the last line).
>>>>>
>>>>>  sudo ./build/bin/nfd --config ./ndn_conf/nfd.conf
>>>>> 1431664563.044290 INFO: [StrategyChoice] setDefaultStrategy
>>>>> /localhost/nfd/strategy/best-route/%FD%03
>>>>> 1431664563.044910 INFO: [InternalFace] registering callback for
>>>>> /localhost/nfd/fib
>>>>> 1431664563.045027 INFO: [InternalFace] registering callback for
>>>>> /localhost/nfd/faces
>>>>> 1431664563.045111 INFO: [InternalFace] registering callback for
>>>>> /localhost/nfd/strategy-choice
>>>>> 1431664563.045207 INFO: [InternalFace] registering callback for
>>>>> /localhost/nfd/status
>>>>> 1431664563.045289 INFO: [FaceTable] Added face id=1 remote=internal://
>>>>> local=internal://
>>>>> 1431664563.049813 INFO: [CommandValidator] Giving privilege "faces" to
>>>>> identity /localhost/daemons/nfd/ksk-1430084088432
>>>>> 1431664563.049861 INFO: [CommandValidator] Giving privilege "fib" to
>>>>> identity /localhost/daemons/nfd/ksk-1430084088432
>>>>> 1431664563.049886 INFO: [CommandValidator] Giving privilege
>>>>> "strategy-choice" to identity /localhost/daemons/nfd/ksk-1430084088432
>>>>> 1431664563.049917 WARNING: [CommandValidator] Wildcard identity is
>>>>> intended for demo purpose only and SHOULD NOT be used in production
>>>>> environment
>>>>> 1431664563.049943 INFO: [CommandValidator] Giving privilege "faces" to
>>>>> identity wildcard
>>>>> 1431664563.049969 INFO: [CommandValidator] Giving privilege
>>>>> "strategy-choice" to identity wildcard
>>>>> 1431664563.050159 INFO: [TablesConfigSection] Setting CS max packets
>>>>> to 65536
>>>>> 1431664563.050738 INFO: [MulticastUdpFace] [id=-1,local=udp4://
>>>>> 10.0.0.37:56363,remote=udp4://224.0.23.170:56363] Creating face
>>>>> 1431664563.050818 INFO: [FaceTable] Added face id=256 remote=udp4://
>>>>> 224.0.23.170:56363 local=udp4://10.0.0.37:56363
>>>>> 1431664563.053394 INFO: [EthernetFace] [id=-1,local=
>>>>> dev://wlan0,remote=ether://[01:00:5e:00:17:aa]] Creating face on
>>>>> wlan0/60:36:dd:a8:11:73
>>>>> 1431664563.081330 INFO: [FaceTable] Added face id=257 remote=
>>>>> ether://[01:00:5e:00:17:aa] local=dev://wlan0
>>>>> 1431664563.090395 INFO: [EthernetFace] [id=-1,local=
>>>>> dev://eth0,remote=ether://[01:00:5e:00:17:aa]] Creating face on
>>>>> eth0/e0:db:55:d6:eb:e3
>>>>> 1431664563.105145 INFO: [FaceTable] Added face id=258 remote=
>>>>> ether://[01:00:5e:00:17:aa] local=dev://eth0
>>>>> 1431664563.115727 INFO: [CommandValidator] Giving privilege "faces" to
>>>>> identity /localhost/daemons/nfd/ksk-1430084088432
>>>>> 1431664563.116162 INFO: [CommandValidator] Giving privilege "fib" to
>>>>> identity /localhost/daemons/nfd/ksk-1430084088432
>>>>> 1431664563.116575 INFO: [CommandValidator] Giving privilege
>>>>> "strategy-choice" to identity /localhost/daemons/nfd/ksk-1430084088432
>>>>> 1431664563.116942 WARNING: [CommandValidator] Wildcard identity is
>>>>> intended for demo purpose only and SHOULD NOT be used in production
>>>>> environment
>>>>> 1431664563.117065 INFO: [CommandValidator] Giving privilege "faces" to
>>>>> identity wildcard
>>>>> 1431664563.117297 INFO: [CommandValidator] Giving privilege
>>>>> "strategy-choice" to identity wildcard
>>>>> 1431664563.117670 INFO: [FaceTable] Added face id=255 remote=null://
>>>>> local=null://
>>>>> 1431664563.122135 INFO: [FaceTable] Added face id=254
>>>>> remote=contentstore:// local=contentstore://
>>>>> 1431664563.124781 INFO: [PrivilegeHelper] dropped to effective uid=116
>>>>> gid=126
>>>>> 1431664563.127378 INFO: [UnixStreamFace] [id=-1,local=
>>>>> unix:///run/nfd.sock,remote=fd://25] Creating face
>>>>> 1431664563.127473 INFO: [FaceTable] Added face id=259 remote=fd://25
>>>>> local=unix:///run/nfd.sock
>>>>> 1431664563.127904 FATAL: [NFD] FileStore: error opening file for
>>>>> reading:
>>>>> /home/anilj1/.ndn/ndnsec-tpm-file/%JAmVmylSjFZutfeCI1dUvGgM+kOffJmUp3kLgktBVQ=.pri
>>>>>
>>>>>  I also tried after changing the grp and owner of
>>>>> the /home/anilj1/.ndn to 'root' but yet it did not help. Is something
>>>>> missing here?
>>>>>
>>>>>  One thing I am not sure when the .ndn folder is created? Is it
>>>>> created first time by the nfd process after it is started? What if I remove
>>>>> this folder before I start nfd locally?
>>>>>
>>>>>  Also is it possible to run nfd from a local user and not with sudo
>>>>> proviledges?
>>>>>
>>>>>  /anil.
>>>>>
>>>>>    _______________________________________________
>>>>> 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/20150515/ac32f305/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nfd.conf
Type: application/octet-stream
Size: 7423 bytes
Desc: not available
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150515/ac32f305/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: client.conf
Type: application/octet-stream
Size: 985 bytes
Desc: not available
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150515/ac32f305/attachment-0001.obj>

From dibenede at cs.colostate.edu  Fri May 15 08:41:37 2015
From: dibenede at cs.colostate.edu (Steve DiBenedetto)
Date: Fri, 15 May 2015 09:41:37 -0600
Subject: [Nfd-dev] Starting NFD locally from compiled sources.
In-Reply-To: <CAHVD1iZa4oCQ7DR2_mbWcGOAM=u0BXFNPOWOBEMw51ZXDDP0Gg@mail.gmail.com>
References: <CAHVD1iacY=5G7Up1_L0GsXOPLyCUKYr1qe-3o7BZvCg2=ydv6g@mail.gmail.com>
	<5DE0044E-A508-48D1-8F6B-827C94059487@memphis.edu>
	<CAHVD1iYD265TPjpSo70hGJkYjamSEgzTY-C-RBuHOPZvko3dmw@mail.gmail.com>
	<7849D8D0-C275-4257-B92E-D36D155CF3E0@memphis.edu>
	<CAHVD1iav0_sfz8EGQLz1c1qQQF-U5K-8P6XcTMCSQ0uUXfOxMw@mail.gmail.com>
	<CAHVD1iY6p48pUTjp0DMrH0QE_s=jFD_-t3bsAKeFqC5pKA57yw@mail.gmail.com>
	<CAG95NwvLBM=YwLOWfWYMen-VvhythNkUZXH686o=KL-hLTNpyg@mail.gmail.com>
	<CAHVD1iZa4oCQ7DR2_mbWcGOAM=u0BXFNPOWOBEMw51ZXDDP0Gg@mail.gmail.com>
Message-ID: <CAG95NwsV4XCde=TrbetHnVzk9n6v3O5ZwaQZDmWwB8kgTczaWQ@mail.gmail.com>

On Fri, May 15, 2015 at 8:21 AM, Anil Jangam <anilj.mailing at gmail.com>
wrote:

> Attached it here Steve.
>
> Its the same one I get which is available when you installed nfd from
> precompiled binary (sudo apt-get install nfd). So when I compile nfd from
> sources, its the latest code, and I am not sure which version precompiled
> binary is. Does configuration different between the two?
>

They are. Specifically, the binary release's config expects the some
pre-authorized certificates to live /etc/ndn/certs (this is specified in in
the nfd.conf with a relative path).

I think I can reproduce your original directory permissions problem: fresh
install with the NFD 0.3.2 ubuntu package seems to create the ~/.ndn
directory as belonging to root. The package's nfd.conf tells NFD to drop
permissions at runtime to the "ndn" user and group. This then blows up with
your original error when you try to start NFD. However, if you change the
config file to specify "root" as the user and group (or just comment out
the entire general section), it should get past that problem.

I'm less certain about your second problem: "Error in setting interest
filter (/localhost/nfd/rib): Unauthorized command". That's coming from the
rib management portion that I'm less familiar with.


> My next step is to run the nfd in debug mode. Can you please also suggest
> steps for the same? Preferably debug nfd in Eclipse.
>

You're using CDT, correct?

>From your original question, it should be possible to run NFD without
root/sudo. You need to make a few changes to your config files:

nfd.conf:
1. change the default unix socket path to something you have access to
(e.g. /tmp/nfd.sock)
2. comment out the entire "ether" subsection
3. comment out the entire general section (there's no need to drop
permissions anymore)

client.conf:
1. update unix socket path to whatever you did in #1 of nfd.conf


> /anil.
>
>
> On Fri, May 15, 2015 at 5:47 AM, Steve DiBenedetto <
> dibenede at cs.colostate.edu> wrote:
>
>> From your original message, it looks like you're trying to run NFD with a
>> custom configuration file. Could you please post it? I'm wondering if
>> there's a problem with the security/authorization settings.
>>
>> On Thu, May 14, 2015 at 11:29 PM, Anil Jangam <anilj.mailing at gmail.com>
>> wrote:
>>
>>> Or is it the case that nfd-start internally starts the nfd as superuser
>>> (sudo), and it is expecting the group and ownership accordingly. All the
>>> files under /home/anilj1/.ndn belongs to different user and group than
>>> root.
>>>
>>> /anil.
>>>
>>> On Thu, May 14, 2015 at 10:26 PM, Anil Jangam <anilj.mailing at gmail.com>
>>> wrote:
>>>
>>>> Well, just to be sure, I gave 777 as follows..
>>>>
>>>> anilj1 at insp5521:~/sandbox/NFD$ ls -Rl /home/anilj1/.ndn
>>>> /home/anilj1/.ndn:
>>>> total 32
>>>> -rwxrwxrwx 1 anilj1 anilj1   985 May 14 22:22 client.conf
>>>> -rwxrwxrwx 1 anilj1 anilj1 18432 May  5 00:17 ndnsec-public-info.db
>>>> drwxrwxrwx 2 anilj1 anilj1  4096 May  5 00:17 ndnsec-tpm-file
>>>>
>>>> /home/anilj1/.ndn/ndnsec-tpm-file:
>>>> total 20
>>>> -rwxrwxrwx 1 anilj1 anilj1 1643 Apr 26 12:35
>>>> %JAmVmylSjFZutfeCI1dUvGgM+kOffJmUp3kLgktBVQ=.pri
>>>> -rwxrwxrwx 1 anilj1 anilj1  398 Apr 26 12:35
>>>> %JAmVmylSjFZutfeCI1dUvGgM+kOffJmUp3kLgktBVQ=.pub
>>>> -rwxrwxrwx 1 anilj1 anilj1  208 May  5 00:17 mapping.txt
>>>> -rwxrwxrwx 1 anilj1 anilj1 1643 May  5 00:17
>>>> rkDt+b7SPQxsx4yL3t%bB4fou2FT1DzhKcpYWfe6Hwo=.pri
>>>> -rwxrwxrwx 1 anilj1 anilj1  398 May  5 00:17
>>>> rkDt+b7SPQxsx4yL3t%bB4fou2FT1DzhKcpYWfe6Hwo=.pub
>>>>
>>>>
>>>> But still the same error.
>>>>
>>>> 1431667575.326153 INFO: [RemoteRegistrator] Load remote_register
>>>> section in rib section
>>>> 1431667575.326258 INFO: [RibManager] Listening on: /localhost/nfd/rib
>>>> 1431667575.334410 INFO: [RibManager] Start monitoring face
>>>> create/destroy events
>>>> 1431667575.345949 FATAL: [NFD] Error in setting interest filter
>>>> (/localhost/nfd/rib): Unauthorized command
>>>>
>>>>
>>>> /anil.
>>>>
>>>>
>>>>
>>>> On Thu, May 14, 2015 at 10:13 PM, Lan Wang (lanwang) <
>>>> lanwang at memphis.edu> wrote:
>>>>
>>>>>  What about adding w permission to the user and r permission to group
>>>>> and other?
>>>>>
>>>>> Lan
>>>>>
>>>>>  On May 15, 2015, at 12:10 AM, Anil Jangam <anilj.mailing at gmail.com>
>>>>>  wrote:
>>>>>
>>>>>  Hi Prof Wang,
>>>>>
>>>>>  Ok.. it was: -r-------- 1 anilj1 anilj1 1643 Apr 26 12:35
>>>>> %JAmVmylSjFZutfeCI1dUvGgM+kOffJmUp3kLgktBVQ=.pri
>>>>>
>>>>>  After added READ permissions to all, it is now throwing following
>>>>> errorr.
>>>>>
>>>>>  1431666355.351034 INFO: [RemoteRegistrator] Load remote_register
>>>>> section in rib section
>>>>> 1431666355.351254 INFO: [RemoteRegistrator] Load remote_register
>>>>> section in rib section
>>>>> 1431666355.351316 INFO: [RibManager] Listening on: /localhost/nfd/rib
>>>>> 1431666355.358148 INFO: [RibManager] Start monitoring face
>>>>> create/destroy events
>>>>> 1431666355.370436 FATAL: [NFD] Error in setting interest filter
>>>>> (/localhost/nfd/rib): Unauthorized command
>>>>>
>>>>>  Ideally, I am trying to run the 'nfd' in debug mode, either from
>>>>> Eclipse or from command line gdb, to do a step wise execution. I want to
>>>>> understand certain part of the code. Any pointers for this case will help.
>>>>>
>>>>>  /anil.
>>>>>
>>>>>
>>>>> On Thu, May 14, 2015 at 9:57 PM, Lan Wang (lanwang) <
>>>>> lanwang at memphis.edu> wrote:
>>>>>
>>>>>> What are the permissions of the .ndn directory and the files in it?
>>>>>>
>>>>>> Lan
>>>>>>
>>>>>>  On May 14, 2015, at 11:45 PM, Anil Jangam <anilj.mailing at gmail.com>
>>>>>>  wrote:
>>>>>>
>>>>>>   Hi,
>>>>>>
>>>>>>  I am attempting to run 'nfd' from compiled binary. However, I am
>>>>>> running into a following problem. (see the last line).
>>>>>>
>>>>>>  sudo ./build/bin/nfd --config ./ndn_conf/nfd.conf
>>>>>> 1431664563.044290 INFO: [StrategyChoice] setDefaultStrategy
>>>>>> /localhost/nfd/strategy/best-route/%FD%03
>>>>>> 1431664563.044910 INFO: [InternalFace] registering callback for
>>>>>> /localhost/nfd/fib
>>>>>> 1431664563.045027 INFO: [InternalFace] registering callback for
>>>>>> /localhost/nfd/faces
>>>>>> 1431664563.045111 INFO: [InternalFace] registering callback for
>>>>>> /localhost/nfd/strategy-choice
>>>>>> 1431664563.045207 INFO: [InternalFace] registering callback for
>>>>>> /localhost/nfd/status
>>>>>> 1431664563.045289 INFO: [FaceTable] Added face id=1
>>>>>> remote=internal:// local=internal://
>>>>>> 1431664563.049813 INFO: [CommandValidator] Giving privilege "faces"
>>>>>> to identity /localhost/daemons/nfd/ksk-1430084088432
>>>>>> 1431664563.049861 INFO: [CommandValidator] Giving privilege "fib" to
>>>>>> identity /localhost/daemons/nfd/ksk-1430084088432
>>>>>> 1431664563.049886 INFO: [CommandValidator] Giving privilege
>>>>>> "strategy-choice" to identity /localhost/daemons/nfd/ksk-1430084088432
>>>>>> 1431664563.049917 WARNING: [CommandValidator] Wildcard identity is
>>>>>> intended for demo purpose only and SHOULD NOT be used in production
>>>>>> environment
>>>>>> 1431664563.049943 INFO: [CommandValidator] Giving privilege "faces"
>>>>>> to identity wildcard
>>>>>> 1431664563.049969 INFO: [CommandValidator] Giving privilege
>>>>>> "strategy-choice" to identity wildcard
>>>>>> 1431664563.050159 INFO: [TablesConfigSection] Setting CS max packets
>>>>>> to 65536
>>>>>> 1431664563.050738 INFO: [MulticastUdpFace] [id=-1,local=udp4://
>>>>>> 10.0.0.37:56363,remote=udp4://224.0.23.170:56363] Creating face
>>>>>> 1431664563.050818 INFO: [FaceTable] Added face id=256 remote=udp4://
>>>>>> 224.0.23.170:56363 local=udp4://10.0.0.37:56363
>>>>>> 1431664563.053394 INFO: [EthernetFace] [id=-1,local=
>>>>>> dev://wlan0,remote=ether://[01:00:5e:00:17:aa]] Creating face on
>>>>>> wlan0/60:36:dd:a8:11:73
>>>>>> 1431664563.081330 INFO: [FaceTable] Added face id=257 remote=
>>>>>> ether://[01:00:5e:00:17:aa] local=dev://wlan0
>>>>>> 1431664563.090395 INFO: [EthernetFace] [id=-1,local=
>>>>>> dev://eth0,remote=ether://[01:00:5e:00:17:aa]] Creating face on
>>>>>> eth0/e0:db:55:d6:eb:e3
>>>>>> 1431664563.105145 INFO: [FaceTable] Added face id=258 remote=
>>>>>> ether://[01:00:5e:00:17:aa] local=dev://eth0
>>>>>> 1431664563.115727 INFO: [CommandValidator] Giving privilege "faces"
>>>>>> to identity /localhost/daemons/nfd/ksk-1430084088432
>>>>>> 1431664563.116162 INFO: [CommandValidator] Giving privilege "fib" to
>>>>>> identity /localhost/daemons/nfd/ksk-1430084088432
>>>>>> 1431664563.116575 INFO: [CommandValidator] Giving privilege
>>>>>> "strategy-choice" to identity /localhost/daemons/nfd/ksk-1430084088432
>>>>>> 1431664563.116942 WARNING: [CommandValidator] Wildcard identity is
>>>>>> intended for demo purpose only and SHOULD NOT be used in production
>>>>>> environment
>>>>>> 1431664563.117065 INFO: [CommandValidator] Giving privilege "faces"
>>>>>> to identity wildcard
>>>>>> 1431664563.117297 INFO: [CommandValidator] Giving privilege
>>>>>> "strategy-choice" to identity wildcard
>>>>>> 1431664563.117670 INFO: [FaceTable] Added face id=255 remote=null://
>>>>>> local=null://
>>>>>> 1431664563.122135 INFO: [FaceTable] Added face id=254
>>>>>> remote=contentstore:// local=contentstore://
>>>>>> 1431664563.124781 INFO: [PrivilegeHelper] dropped to effective
>>>>>> uid=116 gid=126
>>>>>> 1431664563.127378 INFO: [UnixStreamFace] [id=-1,local=
>>>>>> unix:///run/nfd.sock,remote=fd://25] Creating face
>>>>>> 1431664563.127473 INFO: [FaceTable] Added face id=259 remote=fd://25
>>>>>> local=unix:///run/nfd.sock
>>>>>> 1431664563.127904 FATAL: [NFD] FileStore: error opening file for
>>>>>> reading:
>>>>>> /home/anilj1/.ndn/ndnsec-tpm-file/%JAmVmylSjFZutfeCI1dUvGgM+kOffJmUp3kLgktBVQ=.pri
>>>>>>
>>>>>>  I also tried after changing the grp and owner of
>>>>>> the /home/anilj1/.ndn to 'root' but yet it did not help. Is something
>>>>>> missing here?
>>>>>>
>>>>>>  One thing I am not sure when the .ndn folder is created? Is it
>>>>>> created first time by the nfd process after it is started? What if I remove
>>>>>> this folder before I start nfd locally?
>>>>>>
>>>>>>  Also is it possible to run nfd from a local user and not with sudo
>>>>>> proviledges?
>>>>>>
>>>>>>  /anil.
>>>>>>
>>>>>>    _______________________________________________
>>>>>> 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/20150515/bf095caf/attachment.html>

From shijunxiao at email.arizona.edu  Fri May 15 08:48:39 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Fri, 15 May 2015 08:48:39 -0700
Subject: [Nfd-dev] Querying pending Interest in PIT.
In-Reply-To: <CAHVD1iYxifXQX0Qv1Tj0OBDSytSVTnFFAS=RcYXVOnDWzuaOzg@mail.gmail.com>
References: <CAHVD1iaSrO6zg=O9wGYYnX9GNSW09VdOzo3MEZcr9dSdpyUrJA@mail.gmail.com>
	<CAOFH+Oaw4eEcAptUf_AnZcVYfY5BYp96M+0rW2ZVWC8UXVzbLw@mail.gmail.com>
	<CAHVD1ibOe4m7x1mExHt3H5xYFota7WS_aUEV3069mfkqGqjsKQ@mail.gmail.com>
	<CAOFH+OZmY0JHmDBzOLs7zOW0XuN5pVR2U0qq05MRoj6remniOA@mail.gmail.com>
	<CAHVD1iYOa6Agv9SwXAg31PY=rge2j4FcBqiK1BeLXYpN6fv47w@mail.gmail.com>
	<CAOFH+OYF+o19JFMNCLnXS9C38xRQU_tiFc5nYt0Y8qzhyFSsKQ@mail.gmail.com>
	<CAHVD1iYxifXQX0Qv1Tj0OBDSytSVTnFFAS=RcYXVOnDWzuaOzg@mail.gmail.com>
Message-ID: <CAOFH+OY6t4zdVkGxFp08dzsBjhUKcKayJNiWzdbsf4R92gbM-Q@mail.gmail.com>

Hi Anil

In ccnd 0.7.2, when a new route is installed, forwarding checks pending PIT
entries covered by this route, and attempts to forward them again.
I didn't do this in NFD forwarding pipelines, because I feel it
unnecessary: the consumer is responsible for retransmissions.
It's expensive (in terms of performance) to enumerate the PIT.

Your program should install the route into the RIB.
When consumer retransmits the Interest, the strategy will take the new
route into consideration.

Yours, Junxiao

On Thu, May 14, 2015 at 10:31 PM, Anil Jangam <anilj.mailing at gmail.com>
wrote:

> Hello Junxiao,
>
> I think it is not always necessary (or possible) that content location is
> already known. I am sure there are such situations (e.g. mobility). I agree
> with you that if the location is already known, it should be installed into
> the RIB (that's the most obvious action for sure), but it is applicable for
> the new incoming Interest traffic which eventually becomes pending. I am
> trying to address the already pending ones. I hope I am more clear.
>
> For now, lets assume that application is aware of where the content is.
> Question is: how can it query PIT for pending interests and guide them to
> the correct source?
>
> /anil.
>
>
> On Wed, May 13, 2015 at 8:20 PM, Junxiao Shi <shijunxiao at email.arizona.edu
> > wrote:
>
>> Hi Anil
>>
>> Suppose your program is informed of a specific pending Interest, how does
>> the program know where to guide the Interest?
>> If the location is already known, it should be installed into the RIB.
>>
>> Yours, Junxiao
>>
>> On Wed, May 13, 2015 at 8:15 PM, Anil Jangam <anilj.mailing at gmail.com>
>> wrote:
>>
>>> Ok, I would say it is a monitoring scenario. I am trying to write an
>>> application, where it checks for specific pending interests in a router,
>>> and guide it to fetch it from the location which application might already
>>> know of. This is very rough thought as of now. But the bottom line is that
>>> I need to find out the pending interests on router and corresponding
>>> content names.
>>>
>>> Hope this is helps.
>>>
>>> /anil.
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150515/805997c0/attachment.html>

From shijunxiao at email.arizona.edu  Fri May 15 08:53:43 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Fri, 15 May 2015 08:53:43 -0700
Subject: [Nfd-dev] New arrival
In-Reply-To: <CAAq25NTmGYMVVaV7Qab1eux9Qe_Yv7wTWJn80dHy=Jr-nVfpKA@mail.gmail.com>
References: <CAAq25NSNyS+LuphXCCR055ebHNtkQ7SDTeha2j3tAJYtWjtruA@mail.gmail.com>
	<8CF0CBFB-48ED-4EDB-ABE2-50A8E3195122@ucla.edu>
	<CAAq25NTmGYMVVaV7Qab1eux9Qe_Yv7wTWJn80dHy=Jr-nVfpKA@mail.gmail.com>
Message-ID: <CAOFH+Ob_n8eKeO_2Rw1x66M2VCkMUtR3pF1+uAct2SfwMfwxmQ@mail.gmail.com>

Hi Joao


   1. create a Redmine account and a Gerrit account, contact one of the
   project owners (listed on Redmine project page) to add you as a developer
   2. assign the Redmine issue to yourself
   3. toggle Redmine issue status to "In Progress"
   4. work on the design, and post your design under the Redmine issue
   5. once the design is approved, start working on code
      - unit tests are required; coverage should be over 80%
      - for large and complex features, it's recommended to submit headers
      for review first, before doing implementation
      6. submit code to Gerrit, toggle Redmine issue status to "Code Review"
   7. wait for code review, and rework your code according to comments
   8. once the code is approved and merged, toggle Redmine issue status to
   "Closed"


Yours, Junxiao

On Fri, May 15, 2015 at 6:31 AM, Joao Pereira <joaopapereira at gmail.com>
wrote:

> Hello,
> I am a C++, Python developer and prefer core part of the applications. I
> saw there are a couple of open issue in NFD and maybe I can contribute to
> it.
> What I wanted to know is if you have any kind of process for solving
> problems, or if I can just look into one bug and push a commit to gerrit to
> solve it. Is there any rule in terms of messages in the commits, in order
> to identify the problem?
> Is there any order to solve the issues, maybe using the roadmap?
>
> BR
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150515/b6014fe7/attachment.html>

From lanwang at memphis.edu  Fri May 15 09:39:42 2015
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Fri, 15 May 2015 16:39:42 +0000
Subject: [Nfd-dev] RTT estimator
Message-ID: <32392B65-6940-4A20-A4D9-102C9387C558@memphis.edu>

Hi Junxiao,

We're implementing a forwarding strategy and using the RTT estimator you have in NFD.   While debugging some results, we looked at the RTO values computed by the RTT estimator.   It seems that the RTT estimator in NFD has several features that are different from the TCP retransmission timeout algorithm (https://tools.ietf.org/html/rfc6298).

1. you use the same multiplier (0.1) for SRTT and RTTVAR.  But in TCP, it's 0.125 for SRTT and 0.25 for RTTVAR.

2. you initialize the RTTVAR to be the same as the first RTT measurement.  But in TCP, it's initialized to 1/2 of the first RTT measurement.

I'm wondering why you made the above decisions.   Thanks.

Lan




From shijunxiao at email.arizona.edu  Fri May 15 11:23:21 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Fri, 15 May 2015 11:23:21 -0700
Subject: [Nfd-dev] RTT estimator
In-Reply-To: <32392B65-6940-4A20-A4D9-102C9387C558@memphis.edu>
References: <32392B65-6940-4A20-A4D9-102C9387C558@memphis.edu>
Message-ID: <CAOFH+Ob-nUO3=xKEApDivgHGtYJZXEyWS8sjVy7eGSAbtYd7zw@mail.gmail.com>

Hi Lan

NFD RttEstimator code is copied from NDNFD. This code is written according
to ns3::RttMeanDeviation.
I don't have particular reason for those differences from RFC6298.

Recent strategy design suggests that each strategy may need a different
RttEstimator.
Therefore, your strategy could duplicate RttEstimator and give it a
different name or make it a nested class, and then make changes.

Yours, Junxiao
On May 15, 2015 09:39, "Lan Wang (lanwang)" <lanwang at memphis.edu> wrote:

> Hi Junxiao,
>
> We're implementing a forwarding strategy and using the RTT estimator you
> have in NFD.   While debugging some results, we looked at the RTO values
> computed by the RTT estimator.   It seems that the RTT estimator in NFD has
> several features that are different from the TCP retransmission timeout
> algorithm (https://tools.ietf.org/html/rfc6298).
>
> 1. you use the same multiplier (0.1) for SRTT and RTTVAR.  But in TCP,
> it's 0.125 for SRTT and 0.25 for RTTVAR.
>
> 2. you initialize the RTTVAR to be the same as the first RTT measurement.
> But in TCP, it's initialized to 1/2 of the first RTT measurement.
>
> I'm wondering why you made the above decisions.   Thanks.
>
> Lan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150515/ee0068b8/attachment.html>

From lanwang at memphis.edu  Fri May 15 13:20:33 2015
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Fri, 15 May 2015 20:20:33 +0000
Subject: [Nfd-dev] RTT estimator
In-Reply-To: <CAOFH+Ob-nUO3=xKEApDivgHGtYJZXEyWS8sjVy7eGSAbtYd7zw@mail.gmail.com>
References: <32392B65-6940-4A20-A4D9-102C9387C558@memphis.edu>
	<CAOFH+Ob-nUO3=xKEApDivgHGtYJZXEyWS8sjVy7eGSAbtYd7zw@mail.gmail.com>
Message-ID: <952672D8-E53A-4E9A-B111-64145CB76949@memphis.edu>

I see.  We'll create a new RttEstimator based on TCP's algorithm.

Lan

On May 15, 2015, at 1:23 PM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>
 wrote:


Hi Lan

NFD RttEstimator code is copied from NDNFD. This code is written according to ns3::RttMeanDeviation.
I don't have particular reason for those differences from RFC6298.

Recent strategy design suggests that each strategy may need a different RttEstimator.
Therefore, your strategy could duplicate RttEstimator and give it a different name or make it a nested class, and then make changes.

Yours, Junxiao

On May 15, 2015 09:39, "Lan Wang (lanwang)" <lanwang at memphis.edu<mailto:lanwang at memphis.edu>> wrote:
Hi Junxiao,

We're implementing a forwarding strategy and using the RTT estimator you have in NFD.   While debugging some results, we looked at the RTO values computed by the RTT estimator.   It seems that the RTT estimator in NFD has several features that are different from the TCP retransmission timeout algorithm (https://tools.ietf.org/html/rfc6298).

1. you use the same multiplier (0.1) for SRTT and RTTVAR.  But in TCP, it's 0.125 for SRTT and 0.25 for RTTVAR.

2. you initialize the RTTVAR to be the same as the first RTT measurement.  But in TCP, it's initialized to 1/2 of the first RTT measurement.

I'm wondering why you made the above decisions.   Thanks.

Lan


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

From shijunxiao at email.arizona.edu  Mon May 18 09:13:52 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Mon, 18 May 2015 09:13:52 -0700
Subject: [Nfd-dev] RTT delay caused by RIB registration commands
In-Reply-To: <64330686-43E4-4F97-A343-50CD0E55D670@memphis.edu>
References: <2E7F0681-E8C1-49F6-BAEA-8A48F3B4B4E8@memphis.edu>
	<D10AB5AE-A329-49F3-A967-3CCF75C6B89F@memphis.edu>
	<CAOFH+ObVN985Ewms+c9v6azfEOjkb3JOY9mJayu0LTJCN20VGA@mail.gmail.com>
	<8DF5E537-B6CE-4B9E-BF73-EF826CC236AA@memphis.edu>
	<122E97D6-A2CF-4CBE-BD8A-CF82767241DA@memphis.edu>
	<CAOFH+Obrs1_bNOqZhJyboFUuPxn6pz2E79vSW-+LEz4kEFYizw@mail.gmail.com>
	<64330686-43E4-4F97-A343-50CD0E55D670@memphis.edu>
Message-ID: <CAOFH+OaYkt2LeQHj_j-hJa7cuQg+tqBQ2EjR=BwJoExuO-vusw@mail.gmail.com>

Hi Vince

I confirm your steps are correct.
This concludes the issue is caused by signing overhead, and can be solved
by #1705 for emulation environments.

Yours, Junxiao

On Tue, May 12, 2015 at 8:47 AM, Vince Lehman (vslehman) <
vslehman at memphis.edu> wrote:

>   This shows a correlation between signing algorithm and max RTT, but the
> variance is much larger compared to the logs from Apr 23.
> Are you using a different machine?
>
>
>  Yes, I should have been more clear. The results in the previous email are
> from our routing experiments where we originally encountered the problem.
>
>   How many CPU cores does this machine have? There shouldn't be much
> difference between 2 and 3 on a quad-core machine.
>
>
>  The machine has 4 cores. The difference between tests 2 and 3 are due to
> the change in the library which would also affect NLSR. When NLSR sends the
> RIB registration commands, they are also signed using signWithSha256.
>
>   Also, please confirm you have changed ".sign(" to ".signWithSha256(" in
> all these files for "NFD Management":
>
>    - NFD/core/segment-publisher.hpp (for answering face query;
>    unnecessary if nfdc is using a FaceId)
>    - NFD/core/notification-stream.hpp (for generating face status change
>    notifications)
>    - NFD/daemon/mgmt/manager-base.cpp (for answering commands)
>
>   Yes, I have modified each of these files for tests 2 and 3.
>
> --
>  Vince Lehman
>
>  On May 6, 2015, at 7:04 PM, Junxiao Shi <shijunxiao at email.arizona.edu>
> wrote:
>
>  Hi Vince
>
>  Summary from your logs:
>
>    1. NFD=RSA, ndn::nfd::Controller=RSA: min 7.098ms, max 52.041ms
>    2. NFD=SHA256, ndn::nfd::Controller=RSA: min 7.277ms, max 40.540ms
>    3. NFD=SHA256, ndn::nfd::Controller=SHA256: min 7.732ms, max 12.022ms
>
>  This shows a correlation between signing algorithm and max RTT, but the
> variance is much larger compared to the logs from Apr 23.
> Are you using a different machine?
> How many CPU cores does this machine have? There shouldn't be much
> difference between 2 and 3 on a quad-core machine.
>
>  Also, please confirm you have changed ".sign(" to ".signWithSha256(" in
> all these files for "NFD Management":
>
>    - NFD/core/segment-publisher.hpp (for answering face query;
>    unnecessary if nfdc is using a FaceId)
>    - NFD/core/notification-stream.hpp (for generating face status change
>    notifications)
>    - NFD/daemon/mgmt/manager-base.cpp (for answering commands)
>
>
>  Yours, Junxiao
>
> On Wed, May 6, 2015 at 4:04 PM, Vince Lehman (vslehman) <
> vslehman at memphis.edu> wrote:
>
>> At the NFD call today, it was suggested that I try our experiments with a
>> different, quicker signing method for NFD?s management modules.
>>
>>  I ran the following three tests:
>>
>>  1.) Unmodified NFD to get baseline results
>> 2.) NFD with management modules using KeyChain::signWithSha256 for
>> control responses
>> 3.) Test 2 + modified ndn::nfd::Controller in ndn-cxx so control commands
>> are signed using KeyChain::signWithSha256
>>
>>  The results I collected suggest that signing is largely the cause of
>> the RTT jumps.
>>
>>  1. ) Unchanged NFD using KeyChain::sign():
>>
>>  20150506T220013.546312 - Content From /ndn/edu/orange - Ping Reference
>> = 358723384   - Round Trip Time = 7.54174 ms
>> 20150506T220014.545910 - Content From /ndn/edu/orange - Ping Reference =
>> 358723385   - Round Trip Time = 7.35931 ms
>> 20150506T220015.549327 - Content From /ndn/edu/orange - Ping Reference =
>> 358723386   - Round Trip Time = 10.755 ms
>> 20150506T220016.569095 - Content From /ndn/edu/orange - Ping Reference =
>> 358723387   - Round Trip Time = 26.909 ms
>> 20150506T220017.554450 - Content From /ndn/edu/orange - Ping Reference =
>> 358723388   - Round Trip Time = 15.8414 ms
>> 20150506T220018.550272 - Content From /ndn/edu/orange - Ping Reference =
>> 358723389   - Round Trip Time = 11.7576 ms
>> 20150506T220019.594078 - Content From /ndn/edu/orange - Ping Reference =
>> 358723390   - Round Trip Time = 52.0413 ms
>> 20150506T220020.572899 - Content From /ndn/edu/orange - Ping Reference =
>> 358723391   - Round Trip Time = 31.8473 ms
>> 20150506T220021.568606 - Content From /ndn/edu/orange - Ping Reference =
>> 358723392   - Round Trip Time = 29.9206 ms
>> 20150506T220022.545620 - Content From /ndn/edu/orange - Ping Reference =
>> 358723393   - Round Trip Time = 7.09895 ms
>> 20150506T220023.551988 - Content From /ndn/edu/orange - Ping Reference =
>> 358723394   - Round Trip Time = 13.4654 ms
>> 20150506T220024.564711 - Content From /ndn/edu/orange - Ping Reference =
>> 358723395   - Round Trip Time = 26.1983 ms
>> 20150506T220025.590458 - Content From /ndn/edu/orange - Ping Reference =
>> 358723396   - Round Trip Time = 51.8421 ms
>> 20150506T220026.547079 - Content From /ndn/edu/orange - Ping Reference =
>> 358723397   - Round Trip Time = 8.38067 ms
>> 20150506T220027.546382 - Content From /ndn/edu/orange - Ping Reference =
>> 358723398   - Round Trip Time = 7.7887 ms
>>
>>  2.) NFD Management using KeyChain::signWithSha256() for control
>> responses:
>>
>>  20150506T220832.990110 - Content From /ndn/edu/orange - Ping Reference
>> = 481750786   - Round Trip Time = 8.12952 ms
>> 20150506T220833.989616 - Content From /ndn/edu/orange - Ping Reference =
>> 481750787   - Round Trip Time = 7.27718 ms
>> 20150506T220835.000043 - Content From /ndn/edu/orange - Ping Reference =
>> 481750788   - Round Trip Time = 17.7199 ms
>> 20150506T220835.997854 - Content From /ndn/edu/orange - Ping Reference =
>> 481750789   - Round Trip Time = 15.8593 ms
>> 20150506T220836.990831 - Content From /ndn/edu/orange - Ping Reference =
>> 481750790   - Round Trip Time = 8.84247 ms
>> 20150506T220838.011070 - Content From /ndn/edu/orange - Ping Reference =
>> 481750791   - Round Trip Time = 17.0122 ms
>> 20150506T220839.022594 - Content From /ndn/edu/orange - Ping Reference =
>> 481750792   - Round Trip Time = 40.5401 ms
>> 20150506T220839.996497 - Content From /ndn/edu/orange - Ping Reference =
>> 481750793   - Round Trip Time = 13.9247 ms
>> 20150506T220841.000317 - Content From /ndn/edu/orange - Ping Reference =
>> 481750794   - Round Trip Time = 18.0118 ms
>> 20150506T220841.990391 - Content From /ndn/edu/orange - Ping Reference =
>> 481750795   - Round Trip Time = 8.36782 ms
>> 20150506T220842.989631 - Content From /ndn/edu/orange - Ping Reference =
>> 481750796   - Round Trip Time = 7.57163 ms
>> 20150506T220843.990083 - Content From /ndn/edu/orange - Ping Reference =
>> 481750797   - Round Trip Time = 7.9309 ms
>>
>>  3.) NFD Management using KeyChain::signWithSha256() and
>> ndn::nfd::Controller::start() using KeyChain::signWithSha256:
>>
>>  20150506T224746.920419 - Content From /ndn/edu/orange - Ping Reference
>> = 432571709   - Round Trip Time = 7.74707 ms
>> 20150506T224747.920684 - Content From /ndn/edu/orange - Ping Reference =
>> 432571710   - Round Trip Time = 8.08427 ms
>> 20150506T224748.921073 - Content From /ndn/edu/orange - Ping Reference =
>> 432571711   - Round Trip Time = 7.95967 ms
>> 20150506T224749.920619 - Content From /ndn/edu/orange - Ping Reference =
>> 432571712   - Round Trip Time = 7.78507 ms
>> 20150506T224750.923189 - Content From /ndn/edu/orange - Ping Reference =
>> 432571713   - Round Trip Time = 10.5592 ms
>> 20150506T224751.920660 - Content From /ndn/edu/orange - Ping Reference =
>> 432571714   - Round Trip Time = 7.73255 ms
>> 20150506T224752.920939 - Content From /ndn/edu/orange - Ping Reference =
>> 432571715   - Round Trip Time = 8.24211 ms
>> 20150506T224753.923819 - Content From /ndn/edu/orange - Ping Reference =
>> 432571716   - Round Trip Time = 9.19251 ms
>> 20150506T224754.921798 - Content From /ndn/edu/orange - Ping Reference =
>> 432571717   - Round Trip Time = 8.94248 ms
>> 20150506T224755.924729 - Content From /ndn/edu/orange - Ping Reference =
>> 432571718   - Round Trip Time = 12.0222 ms
>> 20150506T224756.920302 - Content From /ndn/edu/orange - Ping Reference =
>> 432571719   - Round Trip Time = 7.75629 ms
>>
>>
>> --
>>  Vince Lehman
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150518/7b39992c/attachment.html>

From shijunxiao at email.arizona.edu  Mon May 25 21:23:14 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Mon, 25 May 2015 21:23:14 -0700
Subject: [Nfd-dev] review request: NDNLPv2 NACK, Fragmentation,
	LocalControlHeader
In-Reply-To: <CAOFH+OZu_AnJsVGQAJqLQVAZYARPyD7HNfa1qVv7rjx4wef8jw@mail.gmail.com>
References: <CAOFH+OY2_gHLAhY0ABatDRoheypp4ibVCnN-57MgAPDvKL7aUQ@mail.gmail.com>
	<CAOFH+OZu_AnJsVGQAJqLQVAZYARPyD7HNfa1qVv7rjx4wef8jw@mail.gmail.com>
Message-ID: <CAOFH+ObDXAyYd7FPkRnOAvJuRWJv=gGFxF0_jwZigqUEFZVdYg@mail.gmail.com>

Dear folks

I have written the protocol spec of first batch of features in NDNLPv2, and
I need someone to review the design.

http://redmine.named-data.net/projects/nfd/wiki/NDNLPv2

If you don't know what this is about, see #2520, #2763, and
http://redmine.named-data.net/attachments/download/301/NDNLPv2_20150417.pptx

I'll appreciate all review comments.
You don't have to be an expert in order to do a design review.

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

From christos at cs.colostate.edu  Tue May 26 05:00:31 2015
From: christos at cs.colostate.edu (Christos Papadopoulos)
Date: Tue, 26 May 2015 06:00:31 -0600
Subject: [Nfd-dev] review request: NDNLPv2 NACK, Fragmentation,
	LocalControlHeader
In-Reply-To: <CAOFH+ObDXAyYd7FPkRnOAvJuRWJv=gGFxF0_jwZigqUEFZVdYg@mail.gmail.com>
References: <CAOFH+OY2_gHLAhY0ABatDRoheypp4ibVCnN-57MgAPDvKL7aUQ@mail.gmail.com>	<CAOFH+OZu_AnJsVGQAJqLQVAZYARPyD7HNfa1qVv7rjx4wef8jw@mail.gmail.com>
	<CAOFH+ObDXAyYd7FPkRnOAvJuRWJv=gGFxF0_jwZigqUEFZVdYg@mail.gmail.com>
Message-ID: <5564605F.9000505@cs.colostate.edu>

Junxiao,

Thanks for the spec, it seems very nice.

I could not find much discussion in the spec about reliability. There 
was some discussion in the slides you linked, but I am not sure I have 
seen that discussion captured in the spec.

Can you say a bit about reliability? Maybe it's not there yet?

Christos.

On 05/25/2015 10:23 PM, Junxiao Shi wrote:
> Dear folks
>
> I have written the protocol spec of first batch of features in NDNLPv2,
> and I need someone to review the design.
>
> http://redmine.named-data.net/projects/nfd/wiki/NDNLPv2
>
> If you don't know what this is about, see #2520, #2763, and
> http://redmine.named-data.net/attachments/download/301/NDNLPv2_20150417.pptx
>
> I'll appreciate all review comments.
> You don't have to be an expert in order to do a design review.
>
> Yours, Junxiao
>
>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>



From shijunxiao at email.arizona.edu  Tue May 26 09:17:15 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Tue, 26 May 2015 09:17:15 -0700
Subject: [Nfd-dev] review request: NDNLPv2 NACK, Fragmentation,
	LocalControlHeader
Message-ID: <CAOFH+Obr-NUPcUQgTsexwCW8qDxMsV5buuwfBUL9A7HQimaROA@mail.gmail.com>

Hi Marc

The byte ranges [0:1400], [1400:2800], [2800:4200], [4200:5000] are correct.
Subscripts are to be interpreted in the same way as Python does.

In your suggested ranges, the last range [4200:5000] is Python notation,
but the other three ranges are inconsistent with the last.

Yours, Junxiao

On Tue, May 26, 2015 at 2:18 AM, <Marc.Mosko at parc.com> wrote:

>  In these examples, would the byte ranges not be [0:1399], [1400:2799],
> [2800:4199], [4200:5000]?
>
>  Marc
>
>  +-------------+-------------+    +-------------+-------------+
> | NDNLPv2     | Fragment    |    | NDNLPv2     | Fragment    |
> | seq=8801    |             |    | seq=8802    |             |
> | FragIndex=0 | [0:1400]    |    | FragIndex=1 | [1400:2800] |
> | FragCount=4 |             |    | FragCount=4 |             |
> +-------------+-------------+    +-------------+-------------+
>
> +-------------+-------------+    +-------------+-------------+
> | NDNLPv2     | Fragment    |    | NDNLPv2     | Fragment    |
> | seq=8803    |             |    | seq=8804    |             |
> | FragIndex=2 | [2800:4200] |    | FragIndex=3 | [4200:5000] |
> | FragCount=4 |             |    | FragCount=4 |             |
> +-------------+-------------+    +-------------+-------------+
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150526/afc544fe/attachment.html>

From shijunxiao at email.arizona.edu  Tue May 26 09:19:17 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Tue, 26 May 2015 09:19:17 -0700
Subject: [Nfd-dev] review request: NDNLPv2 NACK, Fragmentation,
	LocalControlHeader
In-Reply-To: <5564605F.9000505@cs.colostate.edu>
References: <CAOFH+OY2_gHLAhY0ABatDRoheypp4ibVCnN-57MgAPDvKL7aUQ@mail.gmail.com>
	<CAOFH+OZu_AnJsVGQAJqLQVAZYARPyD7HNfa1qVv7rjx4wef8jw@mail.gmail.com>
	<CAOFH+ObDXAyYd7FPkRnOAvJuRWJv=gGFxF0_jwZigqUEFZVdYg@mail.gmail.com>
	<5564605F.9000505@cs.colostate.edu>
Message-ID: <CAOFH+OZZSCs5sSOtGpNDtWBBo+DZ_YVJu2z2ods9zTB9LrH64Q@mail.gmail.com>

Hi Christos

The first batch of NDNLPv2 features are only those listed on #2763
<http://redmine.named-data.net/issues/2763>.
This list does not include reliability. Reliability feature is not yet
approved.

Yours, Junxiao

On Tue, May 26, 2015 at 5:00 AM, Christos Papadopoulos <
christos at cs.colostate.edu> wrote:

> Junxiao,
>
> Thanks for the spec, it seems very nice.
>
> I could not find much discussion in the spec about reliability. There was
> some discussion in the slides you linked, but I am not sure I have seen
> that discussion captured in the spec.
>
> Can you say a bit about reliability? Maybe it's not there yet?
>
> Christos.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150526/99d0baec/attachment.html>

From alexander.afanasyev at ucla.edu  Tue May 26 13:54:06 2015
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Tue, 26 May 2015 13:54:06 -0700
Subject: [Nfd-dev] Jenkins slave outage
Message-ID: <F3854702-7031-415A-BB71-34125420E497@ucla.edu>

Just to let you know.  Due to emergency server maintenance, some of the jenkins slaves hosted in UCLA (both OSX 10.8 and one OSX 10.9) are down.  They should return back to function later today or tomorrow.

?
Alex

-------------- 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/20150526/701e4938/attachment.bin>

From iliamo at CS.UCLA.EDU  Tue May 26 15:39:40 2015
From: iliamo at CS.UCLA.EDU (Ilya Moiseenko)
Date: Tue, 26 May 2015 15:39:40 -0700
Subject: [Nfd-dev] review request: NDNLPv2 NACK, Fragmentation,
	LocalControlHeader
In-Reply-To: <CAOFH+ObDXAyYd7FPkRnOAvJuRWJv=gGFxF0_jwZigqUEFZVdYg@mail.gmail.com>
References: <CAOFH+OY2_gHLAhY0ABatDRoheypp4ibVCnN-57MgAPDvKL7aUQ@mail.gmail.com>
	<CAOFH+OZu_AnJsVGQAJqLQVAZYARPyD7HNfa1qVv7rjx4wef8jw@mail.gmail.com>
	<CAOFH+ObDXAyYd7FPkRnOAvJuRWJv=gGFxF0_jwZigqUEFZVdYg@mail.gmail.com>
Message-ID: <2922057A-548B-4F4D-8636-9E9BB2BB6C0C@cs.ucla.edu>

Hi Junxiao,
I think that even the reliability is not yet approved you should rename it to ?partial reliability? throughout the spec, because I guess that you are not going to provide persistent retransmissions on the link layer.

Another thing is NACK. Ok, if I?m a server-side application getting lots of Interests that I cannot process, do I provide a GiveUpNack to my local NFD ? I expected something like a CongestionNACK. Or congestion goes to the reason field?

Final question, is there a way to make Interest NACK from the application today or in near future? It?s alright if NFD doesn?t understand it yet.

Ilya

On May 25, 2015, at 9:23 PM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:

> Dear folks
> 
> I have written the protocol spec of first batch of features in NDNLPv2, and I need someone to review the design.
> 
> http://redmine.named-data.net/projects/nfd/wiki/NDNLPv2
> 
> If you don't know what this is about, see #2520, #2763, and http://redmine.named-data.net/attachments/download/301/NDNLPv2_20150417.pptx
> 
> I'll appreciate all review comments.
> You don't have to be an expert in order to do a design review.
> 
> 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/20150526/d0f5c868/attachment.html>

From alexni1992 at gmail.com  Tue May 26 22:46:49 2015
From: alexni1992 at gmail.com (Alexander Ni)
Date: Wed, 27 May 2015 14:46:49 +0900
Subject: [Nfd-dev] Consumer and Producer trivial applications
Message-ID: <CAF7W2mm6PJSHZhOkHiQuPrnCtkAA0_y=kTvjeY09sjZjYhnvAw@mail.gmail.com>

Hello everyone,

  I studing NDN and we have some testbed machines on wich I install NFD and
ndn-cxx. I read some NFD and ndn-cxx documentation but not really
understand how to work with producer and consumer applications. Can
somebody explain me how to operate them or how to allocate
consumer/producer roles between machines.

Best Regards,
Alexander Ni
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150527/5ded62fe/attachment.html>

From shijunxiao at email.arizona.EDU  Wed May 27 04:56:26 2015
From: shijunxiao at email.arizona.EDU (Junxiao Shi)
Date: Wed, 27 May 2015 04:56:26 -0700
Subject: [Nfd-dev] review request: NDNLPv2 NACK, Fragmentation,
	LocalControlHeader
In-Reply-To: <2922057A-548B-4F4D-8636-9E9BB2BB6C0C@cs.ucla.edu>
References: <CAOFH+OY2_gHLAhY0ABatDRoheypp4ibVCnN-57MgAPDvKL7aUQ@mail.gmail.com>
	<CAOFH+OZu_AnJsVGQAJqLQVAZYARPyD7HNfa1qVv7rjx4wef8jw@mail.gmail.com>
	<CAOFH+ObDXAyYd7FPkRnOAvJuRWJv=gGFxF0_jwZigqUEFZVdYg@mail.gmail.com>
	<2922057A-548B-4F4D-8636-9E9BB2BB6C0C@cs.ucla.edu>
Message-ID: <CAOFH+OZa6Ov3w+gpWZXYmRVEjbMeYaBE7p=weeUcmDFK0F5Brg@mail.gmail.com>

Hi Ilya

The full name for "reliability" feature is "reliability improvement".
Since any NDNLPv2 feature is swappable, nothing prevents one to design a
reliability feature that can have guaranteed delivery (whether it's useful
is a different question).
"partial reliability" isn't correct.


CongestionNack is in the roadmap but not yet approved.


NDNLPv2 can be used on application-forwarder connection as well.
To send an Interest NACK from application, simply send a NDNLPv2 packet
with NdnlpNack header field.

Yours, Junxiao

On Tue, May 26, 2015 at 3:39 PM, Ilya Moiseenko <iliamo at cs.ucla.edu> wrote:

> Hi Junxiao,
> I think that even the reliability is not yet approved you should rename it
> to ?partial reliability? throughout the spec, because I guess that you are
> not going to provide persistent retransmissions on the link layer.
>
> Another thing is NACK. Ok, if I?m a server-side application getting lots
> of Interests that I cannot process, do I provide a GiveUpNack to my local
> NFD ? I expected something like a CongestionNACK. Or congestion goes to the
> reason field?
>
> Final question, is there a way to make Interest NACK from the application
> today or in near future? It?s alright if NFD doesn?t understand it yet.
>
> Ilya
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150527/921bbbec/attachment.html>

From jefft0 at remap.ucla.edu  Wed May 27 08:16:40 2015
From: jefft0 at remap.ucla.edu (Thompson, Jeff)
Date: Wed, 27 May 2015 15:16:40 +0000
Subject: [Nfd-dev] Consumer and Producer trivial applications
In-Reply-To: <CAF7W2mm6PJSHZhOkHiQuPrnCtkAA0_y=kTvjeY09sjZjYhnvAw@mail.gmail.com>
References: <CAF7W2mm6PJSHZhOkHiQuPrnCtkAA0_y=kTvjeY09sjZjYhnvAw@mail.gmail.com>
Message-ID: <D18B2D23.27A37%jefft0@remap.ucla.edu>

Hello Alexander,

What is your preferred development language? There are example client consumer and publisher applications in C++, Python, JavaScript and Java. For example, the sample applications  in Python which work with NFD are here:
https://github.com/named-data/PyNDN2/blob/master/examples/test_publish_async_nfd.py
https://github.com/named-data/PyNDN2/blob/master/examples/test_echo_consumer.py

- Jeff T

From: Alexander Ni <alexni1992 at gmail.com<mailto:alexni1992 at gmail.com>>
Date: Tuesday, May 26, 2015 at 22:46
To: nfd-dev <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: [Nfd-dev] Consumer and Producer trivial applications

Hello everyone,

  I studing NDN and we have some testbed machines on wich I install NFD and ndn-cxx. I read some NFD and ndn-cxx documentation but not really understand how to work with producer and consumer applications. Can somebody explain me how to operate them or how to allocate consumer/producer roles between machines.

Best Regards,
Alexander Ni

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

From klaus.schneider at uni-bamberg.de  Thu May 28 07:30:27 2015
From: klaus.schneider at uni-bamberg.de (Klaus Schneider)
Date: Thu, 28 May 2015 16:30:27 +0200
Subject: [Nfd-dev] review request: NDNLPv2 NACK, Fragmentation,
	LocalControlHeader
Message-ID: <55672683.5090709@uni-bamberg.de>

Hi Junxiao,

I hope it's not too late for my comments.

Most of the spec looks good to me. Here are just a few remarks/questions.


## Goals

I suppose that NDNLP will also work on wireless links? Maybe it's a good 
idea to add IEEE 802.11 (WiFi) to the list of examples.

## NDNLP Packet Format

Maybe you can elaborate on why a NDNLP packet with unknown fields must 
be dropped. What is the benefit against accepting the packet and 
ignoring the unknown field? Should the receiver send a notice to sender 
of the dropped packet (sth. like a NACK)?

## Network NACK

Maybe one can write out that NACK means "negative acknowledgment". It's 
probably obvious though.

## Local Cache Policy

Am I right to assume that the policy affects only the single data packet 
and not the other caching decisions (so CachingPolicy can't be set to 
LRU, LFU, etc.)? Maybe one can make that more explicit.

I am also unsure if the caching policy is about the cache decision 
policy (like cache/no cache), cache replacement policy or both. I assume 
it's the latter case, but I think it can't hurt to make it more explicit.

## Misc.

Regarding the "reliability improvement": Did you have a look at RFC 3366 
"Advice to link designers on link Automatic Repeat reQuest (ARQ)" 
(http://www.rfc-base.org/txt/rfc-3366.txt) ?

They differentiate between Perfectly-Persistent (Reliable), 
High-Persistence (Highly-Reliable) and Low-Persistence 
(Partially-Reliable) ARQ Protocols. Maybe you can use some ideas from 
that document. I think it's a great read.

I have appended a pdf file with a few orthographical suggestions. Please 
consider that I am not a native speaker and may be wrong about some of 
these.

I hope that helps.

Best regards,
Klaus



> Dear folks
>
> I have written the protocol spec of first batch of features in
> NDNLPv2, and I need someone to review the design.
>
> http://redmine.named-data.net/projects/nfd/wiki/NDNLPv2
>
> If you don't know what this is about, see #2520, #2763, and
> http://redmine.named-data.net/attachments/download/301/NDNLPv2_20150417.pptx
>
>  I'll appreciate all review comments. You don't have to be an expert
> in order to do a design review.
>
> Yours, Junxiao -------------- next part -------------- An HTML
> attachment was scrubbed... URL:
> <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150525/0c40e564/attachment-0001.html>

-- 
Klaus Schneider

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: NDNLPv2_Annotated.pdf
Type: application/pdf
Size: 121227 bytes
Desc: not available
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150528/05ddf208/attachment.pdf>

From christian.tschudin at unibas.ch  Thu May 28 07:33:56 2015
From: christian.tschudin at unibas.ch (christian.tschudin at unibas.ch)
Date: Thu, 28 May 2015 16:33:56 +0200 (CEST)
Subject: [Nfd-dev] review request: NDNLPv2 NACK, Fragmentation,
 LocalControlHeader
In-Reply-To: <CAOFH+ObDXAyYd7FPkRnOAvJuRWJv=gGFxF0_jwZigqUEFZVdYg@mail.gmail.com>
References: <CAOFH+OY2_gHLAhY0ABatDRoheypp4ibVCnN-57MgAPDvKL7aUQ@mail.gmail.com>
	<CAOFH+OZu_AnJsVGQAJqLQVAZYARPyD7HNfa1qVv7rjx4wef8jw@mail.gmail.com>
	<CAOFH+ObDXAyYd7FPkRnOAvJuRWJv=gGFxF0_jwZigqUEFZVdYg@mail.gmail.com>
Message-ID: <alpine.DEB.2.02.1505281410150.18405@cs-meet.cs.unibas.ch>

Dear Junxiao,

thanks for sharing your design plans and the possibility to comment.

A packet layout question: Isn't the NdnlpHeader wrapper redundant? You 
can see this in the grammar where no other field can ever follow the 
outer NDNLP-PACKET-TYPE and -length.

Or are there plans for other fields coming before or instead of the 
NdnlpHeader? Else I guess that this was introduced for parsing speed 
reasons? But the price is considerable: at least 2 mandatory bytes for 
every Ndnlp packet for carrying no additional information.

Regarding fragmentation, I'm wondering about plans for the B+E style 
mentioned in the slides. Could additional fragment types be forseen?

   fragmentBegin, fragmentMiddle, fragmendEnd and fragmentBeginEnd

This would bring the overhead from 2 or 3 bytes for a B+E header 
extension down to 0 additional bytes. *)

Finally some suggestions where the packet format description could 
benefit from clarifications regarding operational aspects:

- NDNLP packet stuffing (concatenation) inside the same frame:
   ok or not?

- mixed NDNLP/Interest/Data stuffing inside the same frame: ok or not?

- fixed width of sequence number field: can the sender choose
   unilateraly or will be there a link negotiation protocol? Can
   the sender change the width on the fly?

- Isn't the statement that "If an incoming NdnlpPacket contains unknown
   fields, the receiver MUST drop the packet" evolution-hostile, also
   against the old principle of "be liberal in what you accept"?

   Or expresses this a stance against the feature interaction problem
   and wants to prevent vendor-specific extensions? Asked differently:
   Shouldn't there be a type range reserved for experimental and
   vendor-specific extensions with an explicit semantics on how to
   process such packets with unknown extensions (without dropping the
   packet alltogether)?

- Related: Does the statement (in the indexed fragmentation section)
   reading "Unless otherwise specified, header extension fields from
   other features shall only appear on the first fragment." mean that
   in general a link feature can/will squat the link for some
   self-chosen duration?
   For example, a hypothetical "urgent msg feature" (or signals like
   a fragment ack or nack feature running in the other direction) would
   have to wait until a fragment train has ended?

best, christian


*) Looking at the "minimum Ndnlp packet fragment overhead" might be
    an interesting metric to observe in the design. Currently, it seems
    that a B+E scheme in NDNLP will vary between 12 and 7 bytes of
    overhead, depending on the final design and type allocation choices
    that will be made. In a BT low energy context with 20B MTU this
    means a change from 8 to 13 bytes payload, a 60% capacity increase.


On Tue, 26 May 2015, Junxiao Shi wrote:

> 
> Dear folks
> 
> I have written the protocol spec of first batch of features in NDNLPv2, and
> I need someone to review the design.
> 
> http://redmine.named-data.net/projects/nfd/wiki/NDNLPv2
> 
> If you don't know what this is about, see #2520, #2763, andhttp://redmine.named-data.net/attachments/download/301/NDNLPv2_20150417.ppt
> x
> 
> I'll appreciate all review comments.
> You don't have to be an expert in order to do a design review.
> 
> Yours, Junxiao
> 
> 
>


From shijunxiao at email.arizona.edu  Thu May 28 14:20:11 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Thu, 28 May 2015 14:20:11 -0700
Subject: [Nfd-dev] review request: NDNLPv2 NACK, Fragmentation,
	LocalControlHeader
In-Reply-To: <55672683.5090709@uni-bamberg.de>
References: <55672683.5090709@uni-bamberg.de>
Message-ID: <CAOFH+OYwBK=ezNsPdrcN=Jfm2QNuTChwNBypkQRYGCt5t3deaA@mail.gmail.com>

Hi Klaus

Thanks for your detailed review.

WiFi
Yes, NDNLPv2 will work on all links including wireless links.
I didn't specifically mention WiFi because most WiFi links are emulating
Ethernet, and there's no difference from software perspective.

Unknown Fields
Excerpt from NDNLPv2_20150513.pptx
<http://redmine.named-data.net/attachments/download/327/NDNLPv2_20150513.pptx>
page
27:

Rationale: NdnlpPacket is hop-by-hop. It's feasible to ensure everyone to
understand all fields.


Ignoring an unknown field will cause incorrect operations, see #2520
note-11.

NACK means "negative acknowledgment"
Agreed.

Local Cache Policy
CachingPolicy field is neither cache decision policy nor cache replacement
policy.
It indicates a suggestion to ContentStore about one specific Data. This
point is already made explicit in "whether and how to cache a Data packet",
but I should use "the" instead of "a" to clarify, or add another sentence.
See NDNLPv2_20150513.pptx
<http://redmine.named-data.net/attachments/download/327/NDNLPv2_20150513.pptx>
page
72 on other values in the plan.

Reliability Improvement
This is in the plan but not in this spec.


I'll also consider minor suggestions in the PDF.

Yours, Junxiao

On Thu, May 28, 2015 at 7:30 AM, Klaus Schneider <
klaus.schneider at uni-bamberg.de> wrote:

> Hi Junxiao,
>
> I hope it's not too late for my comments.
>
> Most of the spec looks good to me. Here are just a few remarks/questions.
>
>
> ## Goals
>
> I suppose that NDNLP will also work on wireless links? Maybe it's a good
> idea to add IEEE 802.11 (WiFi) to the list of examples.
>
> ## NDNLP Packet Format
>
> Maybe you can elaborate on why a NDNLP packet with unknown fields must be
> dropped. What is the benefit against accepting the packet and ignoring the
> unknown field? Should the receiver send a notice to sender of the dropped
> packet (sth. like a NACK)?
>
> ## Network NACK
>
> Maybe one can write out that NACK means "negative acknowledgment". It's
> probably obvious though.
>
> ## Local Cache Policy
>
> Am I right to assume that the policy affects only the single data packet
> and not the other caching decisions (so CachingPolicy can't be set to LRU,
> LFU, etc.)? Maybe one can make that more explicit.
>
> I am also unsure if the caching policy is about the cache decision policy
> (like cache/no cache), cache replacement policy or both. I assume it's the
> latter case, but I think it can't hurt to make it more explicit.
>
> ## Misc.
>
> Regarding the "reliability improvement": Did you have a look at RFC 3366
> "Advice to link designers on link Automatic Repeat reQuest (ARQ)" (
> http://www.rfc-base.org/txt/rfc-3366.txt) ?
>
> They differentiate between Perfectly-Persistent (Reliable),
> High-Persistence (Highly-Reliable) and Low-Persistence (Partially-Reliable)
> ARQ Protocols. Maybe you can use some ideas from that document. I think
> it's a great read.
>
> I have appended a pdf file with a few orthographical suggestions. Please
> consider that I am not a native speaker and may be wrong about some of
> these.
>
> I hope that helps.
>
> Best regards,
> Klaus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150528/5b7c3e3f/attachment.html>

From shijunxiao at email.arizona.edu  Thu May 28 14:28:24 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Thu, 28 May 2015 14:28:24 -0700
Subject: [Nfd-dev] review request: NDNLPv2 NACK, Fragmentation,
	LocalControlHeader
In-Reply-To: <alpine.DEB.2.02.1505281410150.18405@cs-meet.cs.unibas.ch>
References: <CAOFH+OY2_gHLAhY0ABatDRoheypp4ibVCnN-57MgAPDvKL7aUQ@mail.gmail.com>
	<CAOFH+OZu_AnJsVGQAJqLQVAZYARPyD7HNfa1qVv7rjx4wef8jw@mail.gmail.com>
	<CAOFH+ObDXAyYd7FPkRnOAvJuRWJv=gGFxF0_jwZigqUEFZVdYg@mail.gmail.com>
	<alpine.DEB.2.02.1505281410150.18405@cs-meet.cs.unibas.ch>
Message-ID: <CAOFH+Oa+9AigMZ_Yd7ct2vCE0t3AMqkm=GOCwCwoU6YaTr1LkQ@mail.gmail.com>

Hi Christian

NdnlpHeader wrapper
In the full plan NDNLPv2_20150513.pptx
<http://redmine.named-data.net/attachments/download/327/NDNLPv2_20150513.pptx>
page
17-20, we have a header and a trailer. The header wrapper makes it easier
to define the portion covered by HMAC signature (page 53), and permits a
padding at the end of header (page 24).
2-octet overhead is negligible on the link types mentioned in "Goals"
section. NDNLPv2 is not designed for 20-octet MTU links; those links need a
different link adaptation layer protocol.

B-E Fragmentation and extra fragment types
No, only NdnlpFragment type is allowed.
3-octet overhead is negligible on the link types mentioned in "Goals"
section. NDNLPv2 is not designed for 20-octet MTU links; those links need a
different link adaptation layer protocol.

Concatenation in single frame
NDNLPv2 is able to operation on a stream socket, so it can handle
concatenation in a single frame.
However, NDNLPv2 does not define whether concatenation is allowed, and this
is up to face implementation.
See also
http://www.lists.cs.ucla.edu/pipermail/ndn-lib/2014-November/000215.html on
a related topic about WebSocket frame vs network layer packets.

NdnlpSequence width
The width is chosen by link implementation.
Suppose EthernetFace implementation for 100Mbps link has chosen 48-bit, all
NdnlpSequence on this link must be 48-bit.
There's no negotiation.

Unknown Fields
Excerpt from NDNLPv2_20150513.pptx
<http://redmine.named-data.net/attachments/download/327/NDNLPv2_20150513.pptx>
page
27:

Rationale: NdnlpPacket is hop-by-hop. It's feasible to ensure everyone to
understand all fields.


Ignoring an unknown field will cause incorrect operations, see #2520
note-11.

A vendor-specific extension can claim a TLV-TYPE as "known field but
relevant feature is disabled".
This is not a "unknown field".

Extension fields on first fragment only
This mainly applies to extension fields that decorate a whole network layer
packet.
For example, it's sufficient to add a Network NACK on the first fragment,
and it's unnecessary to repeat the Network NACK field on subsequent
fragments.

Fields that do not decorate a network layer packet, such as Automated
Repeat reQuest, can be added to any fragment.

Yours, Junxiao

On Thu, May 28, 2015 at 7:33 AM, <christian.tschudin at unibas.ch> wrote:

> Dear Junxiao,
>
> thanks for sharing your design plans and the possibility to comment.
>
> A packet layout question: Isn't the NdnlpHeader wrapper redundant? You can
> see this in the grammar where no other field can ever follow the outer
> NDNLP-PACKET-TYPE and -length.
>
> Or are there plans for other fields coming before or instead of the
> NdnlpHeader? Else I guess that this was introduced for parsing speed
> reasons? But the price is considerable: at least 2 mandatory bytes for
> every Ndnlp packet for carrying no additional information.
>
> Regarding fragmentation, I'm wondering about plans for the B+E style
> mentioned in the slides. Could additional fragment types be forseen?
>
>   fragmentBegin, fragmentMiddle, fragmendEnd and fragmentBeginEnd
>
> This would bring the overhead from 2 or 3 bytes for a B+E header extension
> down to 0 additional bytes. *)
>
> Finally some suggestions where the packet format description could benefit
> from clarifications regarding operational aspects:
>
> - NDNLP packet stuffing (concatenation) inside the same frame:
>   ok or not?
>
> - mixed NDNLP/Interest/Data stuffing inside the same frame: ok or not?
>
> - fixed width of sequence number field: can the sender choose
>   unilateraly or will be there a link negotiation protocol? Can
>   the sender change the width on the fly?
>
> - Isn't the statement that "If an incoming NdnlpPacket contains unknown
>   fields, the receiver MUST drop the packet" evolution-hostile, also
>   against the old principle of "be liberal in what you accept"?
>
>   Or expresses this a stance against the feature interaction problem
>   and wants to prevent vendor-specific extensions? Asked differently:
>   Shouldn't there be a type range reserved for experimental and
>   vendor-specific extensions with an explicit semantics on how to
>   process such packets with unknown extensions (without dropping the
>   packet alltogether)?
>
> - Related: Does the statement (in the indexed fragmentation section)
>   reading "Unless otherwise specified, header extension fields from
>   other features shall only appear on the first fragment." mean that
>   in general a link feature can/will squat the link for some
>   self-chosen duration?
>   For example, a hypothetical "urgent msg feature" (or signals like
>   a fragment ack or nack feature running in the other direction) would
>   have to wait until a fragment train has ended?
>
> best, christian
>
>
> *) Looking at the "minimum Ndnlp packet fragment overhead" might be
>    an interesting metric to observe in the design. Currently, it seems
>    that a B+E scheme in NDNLP will vary between 12 and 7 bytes of
>    overhead, depending on the final design and type allocation choices
>    that will be made. In a BT low energy context with 20B MTU this
>    means a change from 8 to 13 bytes payload, a 60% capacity increase.
>
>
>
> On Tue, 26 May 2015, Junxiao Shi wrote:
>
>
>> Dear folks
>>
>> I have written the protocol spec of first batch of features in NDNLPv2,
>> and
>> I need someone to review the design.
>>
>> http://redmine.named-data.net/projects/nfd/wiki/NDNLPv2
>>
>> If you don't know what this is about, see #2520, #2763, andhttp://
>> redmine.named-data.net/attachments/download/301/NDNLPv2_20150417.ppt
>> x
>>
>> I'll appreciate all review comments.
>> You don't have to be an expert in order to do a design review.
>>
>> Yours, Junxiao
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150528/240e4449/attachment.html>