From nfd-call-notification at mail1.yoursunny.com  Wed Feb  1 08:00:03 2017
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Wed, 1 Feb 2017 09:00:03 -0700
Subject: [Nfd-dev] NFD call 20170201
Message-ID: <201702011600.v11G0354017232@lectura.cs.arizona.edu>

An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20170201/8c575643/attachment.html>

From aa at CS.UCLA.EDU  Thu Feb  2 15:45:25 2017
From: aa at CS.UCLA.EDU (Alex Afanasyev)
Date: Thu, 2 Feb 2017 15:45:25 -0800
Subject: [Nfd-dev] How can I use Wifi Direct with nfd-android
In-Reply-To: <645A91EB-9177-433B-A1BD-8A1F8BF7E1C6@cs.ucla.edu>
References: <CAD6hRmn13o1JJvJskbaxn_1Fap3xYuv07BQ=OP5T89Y+g8-PnQ@mail.gmail.com>
	<645A91EB-9177-433B-A1BD-8A1F8BF7E1C6@cs.ucla.edu>
Message-ID: <DD3414D3-35FE-45E6-987F-85D60D46E2EA@cs.ucla.edu>


> On Jan 29, 2017, at 10:06 AM, Lixia Zhang <lixia at CS.UCLA.EDU> wrote:
> 
> 
>> On Jan 26, 2017, at 9:44 AM, lahmer ilyas <ilyaslahmer93 at gmail.com <mailto:ilyaslahmer93 at gmail.com>> wrote:
>> 
>> Hi, I'm looking to use wifi-Direct with NFD-android. I want to make an app that sends an Interest to local NFD, then NFD will broadcast that Interest using wifiDirect. Can you please provides me with a hint to how implement that.
> 
> I know little about wifidirect, but according to https://en.wikipedia.org/wiki/Wi-Fi_Direct <https://en.wikipedia.org/wiki/Wi-Fi_Direct>
> it sets up a peer-peer connection in absence of an AP.  
> 
> We just finished such an implementation, the code should be in the pipe of the release process. I expect to see it out soon (though there is a dependency on people?s cycles)

As Lixia mentioned, we are almost finished with integration of WiFi direct function i NFD-Android app.  The code is on our gerrit (https://gerrit.named-data.net/#/c/3563/ <https://gerrit.named-data.net/#/c/3563/>) and you're really welcome to try it and help us thoroughly debug it before it goes into the released version of the app.

---
Alex


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

From shijunxiao at email.arizona.edu  Fri Feb  3 18:41:28 2017
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Fri, 3 Feb 2017 19:41:28 -0700
Subject: [Nfd-dev] Expiration time of the RIB entry at the NDN nodes
In-Reply-To: <BCBFBC0B008B2443A454A13CD91EBEDA2DC722CF@CITESMBX6.ad.uillinois.edu>
References: <BCBFBC0B008B2443A454A13CD91EBEDA2DC7229B@CITESMBX6.ad.uillinois.edu>
	<CAOFH+OZeRYsY-VO+u+p9Gi-nD87f6mqx-xcZbRV7oStOEO2+SA@mail.gmail.com>
	<BCBFBC0B008B2443A454A13CD91EBEDA2DC722CF@CITESMBX6.ad.uillinois.edu>
Message-ID: <CAOFH+Oa9HNo8Dn6KB+y=tCuwq6fS9sV7x8k7gDM3-xSQDupGuA@mail.gmail.com>

Hi Jongdeog

  So I guess if the pingserver is not idle, the prefix at the Illinois node
> would not be expired, right?
>

If the connection between end host and gateway router is good, and there's
no problem with certificate retrieval, the prefix registered on Illinois
node should not disappear, regardless of whether the pingserver is idle or
not.

Routes registered via auto prefix propagation are set to "never expire", so
that they will not appear as long as the face does not appear.
A UDP on-demand face has a default idle timeout of 600 seconds (router's
nfd.conf face_system.udp.idle_timeout key), which means your end host must
send something to the router at least once every 600 seconds. If everything
else is idle, auto prefix propagation can still fulfill this requirement by
sending a prefix registration command once every 300 seconds (end host's
nfd.conf rib.auto_prefix_propagate.refresh_interval key).

However, there are two possible reasons that can cause the face to
disappear.

First, if there is a network connectivity problem that causes either end to
receive an ICMP error, the face disappears on that end.
On end host side, you can prevent this situation by creating the face with
persistency set to permanent. The command is nfdc create -P udp4://
192.0.2.1:6363 for NFD 0.5.1 or below, and nfdc face create udp4://
192.0.2.1:6363 permanent for upcoming NFD version.
In case the face disappears on router side, the next prefix registration
command will create a new face on the router and add the prefix again.

Second, if there is a certificate retrieval problem, or any other reason
that causes the prefix registration command sent by auto prefix propagation
to fail, the exponential back-off retrying algorithm in auto prefix
propagation will kick in. The base retry wait is 50 seconds, and the
maximum retry wait is as long as 3600 seconds (end host's nfd.conf
rib.auto_prefix_propagate section). This means, if prefix registration
command has failed four times, the retry wait would increase to 800 seconds
which is greater than UDP on-demand face's idle timeout, and then you'll
observe the end host's face appear and disappear on the router one time or
another.

But if there's no ICMP error and no error during prefix registration, none
of these would happen.

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

From jlee700 at illinois.edu  Sat Feb  4 19:36:41 2017
From: jlee700 at illinois.edu (Lee, Jongdeog)
Date: Sun, 5 Feb 2017 03:36:41 +0000
Subject: [Nfd-dev] Expiration time of the RIB entry at the NDN nodes
In-Reply-To: <CAOFH+Oa9HNo8Dn6KB+y=tCuwq6fS9sV7x8k7gDM3-xSQDupGuA@mail.gmail.com>
References: <BCBFBC0B008B2443A454A13CD91EBEDA2DC7229B@CITESMBX6.ad.uillinois.edu>
	<CAOFH+OZeRYsY-VO+u+p9Gi-nD87f6mqx-xcZbRV7oStOEO2+SA@mail.gmail.com>
	<BCBFBC0B008B2443A454A13CD91EBEDA2DC722CF@CITESMBX6.ad.uillinois.edu>,
	<CAOFH+Oa9HNo8Dn6KB+y=tCuwq6fS9sV7x8k7gDM3-xSQDupGuA@mail.gmail.com>
Message-ID: <BCBFBC0B008B2443A454A13CD91EBEDA2DC73A5D@CITESMBX6.ad.uillinois.edu>

Thanks, Junxiao.
Let me try your solutions and will let you know.

Best wishes,
Jongdeog Lee (JD)

------------------------------------------------
Ph.D. Student
Department of Computer Science
University of Illinois at Urbana-Champaign
________________________________
From: Junxiao Shi [shijunxiao at email.arizona.edu]
Sent: Friday, February 03, 2017 8:41 PM
To: Lee, Jongdeog
Cc: nfd-dev at lists.cs.ucla.edu
Subject: Re: [Nfd-dev] Expiration time of the RIB entry at the NDN nodes

Hi Jongdeog

  So I guess if the pingserver is not idle, the prefix at the Illinois node would not be expired, right?

If the connection between end host and gateway router is good, and there's no problem with certificate retrieval, the prefix registered on Illinois node should not disappear, regardless of whether the pingserver is idle or not.

Routes registered via auto prefix propagation are set to "never expire", so that they will not appear as long as the face does not appear.
A UDP on-demand face has a default idle timeout of 600 seconds (router's nfd.conf face_system.udp.idle_timeout key), which means your end host must send something to the router at least once every 600 seconds. If everything else is idle, auto prefix propagation can still fulfill this requirement by sending a prefix registration command once every 300 seconds (end host's nfd.conf rib.auto_prefix_propagate.refresh_interval key).

However, there are two possible reasons that can cause the face to disappear.

First, if there is a network connectivity problem that causes either end to receive an ICMP error, the face disappears on that end.
On end host side, you can prevent this situation by creating the face with persistency set to permanent. The command is nfdc create -P udp4://192.0.2.1:6363<https://urldefense.proofpoint.com/v2/url?u=http-3A__192.0.2.1-3A6363&d=DwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Z7ZyWHGeVXO4-LRL2FeI1ZE8d269MMOL_mjEf1LVJpE&m=HR2SgAeeV7vbnp3lqnGI0f421cqUvzmjeim3StaLrsY&s=tBokOJVtokpjyuFKg5DFmyyyUX43IFLNWwH2T1EnxPg&e=> for NFD 0.5.1 or below, and nfdc face create udp4://192.0.2.1:6363<https://urldefense.proofpoint.com/v2/url?u=http-3A__192.0.2.1-3A6363&d=DwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Z7ZyWHGeVXO4-LRL2FeI1ZE8d269MMOL_mjEf1LVJpE&m=HR2SgAeeV7vbnp3lqnGI0f421cqUvzmjeim3StaLrsY&s=tBokOJVtokpjyuFKg5DFmyyyUX43IFLNWwH2T1EnxPg&e=> permanent for upcoming NFD version.
In case the face disappears on router side, the next prefix registration command will create a new face on the router and add the prefix again.

Second, if there is a certificate retrieval problem, or any other reason that causes the prefix registration command sent by auto prefix propagation to fail, the exponential back-off retrying algorithm in auto prefix propagation will kick in. The base retry wait is 50 seconds, and the maximum retry wait is as long as 3600 seconds (end host's nfd.conf rib.auto_prefix_propagate section). This means, if prefix registration command has failed four times, the retry wait would increase to 800 seconds which is greater than UDP on-demand face's idle timeout, and then you'll observe the end host's face appear and disappear on the router one time or another.

But if there's no ICMP error and no error during prefix registration, none of these would happen.

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

From nfd-call-notification at mail1.yoursunny.com  Mon Feb  6 08:00:05 2017
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Mon, 6 Feb 2017 09:00:05 -0700
Subject: [Nfd-dev] NFD call 20170206
Message-ID: <201702061600.v16G052J010934@lectura.cs.arizona.edu>

An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20170206/2e003aa3/attachment.html>

From nfd-call-notification at mail1.yoursunny.com  Wed Feb  8 08:00:02 2017
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Wed, 8 Feb 2017 09:00:02 -0700
Subject: [Nfd-dev] NFD call 20170208
Message-ID: <201702081600.v18G02Pj026995@lectura.cs.arizona.edu>

An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20170208/60c66251/attachment.html>

From jlee700 at illinois.edu  Wed Feb  8 09:06:46 2017
From: jlee700 at illinois.edu (Lee, Jongdeog)
Date: Wed, 8 Feb 2017 17:06:46 +0000
Subject: [Nfd-dev] Expiration time of the RIB entry at the NDN nodes
In-Reply-To: <CAOFH+Oa9HNo8Dn6KB+y=tCuwq6fS9sV7x8k7gDM3-xSQDupGuA@mail.gmail.com>
References: <BCBFBC0B008B2443A454A13CD91EBEDA2DC7229B@CITESMBX6.ad.uillinois.edu>
	<CAOFH+OZeRYsY-VO+u+p9Gi-nD87f6mqx-xcZbRV7oStOEO2+SA@mail.gmail.com>
	<BCBFBC0B008B2443A454A13CD91EBEDA2DC722CF@CITESMBX6.ad.uillinois.edu>,
	<CAOFH+Oa9HNo8Dn6KB+y=tCuwq6fS9sV7x8k7gDM3-xSQDupGuA@mail.gmail.com>
Message-ID: <BCBFBC0B008B2443A454A13CD91EBEDA2DC73C5D@CITESMBX6.ad.uillinois.edu>

Dear Junxiao,

  Thanks. I fixed the issue based on your advice.
  As you said, the prefix is expired because the associated face is expired.
  To prevent this,

1. nfdc create -P udp4://ndnx.cs.illinois.edu
2. nfdc register / tcp4://ndnx.cs.illinois.edu
3. nfdc register /localhop/nfd tcp4://ndnx.cs.illinois.edu

  Above commands fixed my issue (I skipped step 1 before, and it expires the face).

Best wishes,
Jongdeog Lee (JD)

------------------------------------------------
Ph.D. Student
Department of Computer Science
University of Illinois at Urbana-Champaign
________________________________
From: Junxiao Shi [shijunxiao at email.arizona.edu]
Sent: Friday, February 03, 2017 8:41 PM
To: Lee, Jongdeog
Cc: nfd-dev at lists.cs.ucla.edu
Subject: Re: [Nfd-dev] Expiration time of the RIB entry at the NDN nodes

Hi Jongdeog

  So I guess if the pingserver is not idle, the prefix at the Illinois node would not be expired, right?

If the connection between end host and gateway router is good, and there's no problem with certificate retrieval, the prefix registered on Illinois node should not disappear, regardless of whether the pingserver is idle or not.

Routes registered via auto prefix propagation are set to "never expire", so that they will not appear as long as the face does not appear.
A UDP on-demand face has a default idle timeout of 600 seconds (router's nfd.conf face_system.udp.idle_timeout key), which means your end host must send something to the router at least once every 600 seconds. If everything else is idle, auto prefix propagation can still fulfill this requirement by sending a prefix registration command once every 300 seconds (end host's nfd.conf rib.auto_prefix_propagate.refresh_interval key).

However, there are two possible reasons that can cause the face to disappear.

First, if there is a network connectivity problem that causes either end to receive an ICMP error, the face disappears on that end.
On end host side, you can prevent this situation by creating the face with persistency set to permanent. The command is nfdc create -P udp4://192.0.2.1:6363<https://urldefense.proofpoint.com/v2/url?u=http-3A__192.0.2.1-3A6363&d=DwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Z7ZyWHGeVXO4-LRL2FeI1ZE8d269MMOL_mjEf1LVJpE&m=HR2SgAeeV7vbnp3lqnGI0f421cqUvzmjeim3StaLrsY&s=tBokOJVtokpjyuFKg5DFmyyyUX43IFLNWwH2T1EnxPg&e=> for NFD 0.5.1 or below, and nfdc face create udp4://192.0.2.1:6363<https://urldefense.proofpoint.com/v2/url?u=http-3A__192.0.2.1-3A6363&d=DwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Z7ZyWHGeVXO4-LRL2FeI1ZE8d269MMOL_mjEf1LVJpE&m=HR2SgAeeV7vbnp3lqnGI0f421cqUvzmjeim3StaLrsY&s=tBokOJVtokpjyuFKg5DFmyyyUX43IFLNWwH2T1EnxPg&e=> permanent for upcoming NFD version.
In case the face disappears on router side, the next prefix registration command will create a new face on the router and add the prefix again.

Second, if there is a certificate retrieval problem, or any other reason that causes the prefix registration command sent by auto prefix propagation to fail, the exponential back-off retrying algorithm in auto prefix propagation will kick in. The base retry wait is 50 seconds, and the maximum retry wait is as long as 3600 seconds (end host's nfd.conf rib.auto_prefix_propagate section). This means, if prefix registration command has failed four times, the retry wait would increase to 800 seconds which is greater than UDP on-demand face's idle timeout, and then you'll observe the end host's face appear and disappear on the router one time or another.

But if there's no ICMP error and no error during prefix registration, none of these would happen.

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

From jlee700 at illinois.edu  Wed Feb  8 12:05:15 2017
From: jlee700 at illinois.edu (Lee, Jongdeog)
Date: Wed, 8 Feb 2017 20:05:15 +0000
Subject: [Nfd-dev] Expiration time of the RIB entry at the NDN nodes
In-Reply-To: <BCBFBC0B008B2443A454A13CD91EBEDA2DC73C5D@CITESMBX6.ad.uillinois.edu>
References: <BCBFBC0B008B2443A454A13CD91EBEDA2DC7229B@CITESMBX6.ad.uillinois.edu>
	<CAOFH+OZeRYsY-VO+u+p9Gi-nD87f6mqx-xcZbRV7oStOEO2+SA@mail.gmail.com>
	<BCBFBC0B008B2443A454A13CD91EBEDA2DC722CF@CITESMBX6.ad.uillinois.edu>,
	<CAOFH+Oa9HNo8Dn6KB+y=tCuwq6fS9sV7x8k7gDM3-xSQDupGuA@mail.gmail.com>,
	<BCBFBC0B008B2443A454A13CD91EBEDA2DC73C5D@CITESMBX6.ad.uillinois.edu>
Message-ID: <BCBFBC0B008B2443A454A13CD91EBEDA2DC73CC2@CITESMBX6.ad.uillinois.edu>

I just want to correct typos (tcp4 -> udp4).
Again, thanks for the reply.

1. nfdc create -P udp4://ndnx.cs.illinois.edu
2. nfdc register / udp4://ndnx.cs.illinois.edu
3. nfdc register /localhop/nfd udp4://ndnx.cs.illinois.edu

Best wishes,
Jongdeog Lee (JD)

------------------------------------------------
Ph.D. Student
Department of Computer Science
University of Illinois at Urbana-Champaign
________________________________
From: Lee, Jongdeog
Sent: Wednesday, February 08, 2017 11:06 AM
To: Junxiao Shi
Cc: nfd-dev at lists.cs.ucla.edu
Subject: RE: [Nfd-dev] Expiration time of the RIB entry at the NDN nodes

Dear Junxiao,

  Thanks. I fixed the issue based on your advice.
  As you said, the prefix is expired because the associated face is expired.
  To prevent this,

1. nfdc create -P udp4://ndnx.cs.illinois.edu
2. nfdc register / tcp4://ndnx.cs.illinois.edu
3. nfdc register /localhop/nfd tcp4://ndnx.cs.illinois.edu

  Above commands fixed my issue (I skipped step 1 before, and it expires the face).

Best wishes,
Jongdeog Lee (JD)

------------------------------------------------
Ph.D. Student
Department of Computer Science
University of Illinois at Urbana-Champaign
________________________________
From: Junxiao Shi [shijunxiao at email.arizona.edu]
Sent: Friday, February 03, 2017 8:41 PM
To: Lee, Jongdeog
Cc: nfd-dev at lists.cs.ucla.edu
Subject: Re: [Nfd-dev] Expiration time of the RIB entry at the NDN nodes

Hi Jongdeog

  So I guess if the pingserver is not idle, the prefix at the Illinois node would not be expired, right?

If the connection between end host and gateway router is good, and there's no problem with certificate retrieval, the prefix registered on Illinois node should not disappear, regardless of whether the pingserver is idle or not.

Routes registered via auto prefix propagation are set to "never expire", so that they will not appear as long as the face does not appear.
A UDP on-demand face has a default idle timeout of 600 seconds (router's nfd.conf face_system.udp.idle_timeout key), which means your end host must send something to the router at least once every 600 seconds. If everything else is idle, auto prefix propagation can still fulfill this requirement by sending a prefix registration command once every 300 seconds (end host's nfd.conf rib.auto_prefix_propagate.refresh_interval key).

However, there are two possible reasons that can cause the face to disappear.

First, if there is a network connectivity problem that causes either end to receive an ICMP error, the face disappears on that end.
On end host side, you can prevent this situation by creating the face with persistency set to permanent. The command is nfdc create -P udp4://192.0.2.1:6363<https://urldefense.proofpoint.com/v2/url?u=http-3A__192.0.2.1-3A6363&d=DwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Z7ZyWHGeVXO4-LRL2FeI1ZE8d269MMOL_mjEf1LVJpE&m=HR2SgAeeV7vbnp3lqnGI0f421cqUvzmjeim3StaLrsY&s=tBokOJVtokpjyuFKg5DFmyyyUX43IFLNWwH2T1EnxPg&e=> for NFD 0.5.1 or below, and nfdc face create udp4://192.0.2.1:6363<https://urldefense.proofpoint.com/v2/url?u=http-3A__192.0.2.1-3A6363&d=DwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Z7ZyWHGeVXO4-LRL2FeI1ZE8d269MMOL_mjEf1LVJpE&m=HR2SgAeeV7vbnp3lqnGI0f421cqUvzmjeim3StaLrsY&s=tBokOJVtokpjyuFKg5DFmyyyUX43IFLNWwH2T1EnxPg&e=> permanent for upcoming NFD version.
In case the face disappears on router side, the next prefix registration command will create a new face on the router and add the prefix again.

Second, if there is a certificate retrieval problem, or any other reason that causes the prefix registration command sent by auto prefix propagation to fail, the exponential back-off retrying algorithm in auto prefix propagation will kick in. The base retry wait is 50 seconds, and the maximum retry wait is as long as 3600 seconds (end host's nfd.conf rib.auto_prefix_propagate section). This means, if prefix registration command has failed four times, the retry wait would increase to 800 seconds which is greater than UDP on-demand face's idle timeout, and then you'll observe the end host's face appear and disappear on the router one time or another.

But if there's no ICMP error and no error during prefix registration, none of these would happen.

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

From Matteo.Bertolino at eurecom.fr  Thu Feb  9 08:08:21 2017
From: Matteo.Bertolino at eurecom.fr (Matteo Bertolino)
Date: Thu, 09 Feb 2017 17:08:21 +0100
Subject: [Nfd-dev] Adding a new type of NACK
Message-ID: <20170209170821.glq251mt4w4ss0o4@webmail.eurecom.fr>

Good morning,
I am trying to add a new type of NACK called "PERSONALIZED" in ndn-cxx.
Then I modify the strategy method "after receive NACK" with:
if (nack.getReason() == lp::NackReason::PERSONALIZED) {
      log << "I received a PERSONALIZED NACK";
}

But when I compile I have the error:
"PERSONALIZED" is not a member of "ndn::lp::NackReason".


My steps to add the new NACK were:
1) modifying ndn-cxx/src/lp/nack-header.cpp

adding:
case NackReason::PERSONALIZED:
os << "MyPersonalNACK";
break;

in the method operator <<

2) adding the equivalent in the method getReason() always in nack-header.cpp

3) in nack-header.hpp I add:
enum class NackReason {
NONE = 0;
CONGESTION = 50;
...
PERSONALIZED = 200;
}

What did I forgot ?

Thanks in advance
Bests,
Matteo

-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr


From enewberry at email.arizona.EDU  Thu Feb  9 08:18:10 2017
From: enewberry at email.arizona.EDU (enewberry@email.arizona.edu)
Date: Thu, 09 Feb 2017 09:18:10 -0700
Subject: [Nfd-dev] Adding a new type of NACK
Message-ID: <4p76b1h4261dv3bkf8oitc5p.1486657090358@email.lge.com>

Matteo,
I assume that ndn-cxx built successfully and that you're trying to use the new NACK type in NFD?
Have you installed the version of ndn-cxx you built so that NFD can find the new headers? If so, try doing a distclean on NFD and completely rebuild it.
Eric
------ Original message------From: Matteo BertolinoDate: Thu, Feb 9, 2017 9:10 AMTo: nfd-dev at lists.cs.ucla.edu;Cc: Subject:[Nfd-dev] Adding a new type of NACK
Good morning,I am trying to add a new type of NACK called "PERSONALIZED" in ndn-cxx.Then I modify the strategy method "after receive NACK" with:if (nack.getReason() == lp::NackReason::PERSONALIZED) {      log << "I received a PERSONALIZED NACK";}But when I compile I have the error:"PERSONALIZED" is not a member of "ndn::lp::NackReason".My steps to add the new NACK were:1) modifying ndn-cxx/src/lp/nack-header.cppadding:case NackReason::PERSONALIZED:os << "MyPersonalNACK";break;in the method operator <<2) adding the equivalent in the method getReason() always in nack-header.cpp3) in nack-header.hpp I add:enum class NackReason {NONE = 0;CONGESTION = 50;...PERSONALIZED = 200;}What did I forgot ?Thanks in advanceBests,Matteo-------------------------------------------------------------------------------This message was sent using EURECOM Webmail: http://webmail.eurecom.fr_______________________________________________Nfd-dev mailing listNfd-dev at lists.cs.ucla.eduhttp://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/20170209/84804cb6/attachment.html>

From Matteo.Bertolino at eurecom.fr  Thu Feb  9 08:29:18 2017
From: Matteo.Bertolino at eurecom.fr (Matteo Bertolino)
Date: Thu, 09 Feb 2017 17:29:18 +0100
Subject: [Nfd-dev] Adding a new type of NACK
In-Reply-To: <4p76b1h4261dv3bkf8oitc5p.1486657090358@email.lge.com>
References: <4p76b1h4261dv3bkf8oitc5p.1486657090358@email.lge.com>
Message-ID: <20170209172918.hq3sknsn0gskskw4@webmail.eurecom.fr>

Dear Eric,
thank you for your reply. I will answer in line.

Quoting "enewberry at email.arizona.edu" <enewberry at email.arizona.edu>:

> Matteo,
> I assume that ndn-cxx built successfully and that you're trying to   
> use the new NACK type in NFD?
Exactly.

> Have you installed the version of ndn-cxx you built so that NFD can   
> find the new headers?
Yes I did :)

> If so, try doing a distclean on NFD and  completely rebuild it.
Ok! Can I kindly ask you how to perform this operation?
Sorry for the not-smart question :)

Sincerely, Matteo


-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr


From Matteo.Bertolino at eurecom.fr  Thu Feb  9 08:49:10 2017
From: Matteo.Bertolino at eurecom.fr (Matteo Bertolino)
Date: Thu, 09 Feb 2017 17:49:10 +0100
Subject: [Nfd-dev] Adding a new type of NACK
In-Reply-To: <20170209172918.hq3sknsn0gskskw4@webmail.eurecom.fr>
References: <4p76b1h4261dv3bkf8oitc5p.1486657090358@email.lge.com>
	<20170209172918.hq3sknsn0gskskw4@webmail.eurecom.fr>
Message-ID: <20170209174910.eqb50vlggkckg080@webmail.eurecom.fr>

You had right!
Just a sudo ./waf clean and the problem is solved.
Thanks a lot.
Matteo

Quoting Matteo Bertolino <Matteo.Bertolino at eurecom.fr>:

> Dear Eric,
> thank you for your reply. I will answer in line.
>
> Quoting "enewberry at email.arizona.edu" <enewberry at email.arizona.edu>:
>
>> Matteo,
>> I assume that ndn-cxx built successfully and that you're trying to   
>>  use the new NACK type in NFD?
> Exactly.
>
>> Have you installed the version of ndn-cxx you built so that NFD can  
>>   find the new headers?
> Yes I did :)
>
>> If so, try doing a distclean on NFD and  completely rebuild it.
> Ok! Can I kindly ask you how to perform this operation?
> Sorry for the not-smart question :)
>
> Sincerely, Matteo
>
>
> -------------------------------------------------------------------------------
> This message was sent using EURECOM Webmail: http://webmail.eurecom.fr



-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr



From enewberry at email.arizona.EDU  Thu Feb  9 09:54:49 2017
From: enewberry at email.arizona.EDU (Eric Newberry)
Date: Thu, 9 Feb 2017 10:54:49 -0700
Subject: [Nfd-dev] Adding a new type of NACK
In-Reply-To: <20170209174910.eqb50vlggkckg080@webmail.eurecom.fr>
References: <4p76b1h4261dv3bkf8oitc5p.1486657090358@email.lge.com>
	<20170209172918.hq3sknsn0gskskw4@webmail.eurecom.fr>
	<20170209174910.eqb50vlggkckg080@webmail.eurecom.fr>
Message-ID: <4da6f527-fab2-e12e-67b9-68ebd92e5c07@email.arizona.edu>

Matteo,

Great to hear that it worked!

-Eric


On 02/09/2017 09:49 AM, Matteo Bertolino wrote:
> You had right!
> Just a sudo ./waf clean and the problem is solved.
> Thanks a lot.
> Matteo
>
> Quoting Matteo Bertolino <Matteo.Bertolino at eurecom.fr>:
>
>> Dear Eric,
>> thank you for your reply. I will answer in line.
>>
>> Quoting "enewberry at email.arizona.edu" <enewberry at email.arizona.edu>:
>>
>>> Matteo,
>>> I assume that ndn-cxx built successfully and that you're trying to  
>>>  use the new NACK type in NFD?
>> Exactly.
>>
>>> Have you installed the version of ndn-cxx you built so that NFD can 
>>>   find the new headers?
>> Yes I did :)
>>
>>> If so, try doing a distclean on NFD and completely rebuild it.
>> Ok! Can I kindly ask you how to perform this operation?
>> Sorry for the not-smart question :)
>>
>> Sincerely, Matteo
>>
>>
>> ------------------------------------------------------------------------------- 
>>
>> This message was sent using EURECOM Webmail: http://webmail.eurecom.fr
>
>
>
> ------------------------------------------------------------------------------- 
>
> This message was sent using EURECOM Webmail: http://webmail.eurecom.fr
>


From bastiaan.wissingh at tno.nl  Mon Feb 13 02:06:19 2017
From: bastiaan.wissingh at tno.nl (Wissingh, B.F. (Bastiaan))
Date: Mon, 13 Feb 2017 10:06:19 +0000
Subject: [Nfd-dev] Anyone used nfd-android with Ad-Hoc WiFi mode or
 Bluetooth?
Message-ID: <86CFAA18-316A-4EA5-8E8A-9DEEFC9475FE@tno.nl>

Hi,

We are currently looking into using nfd-android for some IoT experiments, for which we would like to use either WiFi in Ad-Hoc mode or Bluetooth to connect between different NDN based devices. So far however, it seems difficult to impossible to use Android devices in WiFi Ad-Hoc mode (without flashing a non-stock rom).

So we were wondering whether any of you has experience with using nfd-android via either Bluetooth (is that implemented within nfd-android?) or WiFi Ad-Hoc.

Looking forward to a reply,

Best regards,
Bastiaan Wissingh



B.F. (Bastiaan) Wissingh MSc
Research Scientist Media Networking
Department of Networks

T +31 (0)88 866 42 52
M +31 (0)65 280 35 59
E bastiaan.wissingh at tno.nl<mailto:bastiaan.wissingh at tno.nl>

Location<http://www.tno.nl/locaties/DHA>



[cid:image001.png at 01D285E9.340C6F30]<http://www.tno.nl/>

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20170213/11211fde/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 3227 bytes
Desc: image001.png
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20170213/11211fde/attachment.png>

From nfd-call-notification at mail1.yoursunny.com  Mon Feb 13 08:00:02 2017
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Mon, 13 Feb 2017 09:00:02 -0700
Subject: [Nfd-dev] NFD call 20170213
Message-ID: <201702131600.v1DG02Db002769@lectura.cs.arizona.edu>

An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20170213/d445abd1/attachment.html>

From aa at CS.UCLA.EDU  Mon Feb 13 10:02:16 2017
From: aa at CS.UCLA.EDU (Alex Afanasyev)
Date: Mon, 13 Feb 2017 10:02:16 -0800
Subject: [Nfd-dev] Anyone used nfd-android with Ad-Hoc WiFi mode or
 Bluetooth?
In-Reply-To: <86CFAA18-316A-4EA5-8E8A-9DEEFC9475FE@tno.nl>
References: <86CFAA18-316A-4EA5-8E8A-9DEEFC9475FE@tno.nl>
Message-ID: <06AB4CB0-658C-475E-A19A-3A3CB97A0506@cs.ucla.edu>

Hi Bastian,

We have pending commit to enable semi-automatic WiFi direct capability (https://gerrit.named-data.net/#/c/3563/ <https://gerrit.named-data.net/#/c/3563/>) coupled with name discovery protocol on top of it.  It just needs a bit more testing before going upstream.  I did an short series tests so far and it was really cool to see it working with a demo whiteboard app.

---
Alex

> On Feb 13, 2017, at 2:06 AM, Wissingh, B.F. (Bastiaan) <bastiaan.wissingh at tno.nl> wrote:
> 
> Hi,
>  
> We are currently looking into using nfd-android for some IoT experiments, for which we would like to use either WiFi in Ad-Hoc mode or Bluetooth to connect between different NDN based devices. So far however, it seems difficult to impossible to use Android devices in WiFi Ad-Hoc mode (without flashing a non-stock rom).
>  
> So we were wondering whether any of you has experience with using nfd-android via either Bluetooth (is that implemented within nfd-android?) or WiFi Ad-Hoc.
>  
> Looking forward to a reply,
>  
> Best regards,
> Bastiaan Wissingh
>  
>  
> B.F. (Bastiaan) Wissingh MSc
> Research Scientist Media Networking
> Department of Networks
> T +31 (0)88 866 42 52
> M +31 (0)65 280 35 59
> E bastiaan.wissingh at tno.nl <mailto:bastiaan.wissingh at tno.nl>	
> Location <http://www.tno.nl/locaties/DHA>
> 
>  
> <image001.png> <http://www.tno.nl/>
> This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.
>  
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu <mailto:Nfd-dev at lists.cs.ucla.edu>
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev <http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev>

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

From obaidasyed at gmail.com  Mon Feb 13 12:39:38 2017
From: obaidasyed at gmail.com (S. Obaid)
Date: Mon, 13 Feb 2017 12:39:38 -0800
Subject: [Nfd-dev] Anyone used nfd-android with Ad-Hoc WiFi mode or
 Bluetooth?
In-Reply-To: <06AB4CB0-658C-475E-A19A-3A3CB97A0506@cs.ucla.edu>
References: <86CFAA18-316A-4EA5-8E8A-9DEEFC9475FE@tno.nl>
	<06AB4CB0-658C-475E-A19A-3A3CB97A0506@cs.ucla.edu>
Message-ID: <CAN_R3w7jFa3z9OD8bbfHcniTnPCBgJcYiO-hrOptfpO9Ck=qNA@mail.gmail.com>

Hi Alex,

Is there any design document available of this feature?

Thanks,
Obaid

On Mon, Feb 13, 2017 at 10:02 AM, Alex Afanasyev <aa at cs.ucla.edu> wrote:

> Hi Bastian,
>
> We have pending commit to enable semi-automatic WiFi direct capability (
> https://gerrit.named-data.net/#/c/3563/) coupled with name discovery
> protocol on top of it.  It just needs a bit more testing before going
> upstream.  I did an short series tests so far and it was really cool to see
> it working with a demo whiteboard app.
>
> ---
> Alex
>
> On Feb 13, 2017, at 2:06 AM, Wissingh, B.F. (Bastiaan) <
> bastiaan.wissingh at tno.nl> wrote:
>
> Hi,
>
> We are currently looking into using nfd-android for some IoT experiments,
> for which we would like to use either WiFi in Ad-Hoc mode or Bluetooth to
> connect between different NDN based devices. So far however, it seems
> difficult to impossible to use Android devices in WiFi Ad-Hoc mode (without
> flashing a non-stock rom).
>
> So we were wondering whether any of you has experience with using
> nfd-android via either Bluetooth (is that implemented within nfd-android?)
> or WiFi Ad-Hoc.
>
> Looking forward to a reply,
>
> Best regards,
> Bastiaan Wissingh
>
>
> B.F. (Bastiaan) Wissingh MSc
> Research Scientist Media Networking
> Department of Networks
> T +31 (0)88 866 42 52
> M +31 (0)65 280 35 59
> E bastiaan.wissingh at tno.nl
> Location <http://www.tno.nl/locaties/DHA>
>
>
> <image001.png> <http://www.tno.nl/>
> This message may contain information that is not intended for you. If you
> are not the addressee or if this message was sent to you by mistake, you
> are requested to inform the sender and delete the message. TNO accepts no
> liability for the content of this e-mail, for the manner in which you use
> it and for damage of any kind resulting from the risks inherent to the
> electronic transmission of messages.
>
> _______________________________________________
> 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/20170213/070cce58/attachment.html>

From aa at CS.UCLA.EDU  Mon Feb 13 12:51:21 2017
From: aa at CS.UCLA.EDU (Alex Afanasyev)
Date: Mon, 13 Feb 2017 12:51:21 -0800
Subject: [Nfd-dev] Anyone used nfd-android with Ad-Hoc WiFi mode or
 Bluetooth?
In-Reply-To: <CAN_R3w7jFa3z9OD8bbfHcniTnPCBgJcYiO-hrOptfpO9Ck=qNA@mail.gmail.com>
References: <86CFAA18-316A-4EA5-8E8A-9DEEFC9475FE@tno.nl>
	<06AB4CB0-658C-475E-A19A-3A3CB97A0506@cs.ucla.edu>
	<CAN_R3w7jFa3z9OD8bbfHcniTnPCBgJcYiO-hrOptfpO9Ck=qNA@mail.gmail.com>
Message-ID: <A81F51E6-AB66-4A53-9CC1-544AED44174A@cs.ucla.edu>

Yes, there is a description of the protocol on redmine wiki: https://redmine.named-data.net/projects/nfd-android/wiki/NDN_Over_WiFi_Direct_Protocol_Specification  (this is initial version, details may change in the future).

--
Alex

> On Feb 13, 2017, at 12:39 PM, S. Obaid <obaidasyed at gmail.com> wrote:
> 
> Hi Alex, 
> 
> Is there any design document available of this feature?
> 
> Thanks, 
> Obaid
> 
> On Mon, Feb 13, 2017 at 10:02 AM, Alex Afanasyev <aa at cs.ucla.edu> wrote:
> Hi Bastian,
> 
> We have pending commit to enable semi-automatic WiFi direct capability (https://gerrit.named-data.net/#/c/3563/) coupled with name discovery protocol on top of it.  It just needs a bit more testing before going upstream.  I did an short series tests so far and it was really cool to see it working with a demo whiteboard app.
> 
> ---
> Alex
> 
>> On Feb 13, 2017, at 2:06 AM, Wissingh, B.F. (Bastiaan) <bastiaan.wissingh at tno.nl> wrote:
>> 
>> Hi,
>>  
>> We are currently looking into using nfd-android for some IoT experiments, for which we would like to use either WiFi in Ad-Hoc mode or Bluetooth to connect between different NDN based devices. So far however, it seems difficult to impossible to use Android devices in WiFi Ad-Hoc mode (without flashing a non-stock rom).
>>  
>> So we were wondering whether any of you has experience with using nfd-android via either Bluetooth (is that implemented within nfd-android?) or WiFi Ad-Hoc.
>>  
>> Looking forward to a reply,
>>  
>> Best regards,
>> Bastiaan Wissingh
>>  
>>  
>> B.F. (Bastiaan) Wissingh MSc
>> Research Scientist Media Networking
>> Department of Networks
>> T +31 (0)88 866 42 52
>> M +31 (0)65 280 35 59
>> E bastiaan.wissingh at tno.nl
>> Location
>> 
>>  
>> <image001.png>
>> This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.


From bastiaan.wissingh at tno.nl  Mon Feb 13 23:54:13 2017
From: bastiaan.wissingh at tno.nl (Wissingh, B.F. (Bastiaan))
Date: Tue, 14 Feb 2017 07:54:13 +0000
Subject: [Nfd-dev] Anyone used nfd-android with Ad-Hoc WiFi mode or
 Bluetooth?
In-Reply-To: <06AB4CB0-658C-475E-A19A-3A3CB97A0506@cs.ucla.edu>
References: <86CFAA18-316A-4EA5-8E8A-9DEEFC9475FE@tno.nl>
	<06AB4CB0-658C-475E-A19A-3A3CB97A0506@cs.ucla.edu>
Message-ID: <21502C4F-B66F-4DC5-90BD-F8B39EF4CBC5@tno.nl>

Hi Alex,

Thanks for the clarification, I indeed saw an earlier post regarding upcoming WiFi-Direct support. However, since this is different from either WiFi Ad-Hoc or Bluetooth is was wondering whether one of those are supported. But it appears indeed that WiFi Ad-Hoc is unsupported by the current versions of the Android OS, for which there are some work-arounds available, but they are inapplicable to our test setup unfortunately.

So how about Bluetooth support within nfd-android, has that been implemented?

Best,
Bastiaan

Van: Alex Afanasyev <aa at cs.ucla.edu>
Datum: maandag 13 februari 2017 19:02
Aan: Bastiaan Wissingh <bastiaan.wissingh at tno.nl>
CC: "nfd-dev at lists.cs.ucla.edu" <nfd-dev at lists.cs.ucla.edu>
Onderwerp: Re: [Nfd-dev] Anyone used nfd-android with Ad-Hoc WiFi mode or Bluetooth?

Hi Bastian,

We have pending commit to enable semi-automatic WiFi direct capability (https://gerrit.named-data.net/#/c/3563/) coupled with name discovery protocol on top of it.  It just needs a bit more testing before going upstream.  I did an short series tests so far and it was really cool to see it working with a demo whiteboard app.

---
Alex

On Feb 13, 2017, at 2:06 AM, Wissingh, B.F. (Bastiaan) <bastiaan.wissingh at tno.nl<mailto:bastiaan.wissingh at tno.nl>> wrote:

Hi,

We are currently looking into using nfd-android for some IoT experiments, for which we would like to use either WiFi in Ad-Hoc mode or Bluetooth to connect between different NDN based devices. So far however, it seems difficult to impossible to use Android devices in WiFi Ad-Hoc mode (without flashing a non-stock rom).

So we were wondering whether any of you has experience with using nfd-android via either Bluetooth (is that implemented within nfd-android?) or WiFi Ad-Hoc.

Looking forward to a reply,

Best regards,
Bastiaan Wissingh



B.F. (Bastiaan) Wissingh MSc
Research Scientist Media Networking
Department of Networks

T +31 (0)88 866 42 52
M +31 (0)65 280 35 59
E bastiaan.wissingh at tno.nl<mailto:bastiaan.wissingh at tno.nl>

Location<http://www.tno.nl/locaties/DHA>



<image001.png><http://www.tno.nl/>

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.



_______________________________________________
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/20170214/fa89e22f/attachment-0001.html>

From Matteo.Bertolino at eurecom.fr  Tue Feb 14 02:13:47 2017
From: Matteo.Bertolino at eurecom.fr (Matteo Bertolino)
Date: Tue, 14 Feb 2017 11:13:47 +0100
Subject: [Nfd-dev] how to disable the ContentStore?
Message-ID: <20170214111347.x8xzwgq8gcw4k08w@webmail.eurecom.fr>

Good morning,
I realize that my question is really trivial, but I would like to  
disable the CS on a node.
Should I write in the node.conf simply
cs_max_packets 0 ?
Or am I getting wrong?

In alternative, how can a producer forbid a packet to be cached?
Should I set the freshnessPeriod to 0?

Thanks,

Matteo

-------------------------------------------------------------------------------
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr


From shijunxiao at email.arizona.edu  Tue Feb 14 04:21:53 2017
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Tue, 14 Feb 2017 12:21:53 +0000
Subject: [Nfd-dev] how to disable the ContentStore?
In-Reply-To: <20170214111347.x8xzwgq8gcw4k08w@webmail.eurecom.fr>
References: <20170214111347.x8xzwgq8gcw4k08w@webmail.eurecom.fr>
Message-ID: <CAOFH+OaC8DgYv6tAsm8Ws4w0At_THA1Li2AkErG0fg+CAeTcmA@mail.gmail.com>

Hi Matteo

I would like to disable the CS on a node.
> Should I write in the node.conf simply cs_max_packets 0 ?

Yes.

how can a producer forbid a packet to be cached?
> Should I set the freshnessPeriod to 0?

FreshnessPeriod=0 still allows the Data to be cached, but it cannot satisfy
any Interest with MustBeFresh selector.
CachePolicy=NoCache in NDNLPv2 header (implemented as
ndn::lp::CachePolicyTag in ndn-cxx) forbids local NFD to cache a Data, but
other NFD can still cache it.

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

From peter at remap.UCLA.EDU  Tue Feb 14 18:03:44 2017
From: peter at remap.UCLA.EDU (Gusev, Peter)
Date: Wed, 15 Feb 2017 02:03:44 +0000
Subject: [Nfd-dev] Quick question - onIncomingData called twice
Message-ID: <EA405E2C-4CFD-4065-822F-5CD294B4719E@remap.ucla.edu>

Hi devs,

In the NFD log, I observe:

1487122986.473758 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/test/testJoin/user1/730551A4-70CC-4DBB-90C1-031488B8592A/about/data/_meta
1487122986.474156 DEBUG: [ContentStore] find /test/testJoin/user1/730551A4-70CC-4DBB-90C1-031488B8592A/about/data/_meta L
1487122986.474518 DEBUG: [Forwarder] onContentStoreMiss interest=/test/testJoin/user1/730551A4-70CC-4DBB-90C1-031488B8592A/about/data/_meta
1487122986.474833 DEBUG: [Forwarder] onOutgoingInterest face=265 interest=/test/testJoin/user1/730551A4-70CC-4DBB-90C1-031488B8592A/about/data/_meta
1487122986.475167 DEBUG: [BestRouteStrategy2] /test/testJoin/user1/730551A4-70CC-4DBB-90C1-031488B8592A/about/data/_meta?ndn.MustBeFresh=1&ndn.Nonce=273900197 from=266 newPitEntry-to=265
1487122986.475544 DEBUG: [Forwarder] onIncomingData face=265 data=/test/testJoin/user1/730551A4-70CC-4DBB-90C1-031488B8592A/about/data/_meta
1487122986.475841 DEBUG: [ContentStore] insert /test/testJoin/user1/730551A4-70CC-4DBB-90C1-031488B8592A/about/data/_meta
1487122986.476144 DEBUG: [Forwarder] onIncomingData matching=/test/testJoin/user1/730551A4-70CC-4DBB-90C1-031488B8592A/about/data/_meta
1487122986.476418 DEBUG: [Strategy] beforeSatisfyInterest pitEntry=/test/testJoin/user1/730551A4-70CC-4DBB-90C1-031488B8592A/about/data/_meta inFace=265 data=/test/testJoin/user1/730551A4-70CC-4DBB-90C1-031488B8592A/about/data/_meta
1487122986.477014 DEBUG: [Forwarder] onOutgoingData face=266 data=/test/testJoin/user1/730551A4-70CC-4DBB-90C1-031488B8592A/about/data/_meta
1487122986.477350 DEBUG: [Forwarder] onIncomingData face=265 data=/test/testJoin/user1/730551A4-70CC-4DBB-90C1-031488B8592A/about/data/_meta
1487122986.477667 DEBUG: [ContentStore] insert /test/testJoin/user1/730551A4-70CC-4DBB-90C1-031488B8592A/about/data/_meta
1487122986.478023 DEBUG: [Forwarder] onIncomingData matching=/test/testJoin/user1/730551A4-70CC-4DBB-90C1-031488B8592A/about/data/_meta
1487122986.478559 DEBUG: [Strategy] beforeSatisfyInterest pitEntry=/test/testJoin/user1/730551A4-70CC-4DBB-90C1-031488B8592A/about/data/_meta inFace=265 data=/test/testJoin/user1/730551A4-70CC-4DBB-90C1-031488B8592A/about/data/_meta

highlighted are two identical entries - does it mean NFD is getting data twice?
could it be application?s fault (i.e. it pushes data two times instead of just one)?

Thanks,

--
Peter Gusev

peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>
+1 213 5872748
peetonn_ (skype)

Software Engineer/Programmer Analyst @ REMAP UCLA

Video streaming/ICN networks/Creative Development

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

From aa at CS.UCLA.EDU  Tue Feb 14 18:35:35 2017
From: aa at CS.UCLA.EDU (Alex Afanasyev)
Date: Tue, 14 Feb 2017 18:35:35 -0800
Subject: [Nfd-dev] Quick question - onIncomingData called twice
In-Reply-To: <EA405E2C-4CFD-4065-822F-5CD294B4719E@remap.ucla.edu>
References: <EA405E2C-4CFD-4065-822F-5CD294B4719E@remap.ucla.edu>
Message-ID: <45788038-29AE-40B3-89BC-41603F8C0DB7@cs.ucla.edu>

On Feb 14, 2017, at 6:03 PM, Gusev, Peter <peter at remap.ucla.edu> wrote:
> 
> Hi devs,
> 
> In the NFD log, I observe:
> 
> 1487122986.473758 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/test/testJoin/user1/730551A4-70CC-4DBB-90C1-031488B8592A/about/data/_meta
> 1487122986.474156 DEBUG: [ContentStore] find /test/testJoin/user1/730551A4-70CC-4DBB-90C1-031488B8592A/about/data/_meta L
> 1487122986.474518 DEBUG: [Forwarder] onContentStoreMiss interest=/test/testJoin/user1/730551A4-70CC-4DBB-90C1-031488B8592A/about/data/_meta
> 1487122986.474833 DEBUG: [Forwarder] onOutgoingInterest face=265 interest=/test/testJoin/user1/730551A4-70CC-4DBB-90C1-031488B8592A/about/data/_meta
> 1487122986.475167 DEBUG: [BestRouteStrategy2] /test/testJoin/user1/730551A4-70CC-4DBB-90C1-031488B8592A/about/data/_meta?ndn.MustBeFresh=1&ndn.Nonce=273900197 from=266 newPitEntry-to=265
> 1487122986.475544 DEBUG: [Forwarder] onIncomingData face=265 data=/test/testJoin/user1/730551A4-70CC-4DBB-90C1-031488B8592A/about/data/_meta
> 1487122986.475841 DEBUG: [ContentStore] insert /test/testJoin/user1/730551A4-70CC-4DBB-90C1-031488B8592A/about/data/_meta
> 1487122986.476144 DEBUG: [Forwarder] onIncomingData matching=/test/testJoin/user1/730551A4-70CC-4DBB-90C1-031488B8592A/about/data/_meta
> 1487122986.476418 DEBUG: [Strategy] beforeSatisfyInterest pitEntry=/test/testJoin/user1/730551A4-70CC-4DBB-90C1-031488B8592A/about/data/_meta inFace=265 data=/test/testJoin/user1/730551A4-70CC-4DBB-90C1-031488B8592A/about/data/_meta
> 1487122986.477014 DEBUG: [Forwarder] onOutgoingData face=266 data=/test/testJoin/user1/730551A4-70CC-4DBB-90C1-031488B8592A/about/data/_meta
> 1487122986.477350 DEBUG: [Forwarder] onIncomingData face=265 data=/test/testJoin/user1/730551A4-70CC-4DBB-90C1-031488B8592A/about/data/_meta
> 1487122986.477667 DEBUG: [ContentStore] insert /test/testJoin/user1/730551A4-70CC-4DBB-90C1-031488B8592A/about/data/_meta
> 1487122986.478023 DEBUG: [Forwarder] onIncomingData matching=/test/testJoin/user1/730551A4-70CC-4DBB-90C1-031488B8592A/about/data/_meta
> 1487122986.478559 DEBUG: [Strategy] beforeSatisfyInterest pitEntry=/test/testJoin/user1/730551A4-70CC-4DBB-90C1-031488B8592A/about/data/_meta inFace=265 data=/test/testJoin/user1/730551A4-70CC-4DBB-90C1-031488B8592A/about/data/_meta
> 
> highlighted are two identical entries - does it mean NFD is getting data twice?
> could it be application?s fault (i.e. it pushes data two times instead of just one)?

I looks like it.  After the first data packet, the inFace records in PIT entry will be removed, but PIT entry itself will be kept for a bit.  The second received data gets processed, but not forwarded downstream, as there are no more in records.

--
Alex

> 
> Thanks, 
> 
> -- 
> Peter Gusev
> 
> peter at remap.ucla.edu <mailto:peter at remap.ucla.edu>
> +1 213 5872748
> peetonn_ (skype)
> 
> Software Engineer/Programmer Analyst @ REMAP UCLA
> 
> Video streaming/ICN networks/Creative Development
> 
> _______________________________________________
> 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/20170214/bba94fbd/attachment-0001.html>

From agawande at memphis.edu  Wed Feb 15 00:00:14 2017
From: agawande at memphis.edu (Ashlesh Gawande (agawande))
Date: Wed, 15 Feb 2017 08:00:14 +0000
Subject: [Nfd-dev] how to disable the ContentStore?
In-Reply-To: <CAOFH+OaC8DgYv6tAsm8Ws4w0At_THA1Li2AkErG0fg+CAeTcmA@mail.gmail.com>
References: <20170214111347.x8xzwgq8gcw4k08w@webmail.eurecom.fr>,
	<CAOFH+OaC8DgYv6tAsm8Ws4w0At_THA1Li2AkErG0fg+CAeTcmA@mail.gmail.com>
Message-ID: <BN3PR04MB2196C9DE8428B10AF7957F12D95B0@BN3PR04MB2196.namprd04.prod.outlook.com>

I tried to test the NoCache CachePolicy with producer and consumer as follows:


1) At line <https://github.com/named-data/ndn-cxx/blob/master/examples/producer.cpp#L68> https://github.com/named-data/ndn-cxx/blob/a341ae80b555fb1a1c4b2738e5dddcfbbcdf77fc/examples/producer.cpp#L68
 I added:


ndn::lp::CachePolicy cachePolicy;
cachePolicy.setPolicy(ndn::lp::CachePolicyType::NO_CACHE);
data->setTag(std::make_shared<ndn::lp::CachePolicyTag>(cachePolicy));

Consumer example was used as it is (must be fresh is set to true).

Started NFD and ran the producer. Then ran the consumer on the same machine and got the data back.
Then I killed the producer and re-ran the consumer. I still got the data back.
Only after the freshness period of data (10 seconds) did I stop receiving data from NFD and got a NoRoute Nack.

Is this not how NoCache policy is supposed to work? Am I doing something wrong?

Thanks
Ashlesh

________________________________
From: Nfd-dev <nfd-dev-bounces at lists.cs.ucla.edu> on behalf of Junxiao Shi <shijunxiao at email.arizona.edu>
Sent: Tuesday, February 14, 2017 6:21:53 AM
To: Matteo Bertolino; nfd-dev at lists.cs.ucla.edu
Subject: Re: [Nfd-dev] how to disable the ContentStore?

Hi Matteo

I would like to disable the CS on a node.
Should I write in the node.conf simply cs_max_packets 0 ?
Yes.

how can a producer forbid a packet to be cached?
Should I set the freshnessPeriod to 0?
FreshnessPeriod=0 still allows the Data to be cached, but it cannot satisfy any Interest with MustBeFresh selector.
CachePolicy=NoCache in NDNLPv2 header (implemented as ndn::lp::CachePolicyTag in ndn-cxx) forbids local NFD to cache a Data, but other NFD can still cache it.

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

From nfd-call-notification at mail1.yoursunny.com  Wed Feb 15 08:00:02 2017
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Wed, 15 Feb 2017 09:00:02 -0700
Subject: [Nfd-dev] NFD call 20170215
Message-ID: <201702151600.v1FG024k029665@lectura.cs.arizona.edu>

An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20170215/2b082aab/attachment.html>

From klaus at cs.arizona.EDU  Wed Feb 15 10:29:07 2017
From: klaus at cs.arizona.EDU (Klaus Schneider)
Date: Wed, 15 Feb 2017 11:29:07 -0700
Subject: [Nfd-dev] how to disable the ContentStore?
In-Reply-To: <BN3PR04MB2196C9DE8428B10AF7957F12D95B0@BN3PR04MB2196.namprd04.prod.outlook.com>
References: <20170214111347.x8xzwgq8gcw4k08w@webmail.eurecom.fr>
	<CAOFH+OaC8DgYv6tAsm8Ws4w0At_THA1Li2AkErG0fg+CAeTcmA@mail.gmail.com>
	<BN3PR04MB2196C9DE8428B10AF7957F12D95B0@BN3PR04MB2196.namprd04.prod.outlook.com>
Message-ID: <d5a107c4-9457-2244-60b6-ae45d4215262@cs.arizona.edu>

Hi Ashlesh,

Junxiao probably knows this better, but I can make a guess.

Since the cachePolicy is part of NDNLP, I can imagine that it doesn't 
work when the producer and targeted cache are on the same node (since 
there's no "link" in between).

Can you try to replicate the scenario with 3 nodes

C --- R --- P

and see if the content is cached at either R or C?

Best regards,
Klaus




On 02/15/2017 01:00 AM, Ashlesh Gawande (agawande) wrote:
> I tried to test the NoCache CachePolicy with producer and consumer as
> follows:
>
>
> 1) At
> line <https://github.com/named-data/ndn-cxx/blob/master/examples/producer.cpp#L68>https://github.com/named-data/ndn-cxx/blob/a341ae80b555fb1a1c4b2738e5dddcfbbcdf77fc/examples/producer.cpp#L68
>  I added:
>
>
> ndn::lp::CachePolicy cachePolicy;
> cachePolicy.setPolicy(ndn::lp::CachePolicyType::NO_CACHE);
> data->setTag(std::make_shared<ndn::lp::CachePolicyTag>(cachePolicy));
>
> Consumer example was used as it is (must be fresh is set to true).
>
> Started NFD and ran the producer. Then ran the consumer on the same
> machine and got the data back.
> Then I killed the producer and re-ran the consumer. I still got the data
> back.
> Only after the freshness period of data (10 seconds) did I stop
> receiving data from NFD and got a NoRoute Nack.
>
> Is this not how NoCache policy is supposed to work? Am I doing something
> wrong?
>
> Thanks
> Ashlesh
>
> ------------------------------------------------------------------------
> *From:* Nfd-dev <nfd-dev-bounces at lists.cs.ucla.edu> on behalf of Junxiao
> Shi <shijunxiao at email.arizona.edu>
> *Sent:* Tuesday, February 14, 2017 6:21:53 AM
> *To:* Matteo Bertolino; nfd-dev at lists.cs.ucla.edu
> *Subject:* Re: [Nfd-dev] how to disable the ContentStore?
>
> Hi Matteo
>
>     I would like to disable the CS on a node.
>     Should I write in the node.conf simply cs_max_packets 0 ?
>
> Yes.
>
>     how can a producer forbid a packet to be cached?
>     Should I set the freshnessPeriod to 0?
>
> FreshnessPeriod=0 still allows the Data to be cached, but it cannot
> satisfy any Interest with MustBeFresh selector.
> CachePolicy=NoCache in NDNLPv2 header (implemented as
> ndn::lp::CachePolicyTag in ndn-cxx) forbids local NFD to cache a Data,
> but other NFD can still cache it.
>
> 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  Wed Feb 15 15:08:46 2017
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Wed, 15 Feb 2017 16:08:46 -0700
Subject: [Nfd-dev] how to disable the ContentStore?
In-Reply-To: <BN3PR04MB2196C9DE8428B10AF7957F12D95B0@BN3PR04MB2196.namprd04.prod.outlook.com>
References: <20170214111347.x8xzwgq8gcw4k08w@webmail.eurecom.fr>
	<CAOFH+OaC8DgYv6tAsm8Ws4w0At_THA1Li2AkErG0fg+CAeTcmA@mail.gmail.com>
	<BN3PR04MB2196C9DE8428B10AF7957F12D95B0@BN3PR04MB2196.namprd04.prod.outlook.com>
Message-ID: <CAOFH+OY+ZSMBT5bc7cecD8LJWNEG5ADm6kY8nG-7_q8EZ_tL3A@mail.gmail.com>

Hi Ashlesh

Your producer code is correct.
It does not work due to NFD Bug 3966
<https://redmine.named-data.net/issues/3966>. You may watch the issue on
Redmine, and try again when it's resolved.

Yours, Junxiao

On Wed, Feb 15, 2017 at 1:00 AM, Ashlesh Gawande (agawande) <
agawande at memphis.edu> wrote:

> I tried to test the NoCache CachePolicy with producer and consumer as
> follows:
>
> 1) At line
> <https://github.com/named-data/ndn-cxx/blob/master/examples/producer.cpp#L68>
> https://github.com/named-data/ndn-cxx/blob/a341ae80b555fb1a1c4b2738e5dddc
> fbbcdf77fc/examples/producer.cpp#L68
>  I added:
>
> ndn::lp::CachePolicy cachePolicy;
> cachePolicy.setPolicy(ndn::lp::CachePolicyType::NO_CACHE);
> data->setTag(std::make_shared<ndn::lp::CachePolicyTag>(cachePolicy));
>
> Consumer example was used as it is (must be fresh is set to true).
>
> Started NFD and ran the producer. Then ran the consumer on the same
> machine and got the data back.
> Then I killed the producer and re-ran the consumer. I still got the data
> back.
> Only after the freshness period of data (10 seconds) did I stop receiving
> data from NFD and got a NoRoute Nack.
>
> Is this not how NoCache policy is supposed to work? Am I doing something
> wrong?
>
> Thanks
> Ashlesh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20170215/ba579720/attachment.html>

From aa at CS.UCLA.EDU  Fri Feb 17 17:57:14 2017
From: aa at CS.UCLA.EDU (Alex Afanasyev)
Date: Fri, 17 Feb 2017 17:57:14 -0800 (PST)
Subject: [Nfd-dev] [CFP] ACM ICN 2017 - Poster and Demos
Message-ID: <58a7a9fa.58af630a.beb6d.3011@mx.google.com>

ACM ICN 2017 - CALL FOR POSTERS AND DEMOS
4th ACM Conference on Information-Centric Networking
Berlin, Germany on Sep. 26-28, 2017
http://conferences2.sigcomm.org/acm-icn/2017/cf-posters-and-demos.html

=========================================================

The ICN poster and demo sessions are intended to showcase works-in-progress. Topics of interest are the same as those listed in the main track call for papers. We strongly encourage both student and industry submissions. Both demos and posters should be accompanied by a two-page extended abstract, which will be published in the conference proceedings.

We specifically encourage submissions of posters and demos that are accompanied with datasets. Such submissions will have a preferential treatment during the review and will be eligible for special awards. The aim is to collect and share datasets that can hopefully become a common ground for evaluation in the ICN community.

The posters and demos submitted to ACM ICN 2017 must be original and cannot be concurrently submitted to other workshops or conferences during the ACM ICN 2017 poster/demo review period. All dual submissions will be rejected without review.

WHY SHOULD YOU SUBMIT A POSTER OR A DEMO?

Presenting a poster is a great opportunity, especially for students, to obtain interesting and valuable feedback on ongoing research from a knowledgeable crowd at the conference. Accepted posters and demos will be published as a two-page abstract for the archived conference proceedings. Students who are submitting posters are highly encouraged to examine if they are eligible for student travel grants.

MORE DETAILS

http://conferences2.sigcomm.org/acm-icn/2017/cf-posters-and-demos.html

=========================================================
IMPORTANT DATES

Submission Deadline:     July 9, 2017 12am EDT
Acceptance Notification: March 1, 2017
Camera Ready Due:        August 21, 2017
=========================================================

From nfd-call-notification at mail1.yoursunny.com  Mon Feb 20 08:00:02 2017
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Mon, 20 Feb 2017 09:00:02 -0700
Subject: [Nfd-dev] NFD call 20170220
Message-ID: <201702201600.v1KG02OI011937@lectura.cs.arizona.edu>

An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20170220/a383cab8/attachment.html>

From nmgordon at memphis.edu  Tue Feb 21 11:03:03 2017
From: nmgordon at memphis.edu (Nick Gordon)
Date: Tue, 21 Feb 2017 13:03:03 -0600
Subject: [Nfd-dev] AutoPrefixPropagator inside mini-NDN
Message-ID: <fcea8400-4590-8e6a-b52c-4beda4028e99@memphis.edu>

I'm developing an integration test to verify that Readvertise works in
conjunction with AutoPrefixPropagator. However, I can't get
AutoPrefixPropagator to work.

I've followed the step's on Junxiao's blog to the T, and I verify that
the propagation target router is receiving the interest, but it is
rejecting them. Why it is rejecting them, I don't know, because I have
set both localhost and localhop security off (i.e. to "trust-anchor any").

Anyone have any suggestions about this?

From lanwang at memphis.edu  Tue Feb 21 13:49:58 2017
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Tue, 21 Feb 2017 21:49:58 +0000
Subject: [Nfd-dev] AutoPrefixPropagator inside mini-NDN
In-Reply-To: <fcea8400-4590-8e6a-b52c-4beda4028e99@memphis.edu>
References: <fcea8400-4590-8e6a-b52c-4beda4028e99@memphis.edu>
Message-ID: <727DAAA1-8B55-4ED0-83E1-A897341C0A43@memphis.edu>

Maybe a little more information would help.  What?s the name of the key that signed the interest from the node to the hub?  Does the router have the route in its FIB to retrieve that key?

Lan

On Feb 21, 2017, at 1:03 PM, Nick Gordon <nmgordon at memphis.edu<mailto:nmgordon at memphis.edu>> wrote:

I'm developing an integration test to verify that Readvertise works in
conjunction with AutoPrefixPropagator. However, I can't get
AutoPrefixPropagator to work.

I've followed the step's on Junxiao's blog to the T, and I verify that
the propagation target router is receiving the interest, but it is
rejecting them. Why it is rejecting them, I don't know, because I have
set both localhost and localhop security off (i.e. to "trust-anchor any").

Anyone have any suggestions about this?
_______________________________________________
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/20170221/9e9a6e53/attachment.html>

From jdd at wustl.edu  Tue Feb 21 13:51:51 2017
From: jdd at wustl.edu (Dehart, John)
Date: Tue, 21 Feb 2017 21:51:51 +0000
Subject: [Nfd-dev] AutoPrefixPropagator inside mini-NDN
In-Reply-To: <727DAAA1-8B55-4ED0-83E1-A897341C0A43@memphis.edu>
References: <fcea8400-4590-8e6a-b52c-4beda4028e99@memphis.edu>
	<727DAAA1-8B55-4ED0-83E1-A897341C0A43@memphis.edu>
Message-ID: <7E0FC88A-C735-4394-9C78-1E56361E4168@wustl.edu>

Nick,

Do you have any nfd log messages?

John

On Feb 21, 2017, at 3:49 PM, Lan Wang (lanwang) <lanwang at memphis.edu<mailto:lanwang at memphis.edu>> wrote:

Maybe a little more information would help.  What?s the name of the key that signed the interest from the node to the hub?  Does the router have the route in its FIB to retrieve that key?

Lan

On Feb 21, 2017, at 1:03 PM, Nick Gordon <nmgordon at memphis.edu<mailto:nmgordon at memphis.edu>> wrote:

I'm developing an integration test to verify that Readvertise works in
conjunction with AutoPrefixPropagator. However, I can't get
AutoPrefixPropagator to work.

I've followed the step's on Junxiao's blog to the T, and I verify that
the propagation target router is receiving the interest, but it is
rejecting them. Why it is rejecting them, I don't know, because I have
set both localhost and localhop security off (i.e. to "trust-anchor any").

Anyone have any suggestions about this?
_______________________________________________
Nfd-dev mailing list
Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

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

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

From nmgordon at memphis.edu  Tue Feb 21 14:04:24 2017
From: nmgordon at memphis.edu (Nick Gordon)
Date: Tue, 21 Feb 2017 16:04:24 -0600
Subject: [Nfd-dev] AutoPrefixPropagator inside mini-NDN
In-Reply-To: <727DAAA1-8B55-4ED0-83E1-A897341C0A43@memphis.edu>
References: <fcea8400-4590-8e6a-b52c-4beda4028e99@memphis.edu>
	<727DAAA1-8B55-4ED0-83E1-A897341C0A43@memphis.edu>
Message-ID: <ef6c51b4-c5fe-b3c2-aaff-7735051ad5ae@memphis.edu>

It's signed following Junxiao's instructions:

1. Generate the key, here "/ndn/endhost"
2. Export that key as a certificate
3. Import that key into the hub router (router1)
4. Restart NFD on router1

So that hub router has the key in the keychain. I'm not sure if this
circumvents the signature verification.

John,

I have lots of NFD logs, but I'm not very skilled at reading them. What
I see is that the strategy shows this:

1487713935.381784 DEBUG: [BestRouteStrategy2]
/localhop/nfd/rib/register/h%19%07%0E%08%03ndn%08%07endhosti%01%00o%01Aj%01%0F/%00%00%01Zb%A9%20%05/%EA%1E%E1%2A%AFm%C8A/%166%1B%01%01%1C1%07%2F%08%03ndn%08%07endhost%08%03KEY%08%11ksk-1487713107245%08%07ID-CERT/%17%FD%01%00%05%19%B3%C68%DC%F8L%B5e%FC%E6%EF%9C%B5%14%B8%BF%CA%BC%FFM%3E%D7%C9z%2A%3BVz%8B%A5Q%81%CA%9Fsf%997%AFZ3%5D%FD%E1%2Aj%A6%A6%23%7Bj%A6R%E2F%82J%92%14%7B%92%BE%C6%902%40%AB%26%1C%83%07%01%12%A9%8Bn%07%F3Tl%0D%D6%98d%ED%A2F%0C%12%EBB-C%B0_%5B%86%B0%9D%3ED8%B47%83s%3C%0BMH%5E%FF%7C%13UtY%95%90%0F%CFm%F2%ECPm%CEj%2F%D8%94%07%C1%7D%28%DA%97%B1%A1%C5s%97%3A%C3%CE%91%29%EB%23A1l4X0Q%AD%05%0F%98e%B1qa%D0%A7Dh%B0%CD%FDw%C2%9E%09%FA%DD%F1%DF%D5%A5%C1%A8%3E%93%E8%11%85%BE%19rg6%DE%A6o%1B%C4E%C1%9F%E6H3N%60%1B%14Y%AE%BD%24%0F%82%0A9l%BC%B0%AF%19%EAzFJs%D6%2A%F0gM%D7%D6%A2%D6%FA%151%07%08G%EDUYPO%0F%12%E7%AFm%A3%9E%B8?ndn.InterestLifetime=10000&ndn.Nonce=763432487
from=265 noNextHop

I see that the end there shows no nexthops. I don't fully understand
this, because isn't that what the register command, which is from
AutoPrefixPropagator, is doing? Saying that "on this Face, you can reach
this prefix"? Do I have to do some other kind of configuration on router1?

-Nick

On 02/21/2017 03:49 PM, Lan Wang (lanwang) wrote:
> Maybe a little more information would help.  What?s the name of the key
> that signed the interest from the node to the hub?  Does the router have
> the route in its FIB to retrieve that key?
> 
> Lan
> 
>> On Feb 21, 2017, at 1:03 PM, Nick Gordon <nmgordon at memphis.edu
>> <mailto:nmgordon at memphis.edu>> wrote:
>>
>> I'm developing an integration test to verify that Readvertise works in
>> conjunction with AutoPrefixPropagator. However, I can't get
>> AutoPrefixPropagator to work.
>>
>> I've followed the step's on Junxiao's blog to the T, and I verify that
>> the propagation target router is receiving the interest, but it is
>> rejecting them. Why it is rejecting them, I don't know, because I have
>> set both localhost and localhop security off (i.e. to "trust-anchor any").
>>
>> Anyone have any suggestions about this?
>> _______________________________________________
>> 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
> 

From lanwang at memphis.edu  Tue Feb 21 14:09:32 2017
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Tue, 21 Feb 2017 22:09:32 +0000
Subject: [Nfd-dev] AutoPrefixPropagator inside mini-NDN
In-Reply-To: <ef6c51b4-c5fe-b3c2-aaff-7735051ad5ae@memphis.edu>
References: <fcea8400-4590-8e6a-b52c-4beda4028e99@memphis.edu>
	<727DAAA1-8B55-4ED0-83E1-A897341C0A43@memphis.edu>
	<ef6c51b4-c5fe-b3c2-aaff-7735051ad5ae@memphis.edu>
Message-ID: <DE738D7A-6A5A-4317-BA1A-5869BB730EA3@memphis.edu>



> On Feb 21, 2017, at 4:04 PM, Nicholas Michael Gordon (nmgordon) <nmgordon at memphis.edu> wrote:
> 
> It's signed following Junxiao's instructions:
> 
> 1. Generate the key, here "/ndn/endhost"
> 2. Export that key as a certificate
> 3. Import that key into the hub router (router1)
> 4. Restart NFD on router1
> 
> So that hub router has the key in the keychain. I'm not sure if this
> circumvents the signature verification.
> 
> John,
> 
> I have lots of NFD logs, but I'm not very skilled at reading them. What
> I see is that the strategy shows this:
> 
> 1487713935.381784 DEBUG: [BestRouteStrategy2]
> /localhop/nfd/rib/register/h%19%07%0E%08%03ndn%08%07endhosti%01%00o%01Aj%01%0F/%00%00%01Zb%A9%20%05/%EA%1E%E1%2A%AFm%C8A/%166%1B%01%01%1C1%07%2F%08%03ndn%08%07endhost%08%03KEY%08%11ksk-1487713107245%08%07ID-CERT/%17%FD%01%00%05%19%B3%C68%DC%F8L%B5e%FC%E6%EF%9C%B5%14%B8%BF%CA%BC%FFM%3E%D7%C9z%2A%3BVz%8B%A5Q%81%CA%9Fsf%997%AFZ3%5D%FD%E1%2Aj%A6%A6%23%7Bj%A6R%E2F%82J%92%14%7B%92%BE%C6%902%40%AB%26%1C%83%07%01%12%A9%8Bn%07%F3Tl%0D%D6%98d%ED%A2F%0C%12%EBB-C%B0_%5B%86%B0%9D%3ED8%B47%83s%3C%0BMH%5E%FF%7C%13UtY%95%90%0F%CFm%F2%ECPm%CEj%2F%D8%94%07%C1%7D%28%DA%97%B1%A1%C5s%97%3A%C3%CE%91%29%EB%23A1l4X0Q%AD%05%0F%98e%B1qa%D0%A7Dh%B0%CD%FDw%C2%9E%09%FA%DD%F1%DF%D5%A5%C1%A8%3E%93%E8%11%85%BE%19rg6%DE%A6o%1B%C4E%C1%9F%E6H3N%60%1B%14Y%AE%BD%24%0F%82%0A9l%BC%B0%AF%19%EAzFJs%D6%2A%F0gM%D7%D6%A2%D6%FA%151%07%08G%EDUYPO%0F%12%E7%AFm%A3%9E%B8?ndn.InterestLifetime=10000&ndn.Nonce=763432487
> from=265 noNextHop
> 
> I see that the end there shows no nexthops. I don't fully understand
> this, because isn't that what the register command, which is from
> AutoPrefixPropagator, is doing? Saying that "on this Face, you can reach
> this prefix"? Do I have to do some other kind of configuration on router1?

You can?t depend on the prefix registration to set up the FIB entry for the key name.  You need the key to verify that prefix registration command.

On the other hand, looks like you are trying to store the key locally at the router (importing the key into the hub router?), so the router should be able to find the key and its certificate locally.  Something is not right if it can?t find the key locally.

Lan
> 
> -Nick
> 
> On 02/21/2017 03:49 PM, Lan Wang (lanwang) wrote:
>> Maybe a little more information would help.  What?s the name of the key
>> that signed the interest from the node to the hub?  Does the router have
>> the route in its FIB to retrieve that key?
>> 
>> Lan
>> 
>>> On Feb 21, 2017, at 1:03 PM, Nick Gordon <nmgordon at memphis.edu
>>> <mailto:nmgordon at memphis.edu>> wrote:
>>> 
>>> I'm developing an integration test to verify that Readvertise works in
>>> conjunction with AutoPrefixPropagator. However, I can't get
>>> AutoPrefixPropagator to work.
>>> 
>>> I've followed the step's on Junxiao's blog to the T, and I verify that
>>> the propagation target router is receiving the interest, but it is
>>> rejecting them. Why it is rejecting them, I don't know, because I have
>>> set both localhost and localhop security off (i.e. to "trust-anchor any").
>>> 
>>> Anyone have any suggestions about this?
>>> _______________________________________________
>>> 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
>> 



From nmgordon at memphis.edu  Tue Feb 21 15:33:39 2017
From: nmgordon at memphis.edu (Nick Gordon)
Date: Tue, 21 Feb 2017 17:33:39 -0600
Subject: [Nfd-dev] How to send command interests from NFD to NLSR?
Message-ID: <f46e90c0-d605-483a-4b6a-39d7558261fc@memphis.edu>

Second part of my problem (figured I could make use of the lists for
once...)

I'm getting a very strange crash when I issue
"nfdc register -o 65 /ndn/endhost 259", NFD on that router crashes. I'm
doing this to simulate a successful propagation into the router. My
Readvertise module seems to be doing it's job, and then the last thing
the log indicates is getting executed is:

m_controller.start<ndn::nfd::RibRegisterCommand>(ControlParameters()
                              .setName(rr.getPrefix())
                              .setOrigin(ndn::nfd::ROUTE_ORIGIN_CLIENT),
    [=] (const ControlParameters& cp) { successCb(); },
    [=] (const ControlResponse& cr) { failureCb(cr.getText()); },
    ndn::nfd::CommandOptions().setPrefix("/localhost/nlsr"));

The aim of this is to send a RibRegisterCommand, registering the prefix
"/ndn/endhost" toward /localhost/nlsr. Then, because NFD has
"/localhost/nlsr" in its FIB, it should pass it off to NLSR, which
inserts it into the NPT and away we go.

I've currently instantiated the destination with the same controller
that the RibManager has. This controller's face is created with internal
NFD face. I *don't* think this is the correct approach, but I didn't
know exactly how to send something to NLSR from NFD.

The last 50 lines of the log are in this gist:
https://gist.github.com/gorgonical/219bfa6025a76ed98f11f9c5defa9d5d

It kind of looks to me like it's putting the data on the Face, which it
then receives from that Face, and we get into some kind of loop.

 -Nick

From lanwang at memphis.edu  Tue Feb 21 16:41:05 2017
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Wed, 22 Feb 2017 00:41:05 +0000
Subject: [Nfd-dev] How to send command interests from NFD to NLSR?
In-Reply-To: <f46e90c0-d605-483a-4b6a-39d7558261fc@memphis.edu>
References: <f46e90c0-d605-483a-4b6a-39d7558261fc@memphis.edu>
Message-ID: <04775BC4-FAE5-491A-B0EB-22A55C548DCE@memphis.edu>

I may be missing something, but shouldn't NLSR just listen on that prefix /localhost/nlsr and It will receive any interest with that name (whether it is from NFD or not)

Lan (on phone)

> On Feb 21, 2017, at 5:33 PM, Nick Gordon <nmgordon at memphis.edu> wrote:
> 
> Second part of my problem (figured I could make use of the lists for
> once...)
> 
> I'm getting a very strange crash when I issue
> "nfdc register -o 65 /ndn/endhost 259", NFD on that router crashes. I'm
> doing this to simulate a successful propagation into the router. My
> Readvertise module seems to be doing it's job, and then the last thing
> the log indicates is getting executed is:
> 
> m_controller.start<ndn::nfd::RibRegisterCommand>(ControlParameters()
>                              .setName(rr.getPrefix())
>                              .setOrigin(ndn::nfd::ROUTE_ORIGIN_CLIENT),
>    [=] (const ControlParameters& cp) { successCb(); },
>    [=] (const ControlResponse& cr) { failureCb(cr.getText()); },
>    ndn::nfd::CommandOptions().setPrefix("/localhost/nlsr"));
> 
> The aim of this is to send a RibRegisterCommand, registering the prefix
> "/ndn/endhost" toward /localhost/nlsr. Then, because NFD has
> "/localhost/nlsr" in its FIB, it should pass it off to NLSR, which
> inserts it into the NPT and away we go.
> 
> I've currently instantiated the destination with the same controller
> that the RibManager has. This controller's face is created with internal
> NFD face. I *don't* think this is the correct approach, but I didn't
> know exactly how to send something to NLSR from NFD.
> 
> The last 50 lines of the log are in this gist:
> https://gist.github.com/gorgonical/219bfa6025a76ed98f11f9c5defa9d5d
> 
> It kind of looks to me like it's putting the data on the Face, which it
> then receives from that Face, and we get into some kind of loop.
> 
> -Nick
> _______________________________________________
> 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 Feb 21 16:57:41 2017
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Tue, 21 Feb 2017 17:57:41 -0700
Subject: [Nfd-dev] How to send command interests from NFD to NLSR?
In-Reply-To: <f46e90c0-d605-483a-4b6a-39d7558261fc@memphis.edu>
References: <f46e90c0-d605-483a-4b6a-39d7558261fc@memphis.edu>
Message-ID: <CAOFH+Ob=DKvSFBgWNs96_KCF=YigbqO86ndyLv13nixtQUxJ-g@mail.gmail.com>

Hi Nick

Can you include gdb 'bt full' logs, for crashes?
See http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2016-May/001748.html

On Feb 21, 2017 3:33 PM, "Nick Gordon" <nmgordon at memphis.edu> wrote:

NFD on that router crashes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20170221/84c3c0cc/attachment.html>

From shijunxiao at email.arizona.EDU  Tue Feb 21 17:16:03 2017
From: shijunxiao at email.arizona.EDU (Junxiao Shi)
Date: Tue, 21 Feb 2017 18:16:03 -0700
Subject: [Nfd-dev] AutoPrefixPropagator inside mini-NDN
In-Reply-To: <ef6c51b4-c5fe-b3c2-aaff-7735051ad5ae@memphis.edu>
References: <fcea8400-4590-8e6a-b52c-4beda4028e99@memphis.edu>
	<727DAAA1-8B55-4ED0-83E1-A897341C0A43@memphis.edu>
	<ef6c51b4-c5fe-b3c2-aaff-7735051ad5ae@memphis.edu>
Message-ID: <CAOFH+Oa_4mBD_aEzT3xZkBYy15PspMvmzJ9xs2c8TcuQLu=bUQ@mail.gmail.com>

Hi Nick

This line indicates strategy cannot finding a nexthop for
/localhop/nfd/rib/register.
Can you confirm FIB on the node where this log is captured contains
/localhop/nfd or /localhop/nfd/rib entry?
You may inspect FIB with 'nfdc fib list' command.

Yours, Junxiao

On Feb 21, 2017 2:04 PM, "Nick Gordon" <nmgordon at memphis.edu> wrote:


1487713935.381784 DEBUG: [BestRouteStrategy2]
/localhop/nfd/rib/register/h%19%07%0E%08%03ndn%08%
07endhosti%01%00o%01Aj%01%0F/%00%00%01Zb%A9%20%05/%EA%1E%E1%
2A%AFm%C8A/%166%1B%01%01%1C1%07%2F%08%03ndn%08%07endhost%08%03KEY%08%11ksk-
1487713107245%08%07ID-CERT/%17%FD%01%00%05%19%B3%C68%DC%
F8L%B5e%FC%E6%EF%9C%B5%14%B8%BF%CA%BC%FFM%3E%D7%C9z%2A%
3BVz%8B%A5Q%81%CA%9Fsf%997%AFZ3%5D%FD%E1%2Aj%A6%A6%23%
7Bj%A6R%E2F%82J%92%14%7B%92%BE%C6%902%40%AB%26%1C%83%07%
01%12%A9%8Bn%07%F3Tl%0D%D6%98d%ED%A2F%0C%12%EBB-C%B0_%5B%
86%B0%9D%3ED8%B47%83s%3C%0BMH%5E%FF%7C%13UtY%95%90%0F%CFm%
F2%ECPm%CEj%2F%D8%94%07%C1%7D%28%DA%97%B1%A1%C5s%97%3A%C3%
CE%91%29%EB%23A1l4X0Q%AD%05%0F%98e%B1qa%D0%A7Dh%B0%CD%FDw%
C2%9E%09%FA%DD%F1%DF%D5%A5%C1%A8%3E%93%E8%11%85%BE%19rg6%DE%
A6o%1B%C4E%C1%9F%E6H3N%60%1B%14Y%AE%BD%24%0F%82%0A9l%BC%B0%
AF%19%EAzFJs%D6%2A%F0gM%D7%D6%A2%D6%FA%151%07%08G%EDUYPO%0F%
12%E7%AFm%A3%9E%B8?ndn.InterestLifetime=10000&ndn.Nonce=763432487
from=265 noNextHop
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20170221/4846f389/attachment.html>

From nmgordon at memphis.edu  Tue Feb 21 19:18:10 2017
From: nmgordon at memphis.edu (Nick Gordon)
Date: Tue, 21 Feb 2017 21:18:10 -0600
Subject: [Nfd-dev] AutoPrefixPropagator inside mini-NDN
In-Reply-To: <CAOFH+Oa_4mBD_aEzT3xZkBYy15PspMvmzJ9xs2c8TcuQLu=bUQ@mail.gmail.com>
References: <fcea8400-4590-8e6a-b52c-4beda4028e99@memphis.edu>
	<727DAAA1-8B55-4ED0-83E1-A897341C0A43@memphis.edu>
	<ef6c51b4-c5fe-b3c2-aaff-7735051ad5ae@memphis.edu>
	<CAOFH+Oa_4mBD_aEzT3xZkBYy15PspMvmzJ9xs2c8TcuQLu=bUQ@mail.gmail.com>
Message-ID: <978be7b3-b07e-b012-15b7-013418466b2c@memphis.edu>

I can in fact confirm that the FIB on that router has no /localhop/nfd
entry:

mininet> router1 nfdc fib list
                          ?
FIB:
                          ?
  /localhost/nfd/rib nexthops={faceid=260 (cost=0)}
                          ?
  /ndn/router1-site/%C1.Router/cs/router1 nexthops={faceid=262 (cost=0)}
                          ?
  /ndn/router2-site/router2 nexthops={faceid=261 (cost=10)}
                          ?
  /ndn/broadcast/KEYS nexthops={faceid=262 (cost=0), faceid=261
(cost=10)}                         ?
  /localhop/ndn/NLSR/LSA nexthops={faceid=261 (cost=10)}
                          ?
  /localhop/ndn/NLSR/LSA/router1-site/%C1.Router/cs/router1
nexthops={faceid=262 (cost=0)}         ?
  /localhost/nfd nexthops={faceid=1 (cost=0)}
                          ?
  /localhop/NLSR/sync nexthops={faceid=262 (cost=0), faceid=261
(cost=10)}                         ?
  /ndn/router2-site/%C1.Router/cs/router2 nexthops={faceid=261
(cost=10)}                          ?
  /localhost/nlsr nexthops={faceid=262 (cost=0)}

I don't know if that's a problem, because I see /localhost/nfd. However,
since the strategy is looking for localhop specifically, I'm unsure.

After re-running this experiment specifically to look for this message,
I can confirm several entries like this:

1487733093.378927 DEBUG: [BestRouteStrategy2]
/localhop/nfd/rib/register/h%19%07%0E%08%03ndn%08%07endhosti%01%00o%01Aj%01%0F/%00%00%01Zc%CDs%DE/%A2%24%D2%B1%DD%3C_%02/%166%1B%01%01%1C1%07%2F%08%03ndn%08%07endhost%08%03KEY%08%11ksk-1487733015581%08%07ID-CERT/%17%FD%01%00%80%03%92cd%16%EA%DF%92%831%8B%22%FF%DE%A8%A8%A4%83%C9%16%93+%C0x%D7%2Ai%7B%15%981%1D7%94%9A%8D%FD+%D4L%E4%CC%DCs%CE%1C%80%82%01%A8%22%EBN%82%7D%C5%82%19%06%B4%8F%A8%8EG%60%2Cz%E3%7B2%F62%ED%CF%D6l%9F%24%BCH%B1%08a%AA%AA%03%89S%BC%22%F7%E96%01R%EA%3B%99r3t%A7%EA%90g%22%F2%7B%19%A3k%F4q%AF%BFs%BF%B5%86%DA%83%A7g%9AT%AC_%DBw%1BR%60%88%E0H%8As%FC%E9%11%06V%3EL%29%19%D5c%0E%0FD%E8N%BE%FF%A9j%F0UO%2Fd%CB%8E%14%92%DD%DD0%C5l%1E%B4IM%16%28%D1IZ%EE%08%C6%D5%A6%079SY%8B%08i%1Cgm%A6%DE%A2%B17%E8%0B%7E%C7%A5QO%FB%00w%CA%AF%92%7Bsq%BA%CC9w%E6%1Cev%2C0eE%F6x%CFD%15%97%60%A1%A3%60%1C%E0%E2%FD%FB%8E%9E%A2%AE%FAu%3C%27%0E%D6S%0B?ndn.InterestLifetime=10000&ndn.Nonce=419550183
from=265 noNextHop
1487733143.408247 DEBUG: [BestRouteStrategy2]
/localhop/nfd/rib/register/h%19%07%0E%08%03ndn%08%07endhosti%01%00o%01Aj%01%0F/%00%00%01Zc%CE7_/%C6%8F%C9s%B2%E8d%D4/%166%1B%01%01%1C1%07%2F%08%03ndn%08%07endhost%08%03KEY%08%11ksk-1487733015581%08%07ID-CERT/%17%FD%01%00%9Bn%F8%98%FDGOw%06%05%80%7E%7Fn%00%AE%C6A%7E%C7C3%80%B9%81%29b%17Y%F3%AF%9D%D2%B3%04%EEM%E6%7EO-%22%FD%21%E9%DA4%1D%1A%92%7B%B7h+%B5%04%85W%EC%98%8Df%87%9C%97%1C%B0%0F%FAy%AFo%8A%C9%88%5E%06%DE%7CF%81%22%096%10%91%A7K%21%BFt%E5%8Aj%17%A1%84%24%87yH%1C%00%93%B5T%84%0A%9BN%D7%20%E5%C0iM%A7C%B1%C8%AA%AA%E3%FC%BD%14t%FD%26xk%B0%3B%B2%BB%04y%F7-%9C%3EW%21%FEn%03%0E5%ED%86%8F%9D%81%AD%2F%CBk%1F%DA%92%DDh%DBL%08%10%AC%92%2C%C7mmS%F1%15%84%99%01%2A%94%A4%AC%D7D%03%E4%F8dV%BFz%B9%BA%7E%00%AF%16%F1%06%055%5E%C9%3A%9Dc%88%7B%C0%84%D9%F1%18%9CM%DE%25%27%22+%EC%FB%0E%F3%C7vgkVMb%3F%B0%EC%CCO%A7%C6%A4%E0%5E%12%C3%7EU%96%C1%01%C9%9C%25%CB%B7u%AFj?ndn.InterestLifetime=10000&ndn.Nonce=556154061
from=265 noNextHop
1487733243.438657 DEBUG: [BestRouteStrategy2]
/localhop/nfd/rib/register/h%19%07%0E%08%03ndn%08%07endhosti%01%00o%01Aj%01%0F/%00%00%01Zc%CF%BE%1E/%7DN%20K%18%99g%24/%166%1B%01%01%1C1%07%2F%08%03ndn%08%07endhost%08%03KEY%08%11ksk-1487733015581%08%07ID-CERT/%17%FD%01%00%84%B2%D4%DC%CAI%A7%ABW%A8%9E%40%86f%C3%9F%1B8%3Cc%3Fo%3B%D893%E4%94%EA%84T.%88%FF%992K%00%3E%0C%EF%D7%17%E98%F0k%E3%C5U%D8%CC%85%D6%04%03%A4%88%FC%81w%85%B4%CB%BF%27%AF%CF%95%B5%8Du%D5l%8B%BF%C7%E1%FD%F3H4%98u%20%5E%A3%91%DC%21%9E%2C%8D%7B%C9%DF%C8%D6%87%A8%99%1F%29%CA%F8%9D%21gc%B9%3C%7F%22f%E9%FC%D5%0EC%B4_%0EgH%C1%B8A%26%A7%E1%3E%94%A8%18%B5%8Cw%23%B4%B6%10%A4%F2%BF%CFkX%A1S%7F%A4%5E%CCl%1Be%88j%C5%98t%9F%0FNA%CD%25%E1%5E%E2+%93%CB%2Fm%11%D9%E9%5DQ%24%14Sp%1DS%B9%E3%FB%CALu%D4%99A%C7%B7W+%16%10%14%FF%97%7F%CC%05CA%14%FF%9A%FA%7Df%9F%BA%3A%0E%C0%B8%80%25%E2%97%AAZ%B5K%0A%BA%8D%85%07%E25%3B%044n%D5%26%2A%88Q%23%86%8C%17%0D%EBYQ%40%EF%19?ndn.InterestLifetime=10000&ndn.Nonce=2733607158
from=265 noNextHop

On 02/21/2017 07:16 PM, Junxiao Shi wrote:
> Hi Nick
> 
> This line indicates strategy cannot finding a nexthop for
> /localhop/nfd/rib/register.
> Can you confirm FIB on the node where this log is captured contains
> /localhop/nfd or /localhop/nfd/rib entry?
> You may inspect FIB with 'nfdc fib list' command.
> 
> Yours, Junxiao
> 
> On Feb 21, 2017 2:04 PM, "Nick Gordon" <nmgordon at memphis.edu
> <mailto:nmgordon at memphis.edu>> wrote:
> 
> 
>     1487713935.381784 DEBUG: [BestRouteStrategy2]
>     /localhop/nfd/rib/register/h%19%07%0E%08%03ndn%08%07endhosti%01%00o%01Aj%01%0F/%00%00%01Zb%A9%20%05/%EA%1E%E1%2A%AFm%C8A/%166%1B%01%01%1C1%07%2F%08%03ndn%08%07endhost%08%03KEY%08%11ksk-1487713107245%08%07ID-CERT/%17%FD%01%00%05%19%B3%C68%DC%F8L%B5e%FC%E6%EF%9C%B5%14%B8%BF%CA%BC%FFM%3E%D7%C9z%2A%3BVz%8B%A5Q%81%CA%9Fsf%997%AFZ3%5D%FD%E1%2Aj%A6%A6%23%7Bj%A6R%E2F%82J%92%14%7B%92%BE%C6%902%40%AB%26%1C%83%07%01%12%A9%8Bn%07%F3Tl%0D%D6%98d%ED%A2F%0C%12%EBB-C%B0_%5B%86%B0%9D%3ED8%B47%83s%3C%0BMH%5E%FF%7C%13UtY%95%90%0F%CFm%F2%ECPm%CEj%2F%D8%94%07%C1%7D%28%DA%97%B1%A1%C5s%97%3A%C3%CE%91%29%EB%23A1l4X0Q%AD%05%0F%98e%B1qa%D0%A7Dh%B0%CD%FDw%C2%9E%09%FA%DD%F1%DF%D5%A5%C1%A8%3E%93%E8%11%85%BE%19rg6%DE%A6o%1B%C4E%C1%9F%E6H3N%60%1B%14Y%AE%BD%24%0F%82%0A9l%BC%B0%AF%19%EAzFJs%D6%2A%F0gM%D7%D6%A2%D6%FA%151%07%08G%EDUYPO%0F%12%E7%AFm%A3%9E%B8?ndn.InterestLifetime=10000&ndn.Nonce=763432487
>     from=265 noNextHop
> 

From nmgordon at memphis.edu  Tue Feb 21 20:41:03 2017
From: nmgordon at memphis.edu (Nick Gordon)
Date: Tue, 21 Feb 2017 22:41:03 -0600
Subject: [Nfd-dev] How to send command interests from NFD to NLSR?
In-Reply-To: <CAOFH+Ob=DKvSFBgWNs96_KCF=YigbqO86ndyLv13nixtQUxJ-g@mail.gmail.com>
References: <f46e90c0-d605-483a-4b6a-39d7558261fc@memphis.edu>
	<CAOFH+Ob=DKvSFBgWNs96_KCF=YigbqO86ndyLv13nixtQUxJ-g@mail.gmail.com>
Message-ID: <017ea291-caea-81b3-9706-256e8715b647@memphis.edu>

Junxiao,

I can only post the top #13 calls, because if I ask for more, it loops infinitely for some reason in gdb. However, I have those, and the
problem is in this code:

void
ReadvertisedRoute::scheduleRetryEvent(RetryState state, time::milliseconds delay,
                                      std::function<void()> command)
{
  BOOST_ASSERT(state != RetryState::NONE);
  if (m_retryState == RetryState::NONE || m_retryState != state) {
    m_retryState = state;
    *m_retryEventId = scheduler::schedule(delay, command); <-- line 72
  }
}

The backtrace is attached.

-Nick

On 02/21/2017 06:57 PM, Junxiao Shi wrote:
> Hi Nick
> 
> Can you include gdb 'bt full' logs, for crashes?
> See http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2016-May/001748.html
> 
> On Feb 21, 2017 3:33 PM, "Nick Gordon" <nmgordon at memphis.edu <mailto:nmgordon at memphis.edu>> wrote:
> 
>     NFD on that router crashes.
> 
-------------- next part --------------

#0  ndn::util::scheduler::EventId::operator! (this=this at entry=0x0) at ../src/util/scheduler.cpp:55
No locals.
#1  0x00007ffff7ae6381 in ndn::util::scheduler::EventId::operator== (this=this at entry=0x0, other=...) at ../src/util/scheduler.cpp:61
No locals.
#2  0x00000000005c2eb7 in ndn::util::scheduler::EventId::operator!= (other=..., this=0x0) at /usr/local/include/ndn-cxx/util/scheduler.hpp:84
No locals.
#3  nfd::scheduler::ScopedEventId::operator= (this=0x0, event=...) at ../core/scheduler.cpp:82
No locals.
#4  0x0000000000588149 in nfd::rib::ReadvertisedRoute::scheduleRetryEvent(nfd::rib::ReadvertisedRoute::RetryState, boost::chrono::duration<long, boost::ratio<1l, 1000l> >, std::function<void ()>) (this=this at entry=0x7fffe404a360, state=state at entry=nfd::rib::ReadvertisedRoute::ADVERTISE, delay=..., command=...) at ../rib/readvertise/readvertised-route.cpp:72
        __PRETTY_FUNCTION__ = "void nfd::rib::ReadvertisedRoute::scheduleRetryEvent(nfd::rib::ReadvertisedRoute::RetryState, boost::chrono::milliseconds, std::function<void()>)"
#5  0x000000000058179f in nfd::rib::Readvertise::<lambda(const string&)>::<lambda(nfd::rib::ReadvertisedRoute&)>::operator() (readRoute=..., __closure=0x7ffff1640f20) at ../rib/readvertise/readvertise.cpp:151
        this = 0x7fffe4030150
        newTime = @0x7ffff1640ed0: {rep_ = 100005}
        route = @0x7ffff1640ee0: {<boost::bidirectional_iterator_helper<boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<nfd::rib::ReadvertisedRoute, std::allocator<nfd::rib::ReadvertisedRoute> > > >, nfd::rib::ReadvertisedRoute, long, nfd::rib::ReadvertisedRoute const*, nfd::rib::ReadvertisedRoute const&>> = {<boost::bidirectional_iteratable<boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<nfd::rib::ReadvertisedRoute, std::allocator<nfd::rib::ReadvertisedRoute> > > >, nfd::rib::ReadvertisedRoute const*, std::iterator<std::bidirectional_iterator_tag, nfd::rib::ReadvertisedRoute, long, nfd::rib::ReadvertisedRoute const*, nfd::rib::ReadvertisedRoute const&> >> = {<boost::forward_iteratable<boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<nfd::rib::ReadvertisedRoute, std::allocator<nfd::rib::ReadvertisedRoute> > > >, nfd::rib::ReadvertisedRoute const*, boost::decrementable<boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<nfd::rib::ReadvertisedRoute, std::allocator<nfd::rib::ReadvertisedRoute> > > >, std::iterator<std::bidirectional_iterator_tag, nfd::rib::ReadvertisedRoute, long, nfd::rib::ReadvertisedRoute const*, nfd::rib::ReadvertisedRoute const&> > >> = {<boost::input_iteratable<boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<nfd::rib::ReadvertisedRoute, std::allocator<nfd::rib::ReadvertisedRoute> > > >, nfd::rib::ReadvertisedRoute const*, boost::decrementable<boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<nfd::rib::ReadvertisedRoute, std::allocator<nfd::rib::ReadvertisedRoute> > > >, std::iterator<std::bidirectional_iterator_tag, nfd::rib::ReadvertisedRoute, long, nfd::rib::ReadvertisedRoute const*, nfd::rib::ReadvertisedRoute const&> > >> = {<boost::equality_comparable1<boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<nfd::rib::ReadvertisedRoute, std::allocator<nfd::rib::ReadvertisedRoute> > > >, boost::incrementable<boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<nfd::rib::ReadvertisedRoute, std::allocator<nfd::rib::ReadvertisedRoute> > > >, boost::dereferenceable<boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<nfd::rib::ReadvertisedRoute, std::allocator<nfd::rib::ReadvertisedRoute> > > >, nfd::rib::ReadvertisedRoute const*, boost::decrementable<boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<nfd::rib::ReadvertisedRoute, std::allocator<nfd::rib::ReadvertisedRoute> > > >, std::iterator<std::bidirectional_iterator_tag, nfd::rib::ReadvertisedRoute, long, nfd::rib::ReadvertisedRoute const*, nfd::rib::ReadvertisedRoute const&> > > > >> = {<boost::incrementable<boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<nfd::rib::ReadvertisedRoute, std::allocator<nfd::rib::ReadvertisedRoute> > > >, boost::dereferenceable<boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<nfd::rib::ReadvertisedRoute, std::allocator<nfd::rib::ReadvertisedRoute> > > >, nfd::rib::ReadvertisedRoute const*, boost::decrementable<boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<nfd::rib::ReadvertisedRoute, std::allocator<nfd::rib::ReadvertisedRoute> > > >, std::iterator<std::bidirectional_iterator_tag, nfd::rib::ReadvertisedRoute, long, nfd::rib::ReadvertisedRoute const*, nfd::rib::ReadvertisedRoute const&> > > >> = {<boost::dereferenceable<boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<nfd::rib::ReadvertisedRoute, std::allocator<nfd::rib::ReadvertisedRoute> > > >, nfd::rib::ReadvertisedRoute const*, boost::decrementable<boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<nfd::rib::ReadvertisedRoute, std::allocator<nfd::rib::ReadvertisedRoute> > > >, std::iterator<std::bidirectional_iterator_tag, nfd::rib::ReadvertisedRoute, long, nfd::rib::ReadvertisedRoute const*, nfd::rib::ReadvertisedRoute const&> > >> = {<boost::decrementable<boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<nfd::rib::ReadvertisedRoute, std::allocator<nfd::rib::ReadvertisedRoute> > > >, std::iterator<std::bidirectional_iterator_tag, nfd::rib::ReadvertisedRoute, long, nfd::rib::ReadvertisedRoute const*, nfd::rib::ReadvertisedRoute const&> >> = {<std::iterator<std::bidirectional_iterator_tag, nfd::rib::ReadvertisedRoute, long, nfd::rib::ReadvertisedRoute const*, nfd::rib::ReadvertisedRoute const&>> = {<No data fields>}, <No data fields>}, <No data fields>}, <No data fields>}, <No data fields>}, <No data fields>}, <No data fields>}, <No data fields>}, <No data fields>}, node = 0x7fffe404a360}
        rr = @0x7fffe404a360: {m_prefix = {<std::enable_shared_from_this<ndn::Name>> = {_M_weak_this = std::weak_ptr (empty) 0x0}, static npos = 18446744073709551615, m_nameBlock = {m_buffer = std::shared_ptr (count 9, weak 0) 0x7fffe4032e80, m_type = 7, m_begin = 7 '\a', m_end = 105 'i', m_size = 16, m_value_begin = 8 '\b', m_value_end = 105 'i', m_subBlocks = std::vector of length 2, capacity 2 = {{m_buffer = std::shared_ptr (count 9, weak 0) 0x7fffe4032e80, m_type = 8, m_begin = 8 '\b', m_end = 8 '\b', m_size = 5, m_value_begin = 110 'n', m_value_end = 8 '\b', m_subBlocks = std::vector of length 0, capacity 0}, {m_buffer = std::shared_ptr (count 9, weak 0) 0x7fffe4032e80, m_type = 8, m_begin = 8 '\b', m_end = 105 'i', m_size = 9, m_value_begin = 101 'e', m_value_end = 105 'i', m_subBlocks = std::vector of length 0, capacity 0}}}}, m_signer = {m_type = ndn::security::SigningInfo::SIGNER_TYPE_NULL, m_name = {<std::enable_shared_from_this<ndn::Name>> = {_M_weak_this = std::weak_ptr (empty) 0x0}, static npos = 18446744073709551615, m_nameBlock = {m_buffer = std::shared_ptr (empty) 0x0, m_type = 7, m_begin = <error reading variable>}, m_identity = {m_impl = std::weak_ptr (empty) 0x0}, m_key = {m_impl = std::weak_ptr (empty) 0x0}, m_digestAlgorithm = ndn::DigestAlgorithm::SHA256, m_info = {m_type = -1, m_hasKeyLocator = false, m_keyLocator = {m_type = ndn::KeyLocator::KeyLocator_None, m_name = {<std::enable_shared_from_this<ndn::Name>> = {_M_weak_this = std::weak_ptr (empty) 0x0}, static npos = 18446744073709551615, m_nameBlock = {m_buffer = std::shared_ptr (empty) 0x0, m_type = 7, m_begin = <error reading variable>}, m_keyDigest = {m_buffer = std::shared_ptr (empty) 0x0, m_type = 4294967295, m_begin = <error reading variable>, m_wire = {m_buffer = std::shared_ptr (empty) 0x0, m_type = 4294967295, m_begin = <error reading variable>}, m_otherTlvs = {<std::__cxx11::_List_base<ndn::Block, std::allocator<ndn::Block> >> = {_M_impl = {<std::allocator<std::_List_node<ndn::Block> >> = {<__gnu_cxx::new_allocator<std::_List_node<ndn::Block> >> = {<No data fields>}, <No data fields>}, _M_node = {<std::__detail::_List_node_base> = {_M_next = 0x7fffe404a588, _M_prev = 0x7fffe404a588}, _M_data = 0}}}, <No data fields>}, m_wire = {m_buffer = std::shared_ptr (empty) 0x0, m_type = 4294967295, m_begin = <error reading variable>}}, m_ribRoutes = std::vector of length 1, capacity 1 = {{entry = std::shared_ptr (count 3, weak 1) 0x7fffe402a610, route = {faceId = 259, origin = 65, flags = 1, cost = 0, expires = {d_ = {rep_ = 9223372036854775807}}, m_expirationEvent = {m_info = std::weak_ptr (empty) 0x0}}}}, m_retryState = nfd::rib::ReadvertisedRoute::ADVERTISE, m_retryEventId = std::shared_ptr (empty) 0x0}
#6  boost::multi_index::multi_index_container<nfd::rib::ReadvertisedRoute, boost::multi_index::indexed_by<boost::multi_index::ordered_unique<boost::multi_index::const_mem_fun<nfd::rib::ReadvertisedRoute, ndn::Name const&, &nfd::rib::ReadvertisedRoute::getPrefix>, mpl_::na, mpl_::na>, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, std::allocator<nfd::rib::ReadvertisedRoute> >::modify_<nfd::rib::Readvertise::advertise(const nfd::rib::ReadvertisedRoute&, boost::chrono::milliseconds)::<lambda(const string&)>::<lambda(nfd::rib::ReadvertisedRoute&)> > (x=0x7fffe404a360, mod=..., this=0x7fffe4030150) at /usr/include/boost/multi_index_container.hpp:813
No locals.
#7  boost::multi_index::detail::index_base<nfd::rib::ReadvertisedRoute, boost::multi_index::indexed_by<boost::multi_index::ordered_unique<boost::multi_index::const_mem_fun<nfd::rib::ReadvertisedRoute, ndn::Name const&, &nfd::rib::ReadvertisedRoute::getPrefix>, mpl_::na, mpl_::na>, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, std::allocator<nfd::rib::ReadvertisedRoute> >::final_modify_<nfd::rib::Readvertise::advertise(const nfd::rib::ReadvertisedRoute&, boost::chrono::milliseconds)::<lambda(const string&)>::<lambda(nfd::rib::ReadvertisedRoute&)> > (x=<optimised out>, mod=..., this=0x7fffe4030160) at /usr/include/boost/multi_index/detail/index_base.hpp:276
No locals.
#8  boost::multi_index::detail::ordered_index<boost::multi_index::const_mem_fun<nfd::rib::ReadvertisedRoute, ndn::Name const&, &nfd::rib::ReadvertisedRoute::getPrefix>, std::less<ndn::Name const>, boost::multi_index::detail::nth_layer<1, nfd::rib::ReadvertisedRoute, boost::multi_index::indexed_by<boost::multi_index::ordered_unique<boost::multi_index::const_mem_fun<nfd::rib::ReadvertisedRoute, ndn::Name const&, &nfd::rib::ReadvertisedRoute::getPrefix>, mpl_::na, mpl_::na>, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, std::allocator<nfd::rib::ReadvertisedRoute> >, boost::mpl::vector0<mpl_::na>, boost::multi_index::detail::ordered_unique_tag>::modify<nfd::rib::Readvertise::advertise(const nfd::rib::ReadvertisedRoute&, boost::chrono::milliseconds)::<lambda(const string&)>::<lambda(nfd::rib::ReadvertisedRoute&)> > (mod=..., position=..., this=0x7fffe4030160) at /usr/include/boost/multi_index/ordered_index.hpp:421
No locals.
#9  nfd::rib::Readvertise::<lambda(const string&)>::operator() (msg=..., __closure=0x7fffe4039280) at ../rib/readvertise/readvertise.cpp:153
        dist = {_M_param = {_M_a = 18446744073709551611, _M_b = 5}}
        newTime = {rep_ = 100005}
        route = {<boost::bidirectional_iterator_helper<boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<nfd::rib::ReadvertisedRoute, std::allocator<nfd::rib::ReadvertisedRoute> > > >, nfd::rib::ReadvertisedRoute, long, nfd::rib::ReadvertisedRoute const*, nfd::rib::ReadvertisedRoute const&>> = {<boost::bidirectional_iteratable<boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<nfd::rib::ReadvertisedRoute, std::allocator<nfd::rib::ReadvertisedRoute> > > >, nfd::rib::ReadvertisedRoute const*, std::iterator<std::bidirectional_iterator_tag, nfd::rib::ReadvertisedRoute, long, nfd::rib::ReadvertisedRoute const*, nfd::rib::ReadvertisedRoute const&> >> = {<boost::forward_iteratable<boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<nfd::rib::ReadvertisedRoute, std::allocator<nfd::rib::ReadvertisedRoute> > > >, nfd::rib::ReadvertisedRoute const*, boost::decrementable<boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<nfd::rib::ReadvertisedRoute, std::allocator<nfd::rib::ReadvertisedRoute> > > >, std::iterator<std::bidirectional_iterator_tag, nfd::rib::ReadvertisedRoute, long, nfd::rib::ReadvertisedRoute const*, nfd::rib::ReadvertisedRoute const&> > >> = {<boost::input_iteratable<boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<nfd::rib::ReadvertisedRoute, std::allocator<nfd::rib::ReadvertisedRoute> > > >, nfd::rib::ReadvertisedRoute const*, boost::decrementable<boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<nfd::rib::ReadvertisedRoute, std::allocator<nfd::rib::ReadvertisedRoute> > > >, std::iterator<std::bidirectional_iterator_tag, nfd::rib::ReadvertisedRoute, long, nfd::rib::ReadvertisedRoute const*, nfd::rib::ReadvertisedRoute const&> > >> = {<boost::equality_comparable1<boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<nfd::rib::ReadvertisedRoute, std::allocator<nfd::rib::ReadvertisedRoute> > > >, boost::incrementable<boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<nfd::rib::ReadvertisedRoute, std::allocator<nfd::rib::ReadvertisedRoute> > > >, boost::dereferenceable<boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<nfd::rib::ReadvertisedRoute, std::allocator<nfd::rib::ReadvertisedRoute> > > >, nfd::rib::ReadvertisedRoute const*, boost::decrementable<boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<nfd::rib::ReadvertisedRoute, std::allocator<nfd::rib::ReadvertisedRoute> > > >, std::iterator<std::bidirectional_iterator_tag, nfd::rib::ReadvertisedRoute, long, nfd::rib::ReadvertisedRoute const*, nfd::rib::ReadvertisedRoute const&> > > > >> = {<boost::incrementable<boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<nfd::rib::ReadvertisedRoute, std::allocator<nfd::rib::ReadvertisedRoute> > > >, boost::dereferenceable<boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<nfd::rib::ReadvertisedRoute, std::allocator<nfd::rib::ReadvertisedRoute> > > >, nfd::rib::ReadvertisedRoute const*, boost::decrementable<boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<nfd::rib::ReadvertisedRoute, std::allocator<nfd::rib::ReadvertisedRoute> > > >, std::iterator<std::bidirectional_iterator_tag, nfd::rib::ReadvertisedRoute, long, nfd::rib::ReadvertisedRoute const*, nfd::rib::ReadvertisedRoute const&> > > >> = {<boost::dereferenceable<boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<nfd::rib::ReadvertisedRoute, std::allocator<nfd::rib::ReadvertisedRoute> > > >, nfd::rib::ReadvertisedRoute const*, boost::decrementable<boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<nfd::rib::ReadvertisedRoute, std::allocator<nfd::rib::ReadvertisedRoute> > > >, std::iterator<std::bidirectional_iterator_tag, nfd::rib::ReadvertisedRoute, long, nfd::rib::ReadvertisedRoute const*, nfd::rib::ReadvertisedRoute const&> > >> = {<boost::decrementable<boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<nfd::rib::ReadvertisedRoute, std::allocator<nfd::rib::ReadvertisedRoute> > > >, std::iterator<std::bidirectional_iterator_tag, nfd::rib::ReadvertisedRoute, long, nfd::rib::ReadvertisedRoute const*, nfd::rib::ReadvertisedRoute const&> >> = {<std::iterator<std::bidirectional_iterator_tag, nfd::rib::ReadvertisedRoute, long, nfd::rib::ReadvertisedRoute const*, nfd::rib::ReadvertisedRoute const&>> = {<No data fields>}, <No data fields>}, <No data fields>}, <No data fields>}, <No data fields>}, <No data fields>}, <No data fields>}, <No data fields>}, <No data fields>}, node = 0x7fffe404a360}
        this = 0x7fffe4030150
        rr = @0x7fffe404a360: {m_prefix = {<std::enable_shared_from_this<ndn::Name>> = {_M_weak_this = std::weak_ptr (empty) 0x0}, static npos = 18446744073709551615, m_nameBlock = {m_buffer = std::shared_ptr (count 9, weak 0) 0x7fffe4032e80, m_type = 7, m_begin = 7 '\a', m_end = 105 'i', m_size = 16, m_value_begin = 8 '\b', m_value_end = 105 'i', m_subBlocks = std::vector of length 2, capacity 2 = {{m_buffer = std::shared_ptr (count 9, weak 0) 0x7fffe4032e80, m_type = 8, m_begin = 8 '\b', m_end = 8 '\b', m_size = 5, m_value_begin = 110 'n', m_value_end = 8 '\b', m_subBlocks = std::vector of length 0, capacity 0}, {m_buffer = std::shared_ptr (count 9, weak 0) 0x7fffe4032e80, m_type = 8, m_begin = 8 '\b', m_end = 105 'i', m_size = 9, m_value_begin = 101 'e', m_value_end = 105 'i', m_subBlocks = std::vector of length 0, capacity 0}}}}, m_signer = {m_type = ndn::security::SigningInfo::SIGNER_TYPE_NULL, m_name = {<std::enable_shared_from_this<ndn::Name>> = {_M_weak_this = std::weak_ptr (empty) 0x0}, static npos = 18446744073709551615, m_nameBlock = {m_buffer = std::shared_ptr (empty) 0x0, m_type = 7, m_begin = <error reading variable>}, m_identity = {m_impl = std::weak_ptr (empty) 0x0}, m_key = {m_impl = std::weak_ptr (empty) 0x0}, m_digestAlgorithm = ndn::DigestAlgorithm::SHA256, m_info = {m_type = -1, m_hasKeyLocator = false, m_keyLocator = {m_type = ndn::KeyLocator::KeyLocator_None, m_name = {<std::enable_shared_from_this<ndn::Name>> = {_M_weak_this = std::weak_ptr (empty) 0x0}, static npos = 18446744073709551615, m_nameBlock = {m_buffer = std::shared_ptr (empty) 0x0, m_type = 7, m_begin = <error reading variable>}, m_keyDigest = {m_buffer = std::shared_ptr (empty) 0x0, m_type = 4294967295, m_begin = <error reading variable>, m_wire = {m_buffer = std::shared_ptr (empty) 0x0, m_type = 4294967295, m_begin = <error reading variable>}, m_otherTlvs = {<std::__cxx11::_List_base<ndn::Block, std::allocator<ndn::Block> >> = {_M_impl = {<std::allocator<std::_List_node<ndn::Block> >> = {<__gnu_cxx::new_allocator<std::_List_node<ndn::Block> >> = {<No data fields>}, <No data fields>}, _M_node = {<std::__detail::_List_node_base> = {_M_next = 0x7fffe404a588, _M_prev = 0x7fffe404a588}, _M_data = 0}}}, <No data fields>}, m_wire = {m_buffer = std::shared_ptr (empty) 0x0, m_type = 4294967295, m_begin = <error reading variable>}}, m_ribRoutes = std::vector of length 1, capacity 1 = {{entry = std::shared_ptr (count 3, weak 1) 0x7fffe402a610, route = {faceId = 259, origin = 65, flags = 1, cost = 0, expires = {d_ = {rep_ = 9223372036854775807}}, m_expirationEvent = {m_info = std::weak_ptr (empty) 0x0}}}}, m_retryState = nfd::rib::ReadvertisedRoute::ADVERTISE, m_retryEventId = std::shared_ptr (empty) 0x0}
        retryTime = @0x7ffff1640250: {rep_ = 50000}
#10 std::_Function_handler<void(const std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&), nfd::rib::Readvertise::advertise(const nfd::rib::ReadvertisedRoute&, boost::chrono::milliseconds)::<lambda(const string&)> >::_M_invoke(const std::_Any_data &, const std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > &) (__functor=..., __args#0=...) at /usr/include/c++/5/functional:1871
No locals.
#11 0x00000000004e4f45 in std::function<void (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)>::operator()(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const (this=<optimised out>, __args#0=...) at /usr/include/c++/5/functional:2267
No locals.
#12 0x0000000000578c29 in nfd::rib::NfdRibReadvertiseDestination::<lambda(const ControlResponse&)>::operator() (cr=..., __closure=<optimised out>) at ../rib/readvertise/nfd-rib-readvertise-destination.cpp:59
        failureCb = <optimised out>
#13 std::_Function_handler<void(const ndn::mgmt::ControlResponse&), nfd::rib::NfdRibReadvertiseDestination::advertise(const nfd::rib::ReadvertisedRoute&, std::function<void()>, std::function<void(const std::__cxx11::basic_string<char>&)>)::<lambda(const ControlResponse&)> >::_M_invoke(const std::_Any_data &, const ndn::mgmt::ControlResponse &) (__functor=..., __args#0=...) at /usr/include/c++/5/functional:1871
No locals.
#14 0x00007ffff793930f in std::function<void (ndn::mgmt::ControlResponse const&)>::operator()(ndn::mgmt::ControlResponse const&) const (__args#0=..., this=0x7fffe402fda8) at /usr/include/c++/5/functional:2267
No locals.
(More stack frames follow...)

From nmgordon at memphis.edu  Tue Feb 21 20:47:18 2017
From: nmgordon at memphis.edu (Nick Gordon)
Date: Tue, 21 Feb 2017 22:47:18 -0600
Subject: [Nfd-dev] How to send command interests from NFD to NLSR?
In-Reply-To: <017ea291-caea-81b3-9706-256e8715b647@memphis.edu>
References: <f46e90c0-d605-483a-4b6a-39d7558261fc@memphis.edu>
	<CAOFH+Ob=DKvSFBgWNs96_KCF=YigbqO86ndyLv13nixtQUxJ-g@mail.gmail.com>
	<017ea291-caea-81b3-9706-256e8715b647@memphis.edu>
Message-ID: <0911a684-ae8e-b24c-e7ee-d6b661f659e5@memphis.edu>

Since I don't think this change is on gerrit, m_retryEventId is a shared_ptr<scheduler::ScopedEventId>. It was necessary to do this in order
to make ReadvertisedRoutes copyable for the RouteContainer.

-Nick

On 02/21/2017 10:41 PM, Nick Gordon wrote:
> Junxiao,
> 
> I can only post the top #13 calls, because if I ask for more, it loops infinitely for some reason in gdb. However, I have those, and the
> problem is in this code:
> 
> void
> ReadvertisedRoute::scheduleRetryEvent(RetryState state, time::milliseconds delay,
>                                       std::function<void()> command)
> {
>   BOOST_ASSERT(state != RetryState::NONE);
>   if (m_retryState == RetryState::NONE || m_retryState != state) {
>     m_retryState = state;
>     *m_retryEventId = scheduler::schedule(delay, command); <-- line 72
>   }
> }
> 
> The backtrace is attached.
> 
> -Nick
> 
> On 02/21/2017 06:57 PM, Junxiao Shi wrote:
>> Hi Nick
>>
>> Can you include gdb 'bt full' logs, for crashes?
>> See http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2016-May/001748.html
>>
>> On Feb 21, 2017 3:33 PM, "Nick Gordon" <nmgordon at memphis.edu <mailto:nmgordon at memphis.edu>> wrote:
>>
>>     NFD on that router crashes.
>>

From nmgordon at memphis.edu  Tue Feb 21 23:31:51 2017
From: nmgordon at memphis.edu (Nick Gordon)
Date: Wed, 22 Feb 2017 01:31:51 -0600
Subject: [Nfd-dev] How to send command interests from NFD to NLSR?
In-Reply-To: <0911a684-ae8e-b24c-e7ee-d6b661f659e5@memphis.edu>
References: <f46e90c0-d605-483a-4b6a-39d7558261fc@memphis.edu>
	<CAOFH+Ob=DKvSFBgWNs96_KCF=YigbqO86ndyLv13nixtQUxJ-g@mail.gmail.com>
	<017ea291-caea-81b3-9706-256e8715b647@memphis.edu>
	<0911a684-ae8e-b24c-e7ee-d6b661f659e5@memphis.edu>
Message-ID: <ca1320c0-6acf-3fcf-1f99-2c553df7a114@memphis.edu>

I have solved the problem. The issue was that I was default-constructing the shared_ptr to nullptr. This would normally be okay, except that
to assign to a ScopedEventId, it compares the EventId members. To do this, it compares their EventInfo's, which are kept as weak_ptrs. If
all of this stuff is not default-constructed, it is in an invalid state. I fixed this by changing

std::shared_ptr<scheduler::ScopedEventId> m_retryEventId = nullptr;

to

std::shared_ptr<scheduler::ScopedEventId> m_retryEventId = std::make_shared<scheduler::ScopedEventId>();

This wasn't caught at the unit test level because of a gap in coverage; I have no unit tests that test for scheduled retries of
advertise/withdraw events.

Anyway, thank you Junxiao for suggesting to get the backtrace from gdb. I definitely couldn't have solved this without that.

-Nick

On 02/21/2017 10:47 PM, Nick Gordon wrote:
> Since I don't think this change is on gerrit, m_retryEventId is a shared_ptr<scheduler::ScopedEventId>. It was necessary to do this in order
> to make ReadvertisedRoutes copyable for the RouteContainer.
> 
> -Nick
> 
> On 02/21/2017 10:41 PM, Nick Gordon wrote:
>> Junxiao,
>>
>> I can only post the top #13 calls, because if I ask for more, it loops infinitely for some reason in gdb. However, I have those, and the
>> problem is in this code:
>>
>> void
>> ReadvertisedRoute::scheduleRetryEvent(RetryState state, time::milliseconds delay,
>>                                       std::function<void()> command)
>> {
>>   BOOST_ASSERT(state != RetryState::NONE);
>>   if (m_retryState == RetryState::NONE || m_retryState != state) {
>>     m_retryState = state;
>>     *m_retryEventId = scheduler::schedule(delay, command); <-- line 72
>>   }
>> }
>>
>> The backtrace is attached.
>>
>> -Nick
>>
>> On 02/21/2017 06:57 PM, Junxiao Shi wrote:
>>> Hi Nick
>>>
>>> Can you include gdb 'bt full' logs, for crashes?
>>> See http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2016-May/001748.html
>>>
>>> On Feb 21, 2017 3:33 PM, "Nick Gordon" <nmgordon at memphis.edu <mailto:nmgordon at memphis.edu>> wrote:
>>>
>>>     NFD on that router crashes.
>>>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
> 

From lanwang at memphis.edu  Wed Feb 22 03:50:04 2017
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Wed, 22 Feb 2017 11:50:04 +0000
Subject: [Nfd-dev] AutoPrefixPropagator inside mini-NDN
In-Reply-To: <978be7b3-b07e-b012-15b7-013418466b2c@memphis.edu>
References: <fcea8400-4590-8e6a-b52c-4beda4028e99@memphis.edu>
	<727DAAA1-8B55-4ED0-83E1-A897341C0A43@memphis.edu>
	<ef6c51b4-c5fe-b3c2-aaff-7735051ad5ae@memphis.edu>
	<CAOFH+Oa_4mBD_aEzT3xZkBYy15PspMvmzJ9xs2c8TcuQLu=bUQ@mail.gmail.com>,
	<978be7b3-b07e-b012-15b7-013418466b2c@memphis.edu>
Message-ID: <C0EFDDB1-DA7F-425B-A314-60E81E880EF6@memphis.edu>

You need to manually create this route.  If you follow Junxiao's post https://yoursunny.com/t/2016/nfd-prefix/,

$ nfdc register / udp4://hobo.cs.arizona.edu
Successful in name registration: ControlParameters(Name: /, FaceId: 266, Origin: 255, Cost: 0, Flags: 1, )

 $ nfdc register /localhop/nfd udp4://hobo.cs.arizona.edu
Successful in name registration: ControlParameters(Name: /localhop/nfd, FaceId: 266, Origin: 255, Cost: 0, Flags: 1, )

You will need to replace hobo with your router's name.

Lan (on phone)

On Feb 21, 2017, at 9:17 PM, Nicholas Michael Gordon (nmgordon) <nmgordon at memphis.edu<mailto:nmgordon at memphis.edu>> wrote:

I can in fact confirm that the FIB on that router has no /localhop/nfd
entry:

mininet> router1 nfdc fib list
                         ?
FIB:
                         ?
 /localhost/nfd/rib nexthops={faceid=260 (cost=0)}
                         ?
 /ndn/router1-site/%C1.Router/cs/router1 nexthops={faceid=262 (cost=0)}
                         ?
 /ndn/router2-site/router2 nexthops={faceid=261 (cost=10)}
                         ?
 /ndn/broadcast/KEYS nexthops={faceid=262 (cost=0), faceid=261
(cost=10)}                         ?
 /localhop/ndn/NLSR/LSA nexthops={faceid=261 (cost=10)}
                         ?
 /localhop/ndn/NLSR/LSA/router1-site/%C1.Router/cs/router1
nexthops={faceid=262 (cost=0)}         ?
 /localhost/nfd nexthops={faceid=1 (cost=0)}
                         ?
 /localhop/NLSR/sync nexthops={faceid=262 (cost=0), faceid=261
(cost=10)}                         ?
 /ndn/router2-site/%C1.Router/cs/router2 nexthops={faceid=261
(cost=10)}                          ?
 /localhost/nlsr nexthops={faceid=262 (cost=0)}

I don't know if that's a problem, because I see /localhost/nfd. However,
since the strategy is looking for localhop specifically, I'm unsure.

After re-running this experiment specifically to look for this message,
I can confirm several entries like this:

1487733093.378927 DEBUG: [BestRouteStrategy2]
/localhop/nfd/rib/register/h%19%07%0E%08%03ndn%08%07endhosti%01%00o%01Aj%01%0F/%00%00%01Zc%CDs%DE/%A2%24%D2%B1%DD%3C_%02/%166%1B%01%01%1C1%07%2F%08%03ndn%08%07endhost%08%03KEY%08%11ksk-1487733015581%08%07ID-CERT/%17%FD%01%00%80%03%92cd%16%EA%DF%92%831%8B%22%FF%DE%A8%A8%A4%83%C9%16%93+%C0x%D7%2Ai%7B%15%981%1D7%94%9A%8D%FD+%D4L%E4%CC%DCs%CE%1C%80%82%01%A8%22%EBN%82%7D%C5%82%19%06%B4%8F%A8%8EG%60%2Cz%E3%7B2%F62%ED%CF%D6l%9F%24%BCH%B1%08a%AA%AA%03%89S%BC%22%F7%E96%01R%EA%3B%99r3t%A7%EA%90g%22%F2%7B%19%A3k%F4q%AF%BFs%BF%B5%86%DA%83%A7g%9AT%AC_%DBw%1BR%60%88%E0H%8As%FC%E9%11%06V%3EL%29%19%D5c%0E%0FD%E8N%BE%FF%A9j%F0UO%2Fd%CB%8E%14%92%DD%DD0%C5l%1E%B4IM%16%28%D1IZ%EE%08%C6%D5%A6%079SY%8B%08i%1Cgm%A6%DE%A2%B17%E8%0B%7E%C7%A5QO%FB%00w%CA%AF%92%7Bsq%BA%CC9w%E6%1Cev%2C0eE%F6x%CFD%15%97%60%A1%A3%60%1C%E0%E2%FD%FB%8E%9E%A2%AE%FAu%3C%27%0E%D6S%0B?ndn.InterestLifetime=10000&ndn.Nonce=419550183
from=265 noNextHop
1487733143.408247 DEBUG: [BestRouteStrategy2]
/localhop/nfd/rib/register/h%19%07%0E%08%03ndn%08%07endhosti%01%00o%01Aj%01%0F/%00%00%01Zc%CE7_/%C6%8F%C9s%B2%E8d%D4/%166%1B%01%01%1C1%07%2F%08%03ndn%08%07endhost%08%03KEY%08%11ksk-1487733015581%08%07ID-CERT/%17%FD%01%00%9Bn%F8%98%FDGOw%06%05%80%7E%7Fn%00%AE%C6A%7E%C7C3%80%B9%81%29b%17Y%F3%AF%9D%D2%B3%04%EEM%E6%7EO-%22%FD%21%E9%DA4%1D%1A%92%7B%B7h+%B5%04%85W%EC%98%8Df%87%9C%97%1C%B0%0F%FAy%AFo%8A%C9%88%5E%06%DE%7CF%81%22%096%10%91%A7K%21%BFt%E5%8Aj%17%A1%84%24%87yH%1C%00%93%B5T%84%0A%9BN%D7%20%E5%C0iM%A7C%B1%C8%AA%AA%E3%FC%BD%14t%FD%26xk%B0%3B%B2%BB%04y%F7-%9C%3EW%21%FEn%03%0E5%ED%86%8F%9D%81%AD%2F%CBk%1F%DA%92%DDh%DBL%08%10%AC%92%2C%C7mmS%F1%15%84%99%01%2A%94%A4%AC%D7D%03%E4%F8dV%BFz%B9%BA%7E%00%AF%16%F1%06%055%5E%C9%3A%9Dc%88%7B%C0%84%D9%F1%18%9CM%DE%25%27%22+%EC%FB%0E%F3%C7vgkVMb%3F%B0%EC%CCO%A7%C6%A4%E0%5E%12%C3%7EU%96%C1%01%C9%9C%25%CB%B7u%AFj?ndn.InterestLifetime=10000&ndn.Nonce=556154061
from=265 noNextHop
1487733243.438657 DEBUG: [BestRouteStrategy2]
/localhop/nfd/rib/register/h%19%07%0E%08%03ndn%08%07endhosti%01%00o%01Aj%01%0F/%00%00%01Zc%CF%BE%1E/%7DN%20K%18%99g%24/%166%1B%01%01%1C1%07%2F%08%03ndn%08%07endhost%08%03KEY%08%11ksk-1487733015581%08%07ID-CERT/%17%FD%01%00%84%B2%D4%DC%CAI%A7%ABW%A8%9E%40%86f%C3%9F%1B8%3Cc%3Fo%3B%D893%E4%94%EA%84T.%88%FF%992K%00%3E%0C%EF%D7%17%E98%F0k%E3%C5U%D8%CC%85%D6%04%03%A4%88%FC%81w%85%B4%CB%BF%27%AF%CF%95%B5%8Du%D5l%8B%BF%C7%E1%FD%F3H4%98u%20%5E%A3%91%DC%21%9E%2C%8D%7B%C9%DF%C8%D6%87%A8%99%1F%29%CA%F8%9D%21gc%B9%3C%7F%22f%E9%FC%D5%0EC%B4_%0EgH%C1%B8A%26%A7%E1%3E%94%A8%18%B5%8Cw%23%B4%B6%10%A4%F2%BF%CFkX%A1S%7F%A4%5E%CCl%1Be%88j%C5%98t%9F%0FNA%CD%25%E1%5E%E2+%93%CB%2Fm%11%D9%E9%5DQ%24%14Sp%1DS%B9%E3%FB%CALu%D4%99A%C7%B7W+%16%10%14%FF%97%7F%CC%05CA%14%FF%9A%FA%7Df%9F%BA%3A%0E%C0%B8%80%25%E2%97%AAZ%B5K%0A%BA%8D%85%07%E25%3B%044n%D5%26%2A%88Q%23%86%8C%17%0D%EBYQ%40%EF%19?ndn.InterestLifetime=10000&ndn.Nonce=2733607158
from=265 noNextHop

On 02/21/2017 07:16 PM, Junxiao Shi wrote:
Hi Nick

This line indicates strategy cannot finding a nexthop for
/localhop/nfd/rib/register.
Can you confirm FIB on the node where this log is captured contains
/localhop/nfd or /localhop/nfd/rib entry?
You may inspect FIB with 'nfdc fib list' command.

Yours, Junxiao

On Feb 21, 2017 2:04 PM, "Nick Gordon" <nmgordon at memphis.edu<mailto:nmgordon at memphis.edu>
<mailto:nmgordon at memphis.edu>> wrote:


   1487713935.381784 DEBUG: [BestRouteStrategy2]
   /localhop/nfd/rib/register/h%19%07%0E%08%03ndn%08%07endhosti%01%00o%01Aj%01%0F/%00%00%01Zb%A9%20%05/%EA%1E%E1%2A%AFm%C8A/%166%1B%01%01%1C1%07%2F%08%03ndn%08%07endhost%08%03KEY%08%11ksk-1487713107245%08%07ID-CERT/%17%FD%01%00%05%19%B3%C68%DC%F8L%B5e%FC%E6%EF%9C%B5%14%B8%BF%CA%BC%FFM%3E%D7%C9z%2A%3BVz%8B%A5Q%81%CA%9Fsf%997%AFZ3%5D%FD%E1%2Aj%A6%A6%23%7Bj%A6R%E2F%82J%92%14%7B%92%BE%C6%902%40%AB%26%1C%83%07%01%12%A9%8Bn%07%F3Tl%0D%D6%98d%ED%A2F%0C%12%EBB-C%B0_%5B%86%B0%9D%3ED8%B47%83s%3C%0BMH%5E%FF%7C%13UtY%95%90%0F%CFm%F2%ECPm%CEj%2F%D8%94%07%C1%7D%28%DA%97%B1%A1%C5s%97%3A%C3%CE%91%29%EB%23A1l4X0Q%AD%05%0F%98e%B1qa%D0%A7Dh%B0%CD%FDw%C2%9E%09%FA%DD%F1%DF%D5%A5%C1%A8%3E%93%E8%11%85%BE%19rg6%DE%A6o%1B%C4E%C1%9F%E6H3N%60%1B%14Y%AE%BD%24%0F%82%0A9l%BC%B0%AF%19%EAzFJs%D6%2A%F0gM%D7%D6%A2%D6%FA%151%07%08G%EDUYPO%0F%12%E7%AFm%A3%9E%B8?ndn.InterestLifetime=10000&ndn.Nonce=763432487
   from=265 noNextHop

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

From nfd-call-notification at mail1.yoursunny.com  Wed Feb 22 08:00:02 2017
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Wed, 22 Feb 2017 09:00:02 -0700
Subject: [Nfd-dev] NFD call 20170222
Message-ID: <201702221600.v1MG02db018690@lectura.cs.arizona.edu>

An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20170222/e7d63ab4/attachment.html>

From bzhang at cs.arizona.EDU  Wed Feb 22 08:35:39 2017
From: bzhang at cs.arizona.EDU (Beichuan Zhang)
Date: Wed, 22 Feb 2017 09:35:39 -0700
Subject: [Nfd-dev] cancel today's NFD call
Message-ID: <58242C85-C41A-4E79-9310-1A2B3E0B43FE@cs.arizona.edu>

A few of us will be on a different call. So the NFD call is cancelled.

Beichuan

From nmgordon at memphis.edu  Wed Feb 22 12:28:11 2017
From: nmgordon at memphis.edu (Nick Gordon)
Date: Wed, 22 Feb 2017 14:28:11 -0600
Subject: [Nfd-dev] AutoPrefixPropagator inside mini-NDN
In-Reply-To: <C0EFDDB1-DA7F-425B-A314-60E81E880EF6@memphis.edu>
References: <fcea8400-4590-8e6a-b52c-4beda4028e99@memphis.edu>
	<727DAAA1-8B55-4ED0-83E1-A897341C0A43@memphis.edu>
	<ef6c51b4-c5fe-b3c2-aaff-7735051ad5ae@memphis.edu>
	<CAOFH+Oa_4mBD_aEzT3xZkBYy15PspMvmzJ9xs2c8TcuQLu=bUQ@mail.gmail.com>
	<978be7b3-b07e-b012-15b7-013418466b2c@memphis.edu>
	<C0EFDDB1-DA7F-425B-A314-60E81E880EF6@memphis.edu>
Message-ID: <42f98c23-a387-9a14-2aaa-68a3abbc668f@memphis.edu>

I am doing this. These registrations are done on the endhost router not running NLSR, so that AutoPrefixPropagator is told where to
propagate to correctly. In the experiment, I am running these commands on endhost, which represents our "laptop" or something similar:

    endhost.cmd("nfdc register / udp4://" + endhost.IP(links[0][1]))
    endhost.cmd("nfdc register /localhop/nfd udp4://" + endhost.IP(links[0][1]) + " 2>&1")

-Nick

On 02/22/2017 05:50 AM, Lan Wang (lanwang) wrote:
> You need to manually create this route.  If you follow Junxiao's post https://yoursunny.com/t/2016/nfd-prefix/, 
> 
> |
> 
> |$ nfdc register / udp4://hobo.cs.arizona.edu Successful in name registration: ControlParameters(Name: /, FaceId: 266, Origin: 255, Cost: 0,
> Flags: 1, )|
> 
>  $ nfdc register /localhop/nfd udp4://hobo.cs.arizona.edu Successful in name registration: ControlParameters(Name: /localhop/nfd, FaceId:
> 266, Origin: 255, Cost: 0, Flags: 1, )
> 
> You will need to replace hobo with your router's name.
> 
> |
> 
> Lan (on phone)
> 
> On Feb 21, 2017, at 9:17 PM, Nicholas Michael Gordon (nmgordon) <nmgordon at memphis.edu <mailto:nmgordon at memphis.edu>> wrote:
> 
>> I can in fact confirm that the FIB on that router has no /localhop/nfd
>> entry:
>>
>> mininet> router1 nfdc fib list
>>                          ?
>> FIB:
>>                          ?
>>  /localhost/nfd/rib nexthops={faceid=260 (cost=0)}
>>                          ?
>>  /ndn/router1-site/%C1.Router/cs/router1 nexthops={faceid=262 (cost=0)}
>>                          ?
>>  /ndn/router2-site/router2 nexthops={faceid=261 (cost=10)}
>>                          ?
>>  /ndn/broadcast/KEYS nexthops={faceid=262 (cost=0), faceid=261
>> (cost=10)}                         ?
>>  /localhop/ndn/NLSR/LSA nexthops={faceid=261 (cost=10)}
>>                          ?
>>  /localhop/ndn/NLSR/LSA/router1-site/%C1.Router/cs/router1
>> nexthops={faceid=262 (cost=0)}         ?
>>  /localhost/nfd nexthops={faceid=1 (cost=0)}
>>                          ?
>>  /localhop/NLSR/sync nexthops={faceid=262 (cost=0), faceid=261
>> (cost=10)}                         ?
>>  /ndn/router2-site/%C1.Router/cs/router2 nexthops={faceid=261
>> (cost=10)}                          ?
>>  /localhost/nlsr nexthops={faceid=262 (cost=0)}
>>
>> I don't know if that's a problem, because I see /localhost/nfd. However,
>> since the strategy is looking for localhop specifically, I'm unsure.
>>
>> After re-running this experiment specifically to look for this message,
>> I can confirm several entries like this:
>>
>> 1487733093.378927 DEBUG: [BestRouteStrategy2]
>> /localhop/nfd/rib/register/h%19%07%0E%08%03ndn%08%07endhosti%01%00o%01Aj%01%0F/%00%00%01Zc%CDs%DE/%A2%24%D2%B1%DD%3C_%02/%166%1B%01%01%1C1%07%2F%08%03ndn%08%07endhost%08%03KEY%08%11ksk-1487733015581%08%07ID-CERT/%17%FD%01%00%80%03%92cd%16%EA%DF%92%831%8B%22%FF%DE%A8%A8%A4%83%C9%16%93+%C0x%D7%2Ai%7B%15%981%1D7%94%9A%8D%FD+%D4L%E4%CC%DCs%CE%1C%80%82%01%A8%22%EBN%82%7D%C5%82%19%06%B4%8F%A8%8EG%60%2Cz%E3%7B2%F62%ED%CF%D6l%9F%24%BCH%B1%08a%AA%AA%03%89S%BC%22%F7%E96%01R%EA%3B%99r3t%A7%EA%90g%22%F2%7B%19%A3k%F4q%AF%BFs%BF%B5%86%DA%83%A7g%9AT%AC_%DBw%1BR%60%88%E0H%8As%FC%E9%11%06V%3EL%29%19%D5c%0E%0FD%E8N%BE%FF%A9j%F0UO%2Fd%CB%8E%14%92%DD%DD0%C5l%1E%B4IM%16%28%D1IZ%EE%08%C6%D5%A6%079SY%8B%08i%1Cgm%A6%DE%A2%B17%E8%0B%7E%C7%A5QO%FB%00w%CA%AF%92%7Bsq%BA%CC9w%E6%1Cev%2C0eE%F6x%CFD%15%97%60%A1%A3%60%1C%E0%E2%FD%FB%8E%9E%A2%AE%FAu%3C%27%0E%D6S%0B?ndn.InterestLifetime=10000&ndn.Nonce=419550183
>> from=265 noNextHop
>> 1487733143.408247 DEBUG: [BestRouteStrategy2]
>> /localhop/nfd/rib/register/h%19%07%0E%08%03ndn%08%07endhosti%01%00o%01Aj%01%0F/%00%00%01Zc%CE7_/%C6%8F%C9s%B2%E8d%D4/%166%1B%01%01%1C1%07%2F%08%03ndn%08%07endhost%08%03KEY%08%11ksk-1487733015581%08%07ID-CERT/%17%FD%01%00%9Bn%F8%98%FDGOw%06%05%80%7E%7Fn%00%AE%C6A%7E%C7C3%80%B9%81%29b%17Y%F3%AF%9D%D2%B3%04%EEM%E6%7EO-%22%FD%21%E9%DA4%1D%1A%92%7B%B7h+%B5%04%85W%EC%98%8Df%87%9C%97%1C%B0%0F%FAy%AFo%8A%C9%88%5E%06%DE%7CF%81%22%096%10%91%A7K%21%BFt%E5%8Aj%17%A1%84%24%87yH%1C%00%93%B5T%84%0A%9BN%D7%20%E5%C0iM%A7C%B1%C8%AA%AA%E3%FC%BD%14t%FD%26xk%B0%3B%B2%BB%04y%F7-%9C%3EW%21%FEn%03%0E5%ED%86%8F%9D%81%AD%2F%CBk%1F%DA%92%DDh%DBL%08%10%AC%92%2C%C7mmS%F1%15%84%99%01%2A%94%A4%AC%D7D%03%E4%F8dV%BFz%B9%BA%7E%00%AF%16%F1%06%055%5E%C9%3A%9Dc%88%7B%C0%84%D9%F1%18%9CM%DE%25%27%22+%EC%FB%0E%F3%C7vgkVMb%3F%B0%EC%CCO%A7%C6%A4%E0%5E%12%C3%7EU%96%C1%01%C9%9C%25%CB%B7u%AFj?ndn.InterestLifetime=10000&ndn.Nonce=556154061
>> from=265 noNextHop
>> 1487733243.438657 DEBUG: [BestRouteStrategy2]
>> /localhop/nfd/rib/register/h%19%07%0E%08%03ndn%08%07endhosti%01%00o%01Aj%01%0F/%00%00%01Zc%CF%BE%1E/%7DN%20K%18%99g%24/%166%1B%01%01%1C1%07%2F%08%03ndn%08%07endhost%08%03KEY%08%11ksk-1487733015581%08%07ID-CERT/%17%FD%01%00%84%B2%D4%DC%CAI%A7%ABW%A8%9E%40%86f%C3%9F%1B8%3Cc%3Fo%3B%D893%E4%94%EA%84T.%88%FF%992K%00%3E%0C%EF%D7%17%E98%F0k%E3%C5U%D8%CC%85%D6%04%03%A4%88%FC%81w%85%B4%CB%BF%27%AF%CF%95%B5%8Du%D5l%8B%BF%C7%E1%FD%F3H4%98u%20%5E%A3%91%DC%21%9E%2C%8D%7B%C9%DF%C8%D6%87%A8%99%1F%29%CA%F8%9D%21gc%B9%3C%7F%22f%E9%FC%D5%0EC%B4_%0EgH%C1%B8A%26%A7%E1%3E%94%A8%18%B5%8Cw%23%B4%B6%10%A4%F2%BF%CFkX%A1S%7F%A4%5E%CCl%1Be%88j%C5%98t%9F%0FNA%CD%25%E1%5E%E2+%93%CB%2Fm%11%D9%E9%5DQ%24%14Sp%1DS%B9%E3%FB%CALu%D4%99A%C7%B7W+%16%10%14%FF%97%7F%CC%05CA%14%FF%9A%FA%7Df%9F%BA%3A%0E%C0%B8%80%25%E2%97%AAZ%B5K%0A%BA%8D%85%07%E25%3B%044n%D5%26%2A%88Q%23%86%8C%17%0D%EBYQ%40%EF%19?ndn.InterestLifetime=10000&ndn.Nonce=2733607158
>> from=265 noNextHop
>>
>> On 02/21/2017 07:16 PM, Junxiao Shi wrote:
>>> Hi Nick
>>>
>>> This line indicates strategy cannot finding a nexthop for
>>> /localhop/nfd/rib/register.
>>> Can you confirm FIB on the node where this log is captured contains
>>> /localhop/nfd or /localhop/nfd/rib entry?
>>> You may inspect FIB with 'nfdc fib list' command.
>>>
>>> Yours, Junxiao
>>>
>>> On Feb 21, 2017 2:04 PM, "Nick Gordon" <nmgordon at memphis.edu <mailto:nmgordon at memphis.edu>
>>> <mailto:nmgordon at memphis.edu>> wrote:
>>>
>>>
>>>    1487713935.381784 DEBUG: [BestRouteStrategy2]
>>>    /localhop/nfd/rib/register/h%19%07%0E%08%03ndn%08%07endhosti%01%00o%01Aj%01%0F/%00%00%01Zb%A9%20%05/%EA%1E%E1%2A%AFm%C8A/%166%1B%01%01%1C1%07%2F%08%03ndn%08%07endhost%08%03KEY%08%11ksk-1487713107245%08%07ID-CERT/%17%FD%01%00%05%19%B3%C68%DC%F8L%B5e%FC%E6%EF%9C%B5%14%B8%BF%CA%BC%FFM%3E%D7%C9z%2A%3BVz%8B%A5Q%81%CA%9Fsf%997%AFZ3%5D%FD%E1%2Aj%A6%A6%23%7Bj%A6R%E2F%82J%92%14%7B%92%BE%C6%902%40%AB%26%1C%83%07%01%12%A9%8Bn%07%F3Tl%0D%D6%98d%ED%A2F%0C%12%EBB-C%B0_%5B%86%B0%9D%3ED8%B47%83s%3C%0BMH%5E%FF%7C%13UtY%95%90%0F%CFm%F2%ECPm%CEj%2F%D8%94%07%C1%7D%28%DA%97%B1%A1%C5s%97%3A%C3%CE%91%29%EB%23A1l4X0Q%AD%05%0F%98e%B1qa%D0%A7Dh%B0%CD%FDw%C2%9E%09%FA%DD%F1%DF%D5%A5%C1%A8%3E%93%E8%11%85%BE%19rg6%DE%A6o%1B%C4E%C1%9F%E6H3N%60%1B%14Y%AE%BD%24%0F%82%0A9l%BC%B0%AF%19%EAzFJs%D6%2A%F0gM%D7%D6%A2%D6%FA%151%07%08G%EDUYPO%0F%12%E7%AFm%A3%9E%B8?ndn.InterestLifetime=10000&ndn.Nonce=763432487
>>>    from=265 noNextHop
>>>

From lanwang at memphis.edu  Wed Feb 22 13:28:11 2017
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Wed, 22 Feb 2017 21:28:11 +0000
Subject: [Nfd-dev] AutoPrefixPropagator inside mini-NDN
In-Reply-To: <42f98c23-a387-9a14-2aaa-68a3abbc668f@memphis.edu>
References: <fcea8400-4590-8e6a-b52c-4beda4028e99@memphis.edu>
	<727DAAA1-8B55-4ED0-83E1-A897341C0A43@memphis.edu>
	<ef6c51b4-c5fe-b3c2-aaff-7735051ad5ae@memphis.edu>
	<CAOFH+Oa_4mBD_aEzT3xZkBYy15PspMvmzJ9xs2c8TcuQLu=bUQ@mail.gmail.com>
	<978be7b3-b07e-b012-15b7-013418466b2c@memphis.edu>
	<C0EFDDB1-DA7F-425B-A314-60E81E880EF6@memphis.edu>
	<42f98c23-a387-9a14-2aaa-68a3abbc668f@memphis.edu>
Message-ID: <20627004-F05B-449A-B8E2-7B7B35E570A6@memphis.edu>

Then the /localhop/nfd prefix was not registered somehow.  I saw that you also tried to register the ?/? prefix, but it?s not in the FIB you printed below either.  You can see what?s the output for the command.  Ask Ashlesh if what you are doing is correct in mini-ndn.

Lan

On Feb 22, 2017, at 2:28 PM, Nicholas Michael Gordon (nmgordon) <nmgordon at memphis.edu<mailto:nmgordon at memphis.edu>> wrote:

I am doing this. These registrations are done on the endhost router not running NLSR, so that AutoPrefixPropagator is told where to
propagate to correctly. In the experiment, I am running these commands on endhost, which represents our "laptop" or something similar:

   endhost.cmd("nfdc register / udp4://" + endhost.IP(links[0][1]))
   endhost.cmd("nfdc register /localhop/nfd udp4://" + endhost.IP(links[0][1]) + " 2>&1")

-Nick

On 02/22/2017 05:50 AM, Lan Wang (lanwang) wrote:
You need to manually create this route.  If you follow Junxiao's post https://yoursunny.com/t/2016/nfd-prefix/,

|

|$ nfdc register / udp4://hobo.cs.arizona.edu Successful in name registration: ControlParameters(Name: /, FaceId: 266, Origin: 255, Cost: 0,
Flags: 1, )|

$ nfdc register /localhop/nfd udp4://hobo.cs.arizona.edu Successful in name registration: ControlParameters(Name: /localhop/nfd, FaceId:
266, Origin: 255, Cost: 0, Flags: 1, )

You will need to replace hobo with your router's name.

|

Lan (on phone)

On Feb 21, 2017, at 9:17 PM, Nicholas Michael Gordon (nmgordon) <nmgordon at memphis.edu<mailto:nmgordon at memphis.edu> <mailto:nmgordon at memphis.edu>> wrote:

I can in fact confirm that the FIB on that router has no /localhop/nfd
entry:

mininet> router1 nfdc fib list
                        ?
FIB:
                        ?
/localhost/nfd/rib nexthops={faceid=260 (cost=0)}
                        ?
/ndn/router1-site/%C1.Router/cs/router1 nexthops={faceid=262 (cost=0)}
                        ?
/ndn/router2-site/router2 nexthops={faceid=261 (cost=10)}
                        ?
/ndn/broadcast/KEYS nexthops={faceid=262 (cost=0), faceid=261
(cost=10)}                         ?
/localhop/ndn/NLSR/LSA nexthops={faceid=261 (cost=10)}
                        ?
/localhop/ndn/NLSR/LSA/router1-site/%C1.Router/cs/router1
nexthops={faceid=262 (cost=0)}         ?
/localhost/nfd nexthops={faceid=1 (cost=0)}
                        ?
/localhop/NLSR/sync nexthops={faceid=262 (cost=0), faceid=261
(cost=10)}                         ?
/ndn/router2-site/%C1.Router/cs/router2 nexthops={faceid=261
(cost=10)}                          ?
/localhost/nlsr nexthops={faceid=262 (cost=0)}

I don't know if that's a problem, because I see /localhost/nfd. However,
since the strategy is looking for localhop specifically, I'm unsure.

After re-running this experiment specifically to look for this message,
I can confirm several entries like this:

1487733093.378927 DEBUG: [BestRouteStrategy2]
/localhop/nfd/rib/register/h%19%07%0E%08%03ndn%08%07endhosti%01%00o%01Aj%01%0F/%00%00%01Zc%CDs%DE/%A2%24%D2%B1%DD%3C_%02/%166%1B%01%01%1C1%07%2F%08%03ndn%08%07endhost%08%03KEY%08%11ksk-1487733015581%08%07ID-CERT/%17%FD%01%00%80%03%92cd%16%EA%DF%92%831%8B%22%FF%DE%A8%A8%A4%83%C9%16%93+%C0x%D7%2Ai%7B%15%981%1D7%94%9A%8D%FD+%D4L%E4%CC%DCs%CE%1C%80%82%01%A8%22%EBN%82%7D%C5%82%19%06%B4%8F%A8%8EG%60%2Cz%E3%7B2%F62%ED%CF%D6l%9F%24%BCH%B1%08a%AA%AA%03%89S%BC%22%F7%E96%01R%EA%3B%99r3t%A7%EA%90g%22%F2%7B%19%A3k%F4q%AF%BFs%BF%B5%86%DA%83%A7g%9AT%AC_%DBw%1BR%60%88%E0H%8As%FC%E9%11%06V%3EL%29%19%D5c%0E%0FD%E8N%BE%FF%A9j%F0UO%2Fd%CB%8E%14%92%DD%DD0%C5l%1E%B4IM%16%28%D1IZ%EE%08%C6%D5%A6%079SY%8B%08i%1Cgm%A6%DE%A2%B17%E8%0B%7E%C7%A5QO%FB%00w%CA%AF%92%7Bsq%BA%CC9w%E6%1Cev%2C0eE%F6x%CFD%15%97%60%A1%A3%60%1C%E0%E2%FD%FB%8E%9E%A2%AE%FAu%3C%27%0E%D6S%0B?ndn.InterestLifetime=10000&ndn.Nonce=419550183
from=265 noNextHop
1487733143.408247 DEBUG: [BestRouteStrategy2]
/localhop/nfd/rib/register/h%19%07%0E%08%03ndn%08%07endhosti%01%00o%01Aj%01%0F/%00%00%01Zc%CE7_/%C6%8F%C9s%B2%E8d%D4/%166%1B%01%01%1C1%07%2F%08%03ndn%08%07endhost%08%03KEY%08%11ksk-1487733015581%08%07ID-CERT/%17%FD%01%00%9Bn%F8%98%FDGOw%06%05%80%7E%7Fn%00%AE%C6A%7E%C7C3%80%B9%81%29b%17Y%F3%AF%9D%D2%B3%04%EEM%E6%7EO-%22%FD%21%E9%DA4%1D%1A%92%7B%B7h+%B5%04%85W%EC%98%8Df%87%9C%97%1C%B0%0F%FAy%AFo%8A%C9%88%5E%06%DE%7CF%81%22%096%10%91%A7K%21%BFt%E5%8Aj%17%A1%84%24%87yH%1C%00%93%B5T%84%0A%9BN%D7%20%E5%C0iM%A7C%B1%C8%AA%AA%E3%FC%BD%14t%FD%26xk%B0%3B%B2%BB%04y%F7-%9C%3EW%21%FEn%03%0E5%ED%86%8F%9D%81%AD%2F%CBk%1F%DA%92%DDh%DBL%08%10%AC%92%2C%C7mmS%F1%15%84%99%01%2A%94%A4%AC%D7D%03%E4%F8dV%BFz%B9%BA%7E%00%AF%16%F1%06%055%5E%C9%3A%9Dc%88%7B%C0%84%D9%F1%18%9CM%DE%25%27%22+%EC%FB%0E%F3%C7vgkVMb%3F%B0%EC%CCO%A7%C6%A4%E0%5E%12%C3%7EU%96%C1%01%C9%9C%25%CB%B7u%AFj?ndn.InterestLifetime=10000&ndn.Nonce=556154061
from=265 noNextHop
1487733243.438657 DEBUG: [BestRouteStrategy2]
/localhop/nfd/rib/register/h%19%07%0E%08%03ndn%08%07endhosti%01%00o%01Aj%01%0F/%00%00%01Zc%CF%BE%1E/%7DN%20K%18%99g%24/%166%1B%01%01%1C1%07%2F%08%03ndn%08%07endhost%08%03KEY%08%11ksk-1487733015581%08%07ID-CERT/%17%FD%01%00%84%B2%D4%DC%CAI%A7%ABW%A8%9E%40%86f%C3%9F%1B8%3Cc%3Fo%3B%D893%E4%94%EA%84T.%88%FF%992K%00%3E%0C%EF%D7%17%E98%F0k%E3%C5U%D8%CC%85%D6%04%03%A4%88%FC%81w%85%B4%CB%BF%27%AF%CF%95%B5%8Du%D5l%8B%BF%C7%E1%FD%F3H4%98u%20%5E%A3%91%DC%21%9E%2C%8D%7B%C9%DF%C8%D6%87%A8%99%1F%29%CA%F8%9D%21gc%B9%3C%7F%22f%E9%FC%D5%0EC%B4_%0EgH%C1%B8A%26%A7%E1%3E%94%A8%18%B5%8Cw%23%B4%B6%10%A4%F2%BF%CFkX%A1S%7F%A4%5E%CCl%1Be%88j%C5%98t%9F%0FNA%CD%25%E1%5E%E2+%93%CB%2Fm%11%D9%E9%5DQ%24%14Sp%1DS%B9%E3%FB%CALu%D4%99A%C7%B7W+%16%10%14%FF%97%7F%CC%05CA%14%FF%9A%FA%7Df%9F%BA%3A%0E%C0%B8%80%25%E2%97%AAZ%B5K%0A%BA%8D%85%07%E25%3B%044n%D5%26%2A%88Q%23%86%8C%17%0D%EBYQ%40%EF%19?ndn.InterestLifetime=10000&ndn.Nonce=2733607158
from=265 noNextHop

On 02/21/2017 07:16 PM, Junxiao Shi wrote:
Hi Nick

This line indicates strategy cannot finding a nexthop for
/localhop/nfd/rib/register.
Can you confirm FIB on the node where this log is captured contains
/localhop/nfd or /localhop/nfd/rib entry?
You may inspect FIB with 'nfdc fib list' command.

Yours, Junxiao

On Feb 21, 2017 2:04 PM, "Nick Gordon" <nmgordon at memphis.edu<mailto:nmgordon at memphis.edu> <mailto:nmgordon at memphis.edu>
<mailto:nmgordon at memphis.edu>> wrote:


  1487713935.381784 DEBUG: [BestRouteStrategy2]
  /localhop/nfd/rib/register/h%19%07%0E%08%03ndn%08%07endhosti%01%00o%01Aj%01%0F/%00%00%01Zb%A9%20%05/%EA%1E%E1%2A%AFm%C8A/%166%1B%01%01%1C1%07%2F%08%03ndn%08%07endhost%08%03KEY%08%11ksk-1487713107245%08%07ID-CERT/%17%FD%01%00%05%19%B3%C68%DC%F8L%B5e%FC%E6%EF%9C%B5%14%B8%BF%CA%BC%FFM%3E%D7%C9z%2A%3BVz%8B%A5Q%81%CA%9Fsf%997%AFZ3%5D%FD%E1%2Aj%A6%A6%23%7Bj%A6R%E2F%82J%92%14%7B%92%BE%C6%902%40%AB%26%1C%83%07%01%12%A9%8Bn%07%F3Tl%0D%D6%98d%ED%A2F%0C%12%EBB-C%B0_%5B%86%B0%9D%3ED8%B47%83s%3C%0BMH%5E%FF%7C%13UtY%95%90%0F%CFm%F2%ECPm%CEj%2F%D8%94%07%C1%7D%28%DA%97%B1%A1%C5s%97%3A%C3%CE%91%29%EB%23A1l4X0Q%AD%05%0F%98e%B1qa%D0%A7Dh%B0%CD%FDw%C2%9E%09%FA%DD%F1%DF%D5%A5%C1%A8%3E%93%E8%11%85%BE%19rg6%DE%A6o%1B%C4E%C1%9F%E6H3N%60%1B%14Y%AE%BD%24%0F%82%0A9l%BC%B0%AF%19%EAzFJs%D6%2A%F0gM%D7%D6%A2%D6%FA%151%07%08G%EDUYPO%0F%12%E7%AFm%A3%9E%B8?ndn.InterestLifetime=10000&ndn.Nonce=763432487
  from=265 noNextHop


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

From nmgordon at memphis.edu  Wed Feb 22 13:37:51 2017
From: nmgordon at memphis.edu (Nick Gordon)
Date: Wed, 22 Feb 2017 15:37:51 -0600
Subject: [Nfd-dev] AutoPrefixPropagator inside mini-NDN
In-Reply-To: <20627004-F05B-449A-B8E2-7B7B35E570A6@memphis.edu>
References: <fcea8400-4590-8e6a-b52c-4beda4028e99@memphis.edu>
	<727DAAA1-8B55-4ED0-83E1-A897341C0A43@memphis.edu>
	<ef6c51b4-c5fe-b3c2-aaff-7735051ad5ae@memphis.edu>
	<CAOFH+Oa_4mBD_aEzT3xZkBYy15PspMvmzJ9xs2c8TcuQLu=bUQ@mail.gmail.com>
	<978be7b3-b07e-b012-15b7-013418466b2c@memphis.edu>
	<C0EFDDB1-DA7F-425B-A314-60E81E880EF6@memphis.edu>
	<42f98c23-a387-9a14-2aaa-68a3abbc668f@memphis.edu>
	<20627004-F05B-449A-B8E2-7B7B35E570A6@memphis.edu>
Message-ID: <815c9271-dbe3-466c-8d7b-f3f6c0a09081@memphis.edu>

Are you supposed to have /localhop/nfd on the "testbed router"? I have it on the endhost:

mininet> endhost nfdc fib list
FIB:
  / nexthops={faceid=260 (cost=0)}
  /localhost/nfd/rib nexthops={faceid=258 (cost=0)}
  /localhop/nfd nexthops={faceid=260 (cost=0)}
  /ndn/endhost/pingserver/ping nexthops={faceid=264 (cost=0), faceid=260 (cost=0)}
  /localhost/nfd nexthops={faceid=1 (cost=0), faceid=260 (cost=0)}

But I don't know how the FIB of the "testbed router" is supposed to look. It currently looks like this:

FIB:
  /localhost/nfd/rib nexthops={faceid=260 (cost=0)}
  /ndn/router1-site/%C1.Router/cs/router1 nexthops={faceid=262 (cost=0)}
  /ndn/router2-site/router2 nexthops={faceid=261 (cost=10)}
  /ndn/broadcast/KEYS nexthops={faceid=262 (cost=0), faceid=261 (cost=10)}
  /localhop/ndn/NLSR/LSA nexthops={faceid=261 (cost=10)}
  /localhop/ndn/NLSR/LSA/router1-site/%C1.Router/cs/router1 nexthops={faceid=262 (cost=0)}
  /localhost/nfd nexthops={faceid=1 (cost=0)}
  /localhop/NLSR/sync nexthops={faceid=262 (cost=0), faceid=261 (cost=10)}
  /ndn/router2-site/%C1.Router/cs/router2 nexthops={faceid=261 (cost=10)}
  /localhost/nlsr nexthops={faceid=262 (cost=0)}

-Nick

On 02/22/2017 03:28 PM, Lan Wang (lanwang) wrote:
> Then the /localhop/nfd prefix was not registered somehow.  I saw that you also tried to register the ?/? prefix, but it?s not in the FIB you
> printed below either.  You can see what?s the output for the command.  Ask Ashlesh if what you are doing is correct in mini-ndn.  
> 
> Lan
> 
>> On Feb 22, 2017, at 2:28 PM, Nicholas Michael Gordon (nmgordon) <nmgordon at memphis.edu <mailto:nmgordon at memphis.edu>> wrote:
>>
>> I am doing this. These registrations are done on the endhost router not running NLSR, so that AutoPrefixPropagator is told where to
>> propagate to correctly. In the experiment, I am running these commands on endhost, which represents our "laptop" or something similar:
>>
>>    endhost.cmd("nfdc register / udp4://" + endhost.IP(links[0][1]))
>>    endhost.cmd("nfdc register /localhop/nfd udp4://" + endhost.IP(links[0][1]) + " 2>&1")
>>
>> -Nick
>>
>> On 02/22/2017 05:50 AM, Lan Wang (lanwang) wrote:
>>> You need to manually create this route.  If you follow Junxiao's post https://yoursunny.com/t/2016/nfd-prefix/,
>>>
>>> |
>>>
>>> |$ nfdc register / udp4://hobo.cs.arizona.edu Successful in name registration: ControlParameters(Name: /, FaceId: 266, Origin: 255, Cost: 0,
>>> Flags: 1, )|
>>>
>>> $ nfdc register /localhop/nfd udp4://hobo.cs.arizona.edu Successful in name registration: ControlParameters(Name: /localhop/nfd, FaceId:
>>> 266, Origin: 255, Cost: 0, Flags: 1, )
>>>
>>> You will need to replace hobo with your router's name.
>>>
>>> |
>>>
>>> Lan (on phone)
>>>
>>> On Feb 21, 2017, at 9:17 PM, Nicholas Michael Gordon (nmgordon) <nmgordon at memphis.edu <mailto:nmgordon at memphis.edu>
>>> <mailto:nmgordon at memphis.edu>> wrote:
>>>
>>>> I can in fact confirm that the FIB on that router has no /localhop/nfd
>>>> entry:
>>>>
>>>> mininet> router1 nfdc fib list
>>>>                         ?
>>>> FIB:
>>>>                         ?
>>>> /localhost/nfd/rib nexthops={faceid=260 (cost=0)}
>>>>                         ?
>>>> /ndn/router1-site/%C1.Router/cs/router1 nexthops={faceid=262 (cost=0)}
>>>>                         ?
>>>> /ndn/router2-site/router2 nexthops={faceid=261 (cost=10)}
>>>>                         ?
>>>> /ndn/broadcast/KEYS nexthops={faceid=262 (cost=0), faceid=261
>>>> (cost=10)}                         ?
>>>> /localhop/ndn/NLSR/LSA nexthops={faceid=261 (cost=10)}
>>>>                         ?
>>>> /localhop/ndn/NLSR/LSA/router1-site/%C1.Router/cs/router1
>>>> nexthops={faceid=262 (cost=0)}         ?
>>>> /localhost/nfd nexthops={faceid=1 (cost=0)}
>>>>                         ?
>>>> /localhop/NLSR/sync nexthops={faceid=262 (cost=0), faceid=261
>>>> (cost=10)}                         ?
>>>> /ndn/router2-site/%C1.Router/cs/router2 nexthops={faceid=261
>>>> (cost=10)}                          ?
>>>> /localhost/nlsr nexthops={faceid=262 (cost=0)}
>>>>
>>>> I don't know if that's a problem, because I see /localhost/nfd. However,
>>>> since the strategy is looking for localhop specifically, I'm unsure.
>>>>
>>>> After re-running this experiment specifically to look for this message,
>>>> I can confirm several entries like this:
>>>>
>>>> 1487733093.378927 DEBUG: [BestRouteStrategy2]
>>>> /localhop/nfd/rib/register/h%19%07%0E%08%03ndn%08%07endhosti%01%00o%01Aj%01%0F/%00%00%01Zc%CDs%DE/%A2%24%D2%B1%DD%3C_%02/%166%1B%01%01%1C1%07%2F%08%03ndn%08%07endhost%08%03KEY%08%11ksk-1487733015581%08%07ID-CERT/%17%FD%01%00%80%03%92cd%16%EA%DF%92%831%8B%22%FF%DE%A8%A8%A4%83%C9%16%93+%C0x%D7%2Ai%7B%15%981%1D7%94%9A%8D%FD+%D4L%E4%CC%DCs%CE%1C%80%82%01%A8%22%EBN%82%7D%C5%82%19%06%B4%8F%A8%8EG%60%2Cz%E3%7B2%F62%ED%CF%D6l%9F%24%BCH%B1%08a%AA%AA%03%89S%BC%22%F7%E96%01R%EA%3B%99r3t%A7%EA%90g%22%F2%7B%19%A3k%F4q%AF%BFs%BF%B5%86%DA%83%A7g%9AT%AC_%DBw%1BR%60%88%E0H%8As%FC%E9%11%06V%3EL%29%19%D5c%0E%0FD%E8N%BE%FF%A9j%F0UO%2Fd%CB%8E%14%92%DD%DD0%C5l%1E%B4IM%16%28%D1IZ%EE%08%C6%D5%A6%079SY%8B%08i%1Cgm%A6%DE%A2%B17%E8%0B%7E%C7%A5QO%FB%00w%CA%AF%92%7Bsq%BA%CC9w%E6%1Cev%2C0eE%F6x%CFD%15%97%60%A1%A3%60%1C%E0%E2%FD%FB%8E%9E%A2%AE%FAu%3C%27%0E%D6S%0B?ndn.InterestLifetime=10000&ndn.Nonce=419550183
>>>> from=265 noNextHop
>>>> 1487733143.408247 DEBUG: [BestRouteStrategy2]
>>>> /localhop/nfd/rib/register/h%19%07%0E%08%03ndn%08%07endhosti%01%00o%01Aj%01%0F/%00%00%01Zc%CE7_/%C6%8F%C9s%B2%E8d%D4/%166%1B%01%01%1C1%07%2F%08%03ndn%08%07endhost%08%03KEY%08%11ksk-1487733015581%08%07ID-CERT/%17%FD%01%00%9Bn%F8%98%FDGOw%06%05%80%7E%7Fn%00%AE%C6A%7E%C7C3%80%B9%81%29b%17Y%F3%AF%9D%D2%B3%04%EEM%E6%7EO-%22%FD%21%E9%DA4%1D%1A%92%7B%B7h+%B5%04%85W%EC%98%8Df%87%9C%97%1C%B0%0F%FAy%AFo%8A%C9%88%5E%06%DE%7CF%81%22%096%10%91%A7K%21%BFt%E5%8Aj%17%A1%84%24%87yH%1C%00%93%B5T%84%0A%9BN%D7%20%E5%C0iM%A7C%B1%C8%AA%AA%E3%FC%BD%14t%FD%26xk%B0%3B%B2%BB%04y%F7-%9C%3EW%21%FEn%03%0E5%ED%86%8F%9D%81%AD%2F%CBk%1F%DA%92%DDh%DBL%08%10%AC%92%2C%C7mmS%F1%15%84%99%01%2A%94%A4%AC%D7D%03%E4%F8dV%BFz%B9%BA%7E%00%AF%16%F1%06%055%5E%C9%3A%9Dc%88%7B%C0%84%D9%F1%18%9CM%DE%25%27%22+%EC%FB%0E%F3%C7vgkVMb%3F%B0%EC%CCO%A7%C6%A4%E0%5E%12%C3%7EU%96%C1%01%C9%9C%25%CB%B7u%AFj?ndn.InterestLifetime=10000&ndn.Nonce=556154061
>>>> from=265 noNextHop
>>>> 1487733243.438657 DEBUG: [BestRouteStrategy2]
>>>> /localhop/nfd/rib/register/h%19%07%0E%08%03ndn%08%07endhosti%01%00o%01Aj%01%0F/%00%00%01Zc%CF%BE%1E/%7DN%20K%18%99g%24/%166%1B%01%01%1C1%07%2F%08%03ndn%08%07endhost%08%03KEY%08%11ksk-1487733015581%08%07ID-CERT/%17%FD%01%00%84%B2%D4%DC%CAI%A7%ABW%A8%9E%40%86f%C3%9F%1B8%3Cc%3Fo%3B%D893%E4%94%EA%84T.%88%FF%992K%00%3E%0C%EF%D7%17%E98%F0k%E3%C5U%D8%CC%85%D6%04%03%A4%88%FC%81w%85%B4%CB%BF%27%AF%CF%95%B5%8Du%D5l%8B%BF%C7%E1%FD%F3H4%98u%20%5E%A3%91%DC%21%9E%2C%8D%7B%C9%DF%C8%D6%87%A8%99%1F%29%CA%F8%9D%21gc%B9%3C%7F%22f%E9%FC%D5%0EC%B4_%0EgH%C1%B8A%26%A7%E1%3E%94%A8%18%B5%8Cw%23%B4%B6%10%A4%F2%BF%CFkX%A1S%7F%A4%5E%CCl%1Be%88j%C5%98t%9F%0FNA%CD%25%E1%5E%E2+%93%CB%2Fm%11%D9%E9%5DQ%24%14Sp%1DS%B9%E3%FB%CALu%D4%99A%C7%B7W+%16%10%14%FF%97%7F%CC%05CA%14%FF%9A%FA%7Df%9F%BA%3A%0E%C0%B8%80%25%E2%97%AAZ%B5K%0A%BA%8D%85%07%E25%3B%044n%D5%26%2A%88Q%23%86%8C%17%0D%EBYQ%40%EF%19?ndn.InterestLifetime=10000&ndn.Nonce=2733607158
>>>> from=265 noNextHop
>>>>
>>>> On 02/21/2017 07:16 PM, Junxiao Shi wrote:
>>>>> Hi Nick
>>>>>
>>>>> This line indicates strategy cannot finding a nexthop for
>>>>> /localhop/nfd/rib/register.
>>>>> Can you confirm FIB on the node where this log is captured contains
>>>>> /localhop/nfd or /localhop/nfd/rib entry?
>>>>> You may inspect FIB with 'nfdc fib list' command.
>>>>>
>>>>> Yours, Junxiao
>>>>>
>>>>> On Feb 21, 2017 2:04 PM, "Nick Gordon" <nmgordon at memphis.edu <mailto:nmgordon at memphis.edu> <mailto:nmgordon at memphis.edu>
>>>>> <mailto:nmgordon at memphis.edu>> wrote:
>>>>>
>>>>>
>>>>>   1487713935.381784 DEBUG: [BestRouteStrategy2]
>>>>>   /localhop/nfd/rib/register/h%19%07%0E%08%03ndn%08%07endhosti%01%00o%01Aj%01%0F/%00%00%01Zb%A9%20%05/%EA%1E%E1%2A%AFm%C8A/%166%1B%01%01%1C1%07%2F%08%03ndn%08%07endhost%08%03KEY%08%11ksk-1487713107245%08%07ID-CERT/%17%FD%01%00%05%19%B3%C68%DC%F8L%B5e%FC%E6%EF%9C%B5%14%B8%BF%CA%BC%FFM%3E%D7%C9z%2A%3BVz%8B%A5Q%81%CA%9Fsf%997%AFZ3%5D%FD%E1%2Aj%A6%A6%23%7Bj%A6R%E2F%82J%92%14%7B%92%BE%C6%902%40%AB%26%1C%83%07%01%12%A9%8Bn%07%F3Tl%0D%D6%98d%ED%A2F%0C%12%EBB-C%B0_%5B%86%B0%9D%3ED8%B47%83s%3C%0BMH%5E%FF%7C%13UtY%95%90%0F%CFm%F2%ECPm%CEj%2F%D8%94%07%C1%7D%28%DA%97%B1%A1%C5s%97%3A%C3%CE%91%29%EB%23A1l4X0Q%AD%05%0F%98e%B1qa%D0%A7Dh%B0%CD%FDw%C2%9E%09%FA%DD%F1%DF%D5%A5%C1%A8%3E%93%E8%11%85%BE%19rg6%DE%A6o%1B%C4E%C1%9F%E6H3N%60%1B%14Y%AE%BD%24%0F%82%0A9l%BC%B0%AF%19%EAzFJs%D6%2A%F0gM%D7%D6%A2%D6%FA%151%07%08G%EDUYPO%0F%12%E7%AFm%A3%9E%B8?ndn.InterestLifetime=10000&ndn.Nonce=763432487
>>>>>   from=265 noNextHop
>>>>>
> 

From lanwang at memphis.edu  Wed Feb 22 13:45:10 2017
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Wed, 22 Feb 2017 21:45:10 +0000
Subject: [Nfd-dev] AutoPrefixPropagator inside mini-NDN
In-Reply-To: <815c9271-dbe3-466c-8d7b-f3f6c0a09081@memphis.edu>
References: <fcea8400-4590-8e6a-b52c-4beda4028e99@memphis.edu>
	<727DAAA1-8B55-4ED0-83E1-A897341C0A43@memphis.edu>
	<ef6c51b4-c5fe-b3c2-aaff-7735051ad5ae@memphis.edu>
	<CAOFH+Oa_4mBD_aEzT3xZkBYy15PspMvmzJ9xs2c8TcuQLu=bUQ@mail.gmail.com>
	<978be7b3-b07e-b012-15b7-013418466b2c@memphis.edu>
	<C0EFDDB1-DA7F-425B-A314-60E81E880EF6@memphis.edu>
	<42f98c23-a387-9a14-2aaa-68a3abbc668f@memphis.edu>
	<20627004-F05B-449A-B8E2-7B7B35E570A6@memphis.edu>
	<815c9271-dbe3-466c-8d7b-f3f6c0a09081@memphis.edu>
Message-ID: <AC4C87D1-879F-4784-A8C5-B69E007BE889@memphis.edu>

My understanding is this:

      autoprefixreg
endhost ?----------> router

You register a prefix on the endhost, then the autoprefixreg functionality on the endhost uses the /localhop/nfd prefix to send the registration interest to router.  So it needs the /localhop/nfd prefix.

Now I checked your log again.  I previously thought it?s from the endhost, now I understand it?s from the router.  That log says it?s actually trying to fetch a key through the /localhop/nfd prefix from the endhost.  So it does need the /localhop/nfd prefix in the FIB.

I guess on the testbed this setup of /localhop/nfd on the router was done by John Dehart already so it?s not mentioned in Junxiao?s blog.  However, you do have to do that in your mini-ndn experiment.

=====================
For NFD development, I feel that the /localhop prefix should be automatically created by NFD whenever there?s a new face to a neighbor created.  This is what /localhop is for and it shouldn?t require any manual configuration.

Lan

On Feb 22, 2017, at 3:37 PM, Nicholas Michael Gordon (nmgordon) <nmgordon at memphis.edu<mailto:nmgordon at memphis.edu>> wrote:

Are you supposed to have /localhop/nfd on the "testbed router"? I have it on the endhost:

mininet> endhost nfdc fib list
FIB:
 / nexthops={faceid=260 (cost=0)}
 /localhost/nfd/rib nexthops={faceid=258 (cost=0)}
 /localhop/nfd nexthops={faceid=260 (cost=0)}
 /ndn/endhost/pingserver/ping nexthops={faceid=264 (cost=0), faceid=260 (cost=0)}
 /localhost/nfd nexthops={faceid=1 (cost=0), faceid=260 (cost=0)}

But I don't know how the FIB of the "testbed router" is supposed to look. It currently looks like this:

FIB:
 /localhost/nfd/rib nexthops={faceid=260 (cost=0)}
 /ndn/router1-site/%C1.Router/cs/router1 nexthops={faceid=262 (cost=0)}
 /ndn/router2-site/router2 nexthops={faceid=261 (cost=10)}
 /ndn/broadcast/KEYS nexthops={faceid=262 (cost=0), faceid=261 (cost=10)}
 /localhop/ndn/NLSR/LSA nexthops={faceid=261 (cost=10)}
 /localhop/ndn/NLSR/LSA/router1-site/%C1.Router/cs/router1 nexthops={faceid=262 (cost=0)}
 /localhost/nfd nexthops={faceid=1 (cost=0)}
 /localhop/NLSR/sync nexthops={faceid=262 (cost=0), faceid=261 (cost=10)}
 /ndn/router2-site/%C1.Router/cs/router2 nexthops={faceid=261 (cost=10)}
 /localhost/nlsr nexthops={faceid=262 (cost=0)}

-Nick

On 02/22/2017 03:28 PM, Lan Wang (lanwang) wrote:
Then the /localhop/nfd prefix was not registered somehow.  I saw that you also tried to register the ?/? prefix, but it?s not in the FIB you
printed below either.  You can see what?s the output for the command.  Ask Ashlesh if what you are doing is correct in mini-ndn.

Lan

On Feb 22, 2017, at 2:28 PM, Nicholas Michael Gordon (nmgordon) <nmgordon at memphis.edu<mailto:nmgordon at memphis.edu> <mailto:nmgordon at memphis.edu>> wrote:

I am doing this. These registrations are done on the endhost router not running NLSR, so that AutoPrefixPropagator is told where to
propagate to correctly. In the experiment, I am running these commands on endhost, which represents our "laptop" or something similar:

  endhost.cmd("nfdc register / udp4://" + endhost.IP(links[0][1]))
  endhost.cmd("nfdc register /localhop/nfd udp4://" + endhost.IP(links[0][1]) + " 2>&1")

-Nick

On 02/22/2017 05:50 AM, Lan Wang (lanwang) wrote:
You need to manually create this route.  If you follow Junxiao's post https://yoursunny.com/t/2016/nfd-prefix/,

|

|$ nfdc register / udp4://hobo.cs.arizona.edu Successful in name registration: ControlParameters(Name: /, FaceId: 266, Origin: 255, Cost: 0,
Flags: 1, )|

$ nfdc register /localhop/nfd udp4://hobo.cs.arizona.edu Successful in name registration: ControlParameters(Name: /localhop/nfd, FaceId:
266, Origin: 255, Cost: 0, Flags: 1, )

You will need to replace hobo with your router's name.

|

Lan (on phone)

On Feb 21, 2017, at 9:17 PM, Nicholas Michael Gordon (nmgordon) <nmgordon at memphis.edu<mailto:nmgordon at memphis.edu> <mailto:nmgordon at memphis.edu>
<mailto:nmgordon at memphis.edu>> wrote:

I can in fact confirm that the FIB on that router has no /localhop/nfd
entry:

mininet> router1 nfdc fib list
                       ?
FIB:
                       ?
/localhost/nfd/rib nexthops={faceid=260 (cost=0)}
                       ?
/ndn/router1-site/%C1.Router/cs/router1 nexthops={faceid=262 (cost=0)}
                       ?
/ndn/router2-site/router2 nexthops={faceid=261 (cost=10)}
                       ?
/ndn/broadcast/KEYS nexthops={faceid=262 (cost=0), faceid=261
(cost=10)}                         ?
/localhop/ndn/NLSR/LSA nexthops={faceid=261 (cost=10)}
                       ?
/localhop/ndn/NLSR/LSA/router1-site/%C1.Router/cs/router1
nexthops={faceid=262 (cost=0)}         ?
/localhost/nfd nexthops={faceid=1 (cost=0)}
                       ?
/localhop/NLSR/sync nexthops={faceid=262 (cost=0), faceid=261
(cost=10)}                         ?
/ndn/router2-site/%C1.Router/cs/router2 nexthops={faceid=261
(cost=10)}                          ?
/localhost/nlsr nexthops={faceid=262 (cost=0)}

I don't know if that's a problem, because I see /localhost/nfd. However,
since the strategy is looking for localhop specifically, I'm unsure.

After re-running this experiment specifically to look for this message,
I can confirm several entries like this:

1487733093.378927 DEBUG: [BestRouteStrategy2]
/localhop/nfd/rib/register/h%19%07%0E%08%03ndn%08%07endhosti%01%00o%01Aj%01%0F/%00%00%01Zc%CDs%DE/%A2%24%D2%B1%DD%3C_%02/%166%1B%01%01%1C1%07%2F%08%03ndn%08%07endhost%08%03KEY%08%11ksk-1487733015581%08%07ID-CERT/%17%FD%01%00%80%03%92cd%16%EA%DF%92%831%8B%22%FF%DE%A8%A8%A4%83%C9%16%93+%C0x%D7%2Ai%7B%15%981%1D7%94%9A%8D%FD+%D4L%E4%CC%DCs%CE%1C%80%82%01%A8%22%EBN%82%7D%C5%82%19%06%B4%8F%A8%8EG%60%2Cz%E3%7B2%F62%ED%CF%D6l%9F%24%BCH%B1%08a%AA%AA%03%89S%BC%22%F7%E96%01R%EA%3B%99r3t%A7%EA%90g%22%F2%7B%19%A3k%F4q%AF%BFs%BF%B5%86%DA%83%A7g%9AT%AC_%DBw%1BR%60%88%E0H%8As%FC%E9%11%06V%3EL%29%19%D5c%0E%0FD%E8N%BE%FF%A9j%F0UO%2Fd%CB%8E%14%92%DD%DD0%C5l%1E%B4IM%16%28%D1IZ%EE%08%C6%D5%A6%079SY%8B%08i%1Cgm%A6%DE%A2%B17%E8%0B%7E%C7%A5QO%FB%00w%CA%AF%92%7Bsq%BA%CC9w%E6%1Cev%2C0eE%F6x%CFD%15%97%60%A1%A3%60%1C%E0%E2%FD%FB%8E%9E%A2%AE%FAu%3C%27%0E%D6S%0B?ndn.InterestLifetime=10000&ndn.Nonce=419550183
from=265 noNextHop
1487733143.408247 DEBUG: [BestRouteStrategy2]
/localhop/nfd/rib/register/h%19%07%0E%08%03ndn%08%07endhosti%01%00o%01Aj%01%0F/%00%00%01Zc%CE7_/%C6%8F%C9s%B2%E8d%D4/%166%1B%01%01%1C1%07%2F%08%03ndn%08%07endhost%08%03KEY%08%11ksk-1487733015581%08%07ID-CERT/%17%FD%01%00%9Bn%F8%98%FDGOw%06%05%80%7E%7Fn%00%AE%C6A%7E%C7C3%80%B9%81%29b%17Y%F3%AF%9D%D2%B3%04%EEM%E6%7EO-%22%FD%21%E9%DA4%1D%1A%92%7B%B7h+%B5%04%85W%EC%98%8Df%87%9C%97%1C%B0%0F%FAy%AFo%8A%C9%88%5E%06%DE%7CF%81%22%096%10%91%A7K%21%BFt%E5%8Aj%17%A1%84%24%87yH%1C%00%93%B5T%84%0A%9BN%D7%20%E5%C0iM%A7C%B1%C8%AA%AA%E3%FC%BD%14t%FD%26xk%B0%3B%B2%BB%04y%F7-%9C%3EW%21%FEn%03%0E5%ED%86%8F%9D%81%AD%2F%CBk%1F%DA%92%DDh%DBL%08%10%AC%92%2C%C7mmS%F1%15%84%99%01%2A%94%A4%AC%D7D%03%E4%F8dV%BFz%B9%BA%7E%00%AF%16%F1%06%055%5E%C9%3A%9Dc%88%7B%C0%84%D9%F1%18%9CM%DE%25%27%22+%EC%FB%0E%F3%C7vgkVMb%3F%B0%EC%CCO%A7%C6%A4%E0%5E%12%C3%7EU%96%C1%01%C9%9C%25%CB%B7u%AFj?ndn.InterestLifetime=10000&ndn.Nonce=556154061
from=265 noNextHop
1487733243.438657 DEBUG: [BestRouteStrategy2]
/localhop/nfd/rib/register/h%19%07%0E%08%03ndn%08%07endhosti%01%00o%01Aj%01%0F/%00%00%01Zc%CF%BE%1E/%7DN%20K%18%99g%24/%166%1B%01%01%1C1%07%2F%08%03ndn%08%07endhost%08%03KEY%08%11ksk-1487733015581%08%07ID-CERT/%17%FD%01%00%84%B2%D4%DC%CAI%A7%ABW%A8%9E%40%86f%C3%9F%1B8%3Cc%3Fo%3B%D893%E4%94%EA%84T.%88%FF%992K%00%3E%0C%EF%D7%17%E98%F0k%E3%C5U%D8%CC%85%D6%04%03%A4%88%FC%81w%85%B4%CB%BF%27%AF%CF%95%B5%8Du%D5l%8B%BF%C7%E1%FD%F3H4%98u%20%5E%A3%91%DC%21%9E%2C%8D%7B%C9%DF%C8%D6%87%A8%99%1F%29%CA%F8%9D%21gc%B9%3C%7F%22f%E9%FC%D5%0EC%B4_%0EgH%C1%B8A%26%A7%E1%3E%94%A8%18%B5%8Cw%23%B4%B6%10%A4%F2%BF%CFkX%A1S%7F%A4%5E%CCl%1Be%88j%C5%98t%9F%0FNA%CD%25%E1%5E%E2+%93%CB%2Fm%11%D9%E9%5DQ%24%14Sp%1DS%B9%E3%FB%CALu%D4%99A%C7%B7W+%16%10%14%FF%97%7F%CC%05CA%14%FF%9A%FA%7Df%9F%BA%3A%0E%C0%B8%80%25%E2%97%AAZ%B5K%0A%BA%8D%85%07%E25%3B%044n%D5%26%2A%88Q%23%86%8C%17%0D%EBYQ%40%EF%19?ndn.InterestLifetime=10000&ndn.Nonce=2733607158
from=265 noNextHop

On 02/21/2017 07:16 PM, Junxiao Shi wrote:
Hi Nick

This line indicates strategy cannot finding a nexthop for
/localhop/nfd/rib/register.
Can you confirm FIB on the node where this log is captured contains
/localhop/nfd or /localhop/nfd/rib entry?
You may inspect FIB with 'nfdc fib list' command.

Yours, Junxiao

On Feb 21, 2017 2:04 PM, "Nick Gordon" <nmgordon at memphis.edu<mailto:nmgordon at memphis.edu> <mailto:nmgordon at memphis.edu> <mailto:nmgordon at memphis.edu>
<mailto:nmgordon at memphis.edu>> wrote:


 1487713935.381784 DEBUG: [BestRouteStrategy2]
 /localhop/nfd/rib/register/h%19%07%0E%08%03ndn%08%07endhosti%01%00o%01Aj%01%0F/%00%00%01Zb%A9%20%05/%EA%1E%E1%2A%AFm%C8A/%166%1B%01%01%1C1%07%2F%08%03ndn%08%07endhost%08%03KEY%08%11ksk-1487713107245%08%07ID-CERT/%17%FD%01%00%05%19%B3%C68%DC%F8L%B5e%FC%E6%EF%9C%B5%14%B8%BF%CA%BC%FFM%3E%D7%C9z%2A%3BVz%8B%A5Q%81%CA%9Fsf%997%AFZ3%5D%FD%E1%2Aj%A6%A6%23%7Bj%A6R%E2F%82J%92%14%7B%92%BE%C6%902%40%AB%26%1C%83%07%01%12%A9%8Bn%07%F3Tl%0D%D6%98d%ED%A2F%0C%12%EBB-C%B0_%5B%86%B0%9D%3ED8%B47%83s%3C%0BMH%5E%FF%7C%13UtY%95%90%0F%CFm%F2%ECPm%CEj%2F%D8%94%07%C1%7D%28%DA%97%B1%A1%C5s%97%3A%C3%CE%91%29%EB%23A1l4X0Q%AD%05%0F%98e%B1qa%D0%A7Dh%B0%CD%FDw%C2%9E%09%FA%DD%F1%DF%D5%A5%C1%A8%3E%93%E8%11%85%BE%19rg6%DE%A6o%1B%C4E%C1%9F%E6H3N%60%1B%14Y%AE%BD%24%0F%82%0A9l%BC%B0%AF%19%EAzFJs%D6%2A%F0gM%D7%D6%A2%D6%FA%151%07%08G%EDUYPO%0F%12%E7%AFm%A3%9E%B8?ndn.InterestLifetime=10000&ndn.Nonce=763432487
 from=265 noNextHop



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

From shijunxiao at email.arizona.edu  Thu Feb 23 08:00:51 2017
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Thu, 23 Feb 2017 09:00:51 -0700
Subject: [Nfd-dev] AutoPrefixPropagator inside mini-NDN
In-Reply-To: <815c9271-dbe3-466c-8d7b-f3f6c0a09081@memphis.edu>
References: <fcea8400-4590-8e6a-b52c-4beda4028e99@memphis.edu>
	<727DAAA1-8B55-4ED0-83E1-A897341C0A43@memphis.edu>
	<ef6c51b4-c5fe-b3c2-aaff-7735051ad5ae@memphis.edu>
	<CAOFH+Oa_4mBD_aEzT3xZkBYy15PspMvmzJ9xs2c8TcuQLu=bUQ@mail.gmail.com>
	<978be7b3-b07e-b012-15b7-013418466b2c@memphis.edu>
	<C0EFDDB1-DA7F-425B-A314-60E81E880EF6@memphis.edu>
	<42f98c23-a387-9a14-2aaa-68a3abbc668f@memphis.edu>
	<20627004-F05B-449A-B8E2-7B7B35E570A6@memphis.edu>
	<815c9271-dbe3-466c-8d7b-f3f6c0a09081@memphis.edu>
Message-ID: <04B63646-9EF1-4A23-A8A4-A939EBA98797@email.arizona.edu>

Hi Nick

> Are you supposed to have /localhop/nfd on the "testbed router??
Yes, a testbed router should have /localhop/nfd/rib in order to accept remote prefix registration commands.
In nfd.conf, add a rib.localhop_security section and that registration would show up.

> But I don't know how the FIB of the "testbed router" is supposed to look.
You may examine the HTTP status page of any existing testbed router to find out. Links can be found on testbed status page <http://www.arl.wustl.edu/~jdd/ndnstatus/ndn_prefix/tbs_ndnx.html>.

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

From malhowaidi at gmail.com  Fri Feb 24 08:38:44 2017
From: malhowaidi at gmail.com (Mohammad Alhowaidi)
Date: Fri, 24 Feb 2017 10:38:44 -0600
Subject: [Nfd-dev] Large NFD content store
Message-ID: <CAOYiq137_YP-Et6yGYjRZo8dHTags3sQ56A74coKMFSs0BpANg@mail.gmail.com>

Hello,

I am working with large amount of data and I was wondering if there is a
direct way in the current NFD implementation to save the data to the disk
instead save it to memory due to the data size. OR should I change the NFD
implementation to do that?

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

From xaiki at endlessm.com  Fri Feb 24 08:52:33 2017
From: xaiki at endlessm.com (Niv Sardi)
Date: Fri, 24 Feb 2017 13:52:33 -0300
Subject: [Nfd-dev] Large NFD content store
In-Reply-To: <CAOYiq137_YP-Et6yGYjRZo8dHTags3sQ56A74coKMFSs0BpANg@mail.gmail.com>
References: <CAOYiq137_YP-Et6yGYjRZo8dHTags3sQ56A74coKMFSs0BpANg@mail.gmail.com>
Message-ID: <CAFOjVw9HaHf3DjcpTY6t4n9eW4j-dh-44t2FuttUPtZFnEBJiw@mail.gmail.com>

i guess you probably want to use a repo for that, there is
https://github.com/named-data/repo-ng and we have an implementation in
https://github.com/endlessm/eos-data-distribution

On Fri, Feb 24, 2017 at 1:38 PM, Mohammad Alhowaidi <malhowaidi at gmail.com>
wrote:

> Hello,
>
> I am working with large amount of data and I was wondering if there is a
> direct way in the current NFD implementation to save the data to the disk
> instead save it to memory due to the data size. OR should I change the NFD
> implementation to do that?
>
> Thanks,
> Mohammad
>
> _______________________________________________
> 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/20170224/af1843a6/attachment.html>

From shijunxiao at email.arizona.edu  Fri Feb 24 08:56:54 2017
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Fri, 24 Feb 2017 16:56:54 +0000
Subject: [Nfd-dev] Large NFD content store
In-Reply-To: <CAOYiq137_YP-Et6yGYjRZo8dHTags3sQ56A74coKMFSs0BpANg@mail.gmail.com>
References: <CAOYiq137_YP-Et6yGYjRZo8dHTags3sQ56A74coKMFSs0BpANg@mail.gmail.com>
Message-ID: <CAOFH+ObVhrvj3yz2XDoKHMS2woWTHYzTWWoK8J5sNmNy=RNESw@mail.gmail.com>

Hi Mohammad

On-disk Content Store is not an existing feature, but can be easily
experimented due to NFD's modular design.
Content Store lookup API has been changed to asynchronous, exactly for
supporting an on-disk Content Store.

To design an on-disk Content Store, some considerations are:

* The disk should be faster than network retrieval. SSD is needed.
* Index should be kept in memory. Full Data packets can be stored in disk.
This avoids forwardi delays in case of a cache miss.
* Keep some full Data packets in memory. You'll need an algorithm to decide
when to move full Data packets onto disk or back into memory.

Yours, Junxiao

On Fri, Feb 24, 2017 at 09:39 Mohammad Alhowaidi <malhowaidi at gmail.com>
wrote:

> Hello,
>
> I am working with large amount of data and I was wondering if there is a
> direct way in the current NFD implementation to save the data to the disk
> instead save it to memory due to the data size. OR should I change the NFD
> implementation to do that?
>
> Thanks,
> Mohammad
> _______________________________________________
> 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/20170224/58c4a38d/attachment.html>

From klaus at cs.arizona.EDU  Sun Feb 26 12:39:12 2017
From: klaus at cs.arizona.EDU (Klaus Schneider)
Date: Sun, 26 Feb 2017 13:39:12 -0700
Subject: [Nfd-dev] [Ndn-interest] Design choice: naming scheme or packet
 payload?
In-Reply-To: <CAOFH+OZ5KsKWokg3PpsUuSyOq9gY7829LTbw1P_Ukbk-xaSrLA@mail.gmail.com>
References: <222010749.247241.1487970899480.ref@mail.yahoo.com>
	<222010749.247241.1487970899480@mail.yahoo.com>
	<CAOFH+OZ5KsKWokg3PpsUuSyOq9gY7829LTbw1P_Ukbk-xaSrLA@mail.gmail.com>
Message-ID: <c02a533c-6312-5542-c7b6-8a66213e62f6@cs.arizona.edu>

Hi Scott,

I think we should also note that using NDNLP headers to modify 
information at intermediate nodes is more a workaround of the current 
implementation than a permanent requirement of NDN.

The information you are talking about is relevant to the endpoints of 
the connection (consumer and producer), but seems completely irrelevant 
to the endpoints of each link on the path. Putting it inside NDNLP is, I 
think, to choose the wrong layer for the task.

An analogy would be that you want a new feature in the IP protocol, 
let's say larger addresses. But instead of changing IPv4, you add the 
larger addresses to all the link/MAC layer protocols on the way and copy 
the information at each hop.

This has two results: First, you bloat the link layer protocols with 
functionality that doesn't belong there. Second, you create a dependency 
for each newly invented link layer protocol to support the shared 
features (e.g. larger addresses).

This failure of decoupling seems to be exactly what is happening with 
NDNLP.


> NDN architecture doesn't allow the payload to be modified

This is true for the current implementation. However, there might be use 
cases for allowing certain parts of the payload or certain metainfo to 
be modified at each node (by keeping them outside the "security 
envelope" of the packet).

Given the bloating of NDNLP, maybe it's time to think about allowing 
intermediate nodes to manipulate well-defined parts of Interest and Data 
packets.


Best regards,
Klaus



On 02/24/2017 10:21 PM, Junxiao Shi wrote:
> Hi Scott
>
> Neither Name nor MetaInfo should be modified on intermediate nodes.
> Instead, hop-by-hop information can appear as NDNLPv2 headers.
> NDNLP is a link protocol for NDN, specifically designed for carrying
> hop-by-hop information. You may find more information about NDNLPv2
> on https://redmine.named-data.net/projects/nfd/wiki/NDNLPv2
> <https://redmine.named-data.net/projects/nfd/wiki/NDNLPv2>
>
> Yours, Junxiao
>
> On Fri, Feb 24, 2017 at 2:14 PM, <scott1091 at yahoo.com
> <mailto:scott1091 at yahoo.com>> wrote:
>
>     Hi all,
>
>     Thanks for accepting my request.
>
>     I am working on a NDN forwarding strategy and consumer/producer
>     applications on ndnSIM. Assuming that there are multiple paths from
>     the consumer to a data source, the goal is to improve data delivery
>     based on cross-layer information from the network, so the consumer
>     can select the best face to send the following Interest packets
>     based on number of hops, node ID, throughput, round-trip delay, and
>     geographical location.
>
>     I see two possible ways to implement that:
>     1. Insert the cross layer information direct in the packet payload
>         Every node along the path would have to update the packet
>     payload or meta data accordingly, and the producer would insert its
>     coordinates.
>         The consumer can then select which face to send the following
>     Interests based on throughput, or distance to content source, or
>     path with less hops, etc.
>         Since the NDN architecture doesn't allow the payload to be
>     modified, intermediate nodes would have to create a copy of the
>     packets. Can I use MetaInfo field?
>
>     2. Design a naming scheme (more common in the literature)
>         Use a naming scheme to accomodate that. For instance the
>     Interest packet would be /<desired_content>/<hop_count>/<+node_id>
>     and the data packet would be something like
>     /<content>/<hop_count>/<lat_long>/<node_id1 + node_id2 + ... +
>     node_idN>, where node_id1-N refers to the nodes along the path.
>
>     Are the two implementations feasible? Could you comment on the
>     recommended way to use information from the network in the
>     forwarding decision?
>
>     Thank you!
>
>
>
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>

From nfd-call-notification at mail1.yoursunny.com  Mon Feb 27 08:00:03 2017
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Mon, 27 Feb 2017 09:00:03 -0700
Subject: [Nfd-dev] NFD call 20170227
Message-ID: <201702271600.v1RG03fW011135@lectura.cs.arizona.edu>

An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20170227/737927e0/attachment-0001.html>

From bzhang at cs.arizona.edu  Mon Feb 27 08:03:22 2017
From: bzhang at cs.arizona.edu (Beichuan Zhang)
Date: Mon, 27 Feb 2017 09:03:22 -0700
Subject: [Nfd-dev] NFD call 20170227
In-Reply-To: <201702271600.v1RG03fW011135@lectura.cs.arizona.edu>
References: <201702271600.v1RG03fW011135@lectura.cs.arizona.edu>
Message-ID: <B04D3CD2-08A7-42A7-89CD-79FA8A4D386F@cs.arizona.edu>

Today?s NFD call is cancelled. We?ll resume on Wednesday.

Beichuan

> On Feb 27, 2017, at 9:00 AM, NFD call notification <nfd-call-notification at mail1.yoursunny.com> wrote:
> 
> Dear folks
> 
> This is a reminder of the upcoming NFD call using Bluejeans https://bluejeans.com/505221277 <https://bluejeans.com/505221277>. The current call time is every Monday 14:00-15:00 Pacific time and every Wednesday 14:00-15:00 Pacific time. The current agenda includes the following issues:
> 
> 
> 
> 
> _______________________________________________
> 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/20170227/08a184be/attachment.html>

From scott1091 at yahoo.com  Sun Feb 26 16:55:45 2017
From: scott1091 at yahoo.com (scott1091 at yahoo.com)
Date: Mon, 27 Feb 2017 00:55:45 +0000 (UTC)
Subject: [Nfd-dev] [Ndn-interest] Design choice: naming scheme or packet
 payload?
In-Reply-To: <c02a533c-6312-5542-c7b6-8a66213e62f6@cs.arizona.edu>
References: <222010749.247241.1487970899480.ref@mail.yahoo.com>
	<222010749.247241.1487970899480@mail.yahoo.com>
	<CAOFH+OZ5KsKWokg3PpsUuSyOq9gY7829LTbw1P_Ukbk-xaSrLA@mail.gmail.com>
	<c02a533c-6312-5542-c7b6-8a66213e62f6@cs.arizona.edu>
Message-ID: <1077704726.1392249.1488156945505@mail.yahoo.com>

Thank you both for your answers.
I believe that the packet information field in the NDNLP is useful for my application. The endpoints can handle the remaining features. I will let you know of any suggestions or struggles in the near future.





 

    On Sunday, February 26, 2017 3:48 PM, Klaus Schneider <klaus at cs.arizona.edu> wrote:
 

 Hi Scott,

I think we should also note that using NDNLP headers to modify 
information at intermediate nodes is more a workaround of the current 
implementation than a permanent requirement of NDN.

The information you are talking about is relevant to the endpoints of 
the connection (consumer and producer), but seems completely irrelevant 
to the endpoints of each link on the path. Putting it inside NDNLP is, I 
think, to choose the wrong layer for the task.

An analogy would be that you want a new feature in the IP protocol, 
let's say larger addresses. But instead of changing IPv4, you add the 
larger addresses to all the link/MAC layer protocols on the way and copy 
the information at each hop.

This has two results: First, you bloat the link layer protocols with 
functionality that doesn't belong there. Second, you create a dependency 
for each newly invented link layer protocol to support the shared 
features (e.g. larger addresses).

This failure of decoupling seems to be exactly what is happening with 
NDNLP.


> NDN architecture doesn't allow the payload to be modified

This is true for the current implementation. However, there might be use 
cases for allowing certain parts of the payload or certain metainfo to 
be modified at each node (by keeping them outside the "security 
envelope" of the packet).

Given the bloating of NDNLP, maybe it's time to think about allowing 
intermediate nodes to manipulate well-defined parts of Interest and Data 
packets.


Best regards,
Klaus



On 02/24/2017 10:21 PM, Junxiao Shi wrote:
> Hi Scott
>
> Neither Name nor MetaInfo should be modified on intermediate nodes.
> Instead, hop-by-hop information can appear as NDNLPv2 headers.
> NDNLP is a link protocol for NDN, specifically designed for carrying
> hop-by-hop information. You may find more information about NDNLPv2
> on https://redmine.named-data.net/projects/nfd/wiki/NDNLPv2
> <https://redmine.named-data.net/projects/nfd/wiki/NDNLPv2>
>
> Yours, Junxiao
>
> On Fri, Feb 24, 2017 at 2:14 PM, <scott1091 at yahoo.com
> <mailto:scott1091 at yahoo.com>> wrote:
>
>? ? Hi all,
>
>? ? Thanks for accepting my request.
>
>? ? I am working on a NDN forwarding strategy and consumer/producer
>? ? applications on ndnSIM. Assuming that there are multiple paths from
>? ? the consumer to a data source, the goal is to improve data delivery
>? ? based on cross-layer information from the network, so the consumer
>? ? can select the best face to send the following Interest packets
>? ? based on number of hops, node ID, throughput, round-trip delay, and
>? ? geographical location.
>
>? ? I see two possible ways to implement that:
>? ? 1. Insert the cross layer information direct in the packet payload
>? ? ? ? Every node along the path would have to update the packet
>? ? payload or meta data accordingly, and the producer would insert its
>? ? coordinates.
>? ? ? ? The consumer can then select which face to send the following
>? ? Interests based on throughput, or distance to content source, or
>? ? path with less hops, etc.
>? ? ? ? Since the NDN architecture doesn't allow the payload to be
>? ? modified, intermediate nodes would have to create a copy of the
>? ? packets. Can I use MetaInfo field?
>
>? ? 2. Design a naming scheme (more common in the literature)
>? ? ? ? Use a naming scheme to accomodate that. For instance the
>? ? Interest packet would be /<desired_content>/<hop_count>/<+node_id>
>? ? and the data packet would be something like
>? ? /<content>/<hop_count>/<lat_long>/<node_id1 + node_id2 + ... +
>? ? node_idN>, where node_id1-N refers to the nodes along the path.
>
>? ? Are the two implementations feasible? Could you comment on the
>? ? recommended way to use information from the network in the
>? ? forwarding decision?
>
>? ? Thank you!
>
>
>
> _______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>


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

From babaeim at clarkson.EDU  Tue Feb 28 09:48:22 2017
From: babaeim at clarkson.EDU (Marzieh Babaeianjelodar)
Date: Tue, 28 Feb 2017 12:48:22 -0500
Subject: [Nfd-dev] NDN questions
Message-ID: <1754A32D-0D62-4C01-9F88-3CBB325D866C@clarkson.edu>

Hi I have some basic questions.

1) 

So in,  min suffix component and max suffix component

I have a interest name: example/fileip.txt/%FD%00%00%01Z%85%8B%86%DE

Why is it saying minsuffix and maxsuffix are 3?

Because 1/2/3 ? Because the document says beyond prefix

2)

I read the documentation and understand that I can exclude one part from the name, 

how do I add that exclusion to my command? Because by default in the exclude this is what it gives me: and I WANT TO give it a specific thing.

3)

I also need a better description about Child selectors if anyone can describe it


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