From bmohammadi at ce.sharif.edu  Mon Jan  2 05:25:35 2017
From: bmohammadi at ce.sharif.edu (bmohammadi)
Date: Mon, 02 Jan 2017 16:55:35 +0330
Subject: [Nfd-dev] The way of updating routers' FIB after handover
Message-ID: <350243b92e57c07cbe752b731b878265@ce.sharif.edu>

Dear NDN Researchers,

I am working on mobility in Named Data Networks. For Simulation I need
to know the exact mechanism of NDN when
producer moves and handover occurs. Actually I need to khow what happens
when a producer detaches from a router
and attaches to a new one and how routers' FIB will be updated after
that event in order to send interest packets 
to the new location of producer.  I would be grateful whether you could
answer my question.

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

From lixia at CS.UCLA.EDU  Mon Jan  2 08:54:41 2017
From: lixia at CS.UCLA.EDU (Lixia Zhang)
Date: Mon, 2 Jan 2017 08:54:41 -0800
Subject: [Nfd-dev] The way of updating routers' FIB after handover
In-Reply-To: <350243b92e57c07cbe752b731b878265@ce.sharif.edu>
References: <350243b92e57c07cbe752b731b878265@ce.sharif.edu>
Message-ID: <30A619C5-0725-44EE-AB74-2F1B4A84BA0D@cs.ucla.edu>


> On Jan 2, 2017, at 5:25 AM, bmohammadi <bmohammadi at ce.sharif.edu> wrote:
> 
> Dear NDN Researchers,
> 
> I am working on mobility in Named Data Networks. For Simulation I need to know the exact mechanism of NDN when
> producer moves and handover occurs. Actually I need to khow what happens when a producer detaches from a router
> and attaches to a new one and how routers' FIB will be updated after that event in order to send interest packets to the new location of producer.  I would be grateful whether you could answer my question.
> 

There are several ways to support NDN producer mobility, as summarized in the paper "A Survey of Mobility Support in Named Data Networking"
https://named-data.net/wp-content/uploads/2016/04/survey_mobility_support_ndn.pdf <https://named-data.net/wp-content/uploads/2016/04/survey_mobility_support_ndn.pdf>

At this time, I believe that people are experimenting with a few of the approaches, for example the "Interest with hint" idea (see Table II in the paper) is used by NDNfit.

Since you are working on NDN mobility, wonder exactly what you plan to do?

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

From nfd-call-notification at mail1.yoursunny.com  Tue Jan  3 06:00:01 2017
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Tue, 3 Jan 2017 07:00:01 -0700
Subject: [Nfd-dev] NFD call 20170103
Message-ID: <201701031400.v03E01Ke013969@lectura.cs.arizona.edu>

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

From shijunxiao at email.arizona.edu  Tue Jan  3 07:43:57 2017
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Tue, 3 Jan 2017 08:43:57 -0700
Subject: [Nfd-dev] The way of updating routers' FIB after handover
In-Reply-To: <9DF0DA90-5470-4F21-9919-FAF211B0584C@cs.ucla.edu>
References: <350243b92e57c07cbe752b731b878265@ce.sharif.edu>
	<30A619C5-0725-44EE-AB74-2F1B4A84BA0D@cs.ucla.edu>
	<0a91ec771d1c9eff10fc6806d8bdd6e4@ce.sharif.edu>
	<9DF0DA90-5470-4F21-9919-FAF211B0584C@cs.ucla.edu>
Message-ID: <CAOFH+OZm89B8pmxxUF=x3x+rMjeCcSu7kZ4bwL+srs0UV462gA@mail.gmail.com>

Hi Bmohammadi

The short term plan for the NDN testbed is to *readvertise a mobile
producer's route into the global routing system*.

   1. The mobile producer application, e.g. ndnpingserver, registers its
   prefix onto the local NFD on the mobile node.
   2. NFD on the mobile node readvertises the producer's prefix to the
   connected router, so that the connected testbed router has a route toward
   the mobile node for this prefix. This step is formerly known as "automatic
   prefix propagation" and is implemented as such.
   3. NFD on the router readvertises the producer's prefix into the global
   routing system (NLSR), so that everyone in the world knows the mobile
   producer is reachable via this router. This feature is designed in
   https://redmine.named-data.net/issues/3784
   <https://redmine.named-data.net/issues/3784> and to be implemented in
   https://redmine.named-data.net/issues/3818
   <https://redmine.named-data.net/issues/3818> .

They will be routing scalability issue when there are many mobile nodes
advertising their prefixes, but we are not there yet.

Yours, Junxiao

On Mon, Jan 2, 2017 at 5:41 PM, Lixia Zhang <lixia at cs.ucla.edu> wrote:
>
> Dear Dr. Zhang,
>
> Thank you very much for your kind response. I have read the paper you
> mentioned but in that paper mobility in "pure NDN" has not been
> investigated.
>
> By "pure NDN", do you mean the use of a routing protocol to support mobile
> producers?
>
> Actually in addition to other solutions I want to compare my approach with
> "pure NDN", but I do not know the way of updating routers' FIB when a
> producer changes it's Point of Attachment.
>
> If one wants to use routing protocol to reflect a producer's connectivity
>  change from one NDN router R1 to another one R2, I think 2 actions are
> needed:
> 1/ de-register the producer's prefix from R1, and
>
This action is implicitly: when R1's face toward the mobile node fails,
NFD-RIB deletes the route, which in turn causes the readvertise module to
withdraw the route from the global routing system.


> 2/ register the prefix with R2.
>
This action is performed using the three steps above.


>
> We meant to make a TR to describe remote prefix registration but haven't
> got there.  There is a slide deck on the topic
> https://redmine.named-data.net/attachments/download/168/remo
> te%20prefix%20registeration-draft2.ppt
> but I dont know whether that still represents the latest implementation.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20170103/1b66a119/attachment.html>

From agawande at memphis.edu  Tue Jan  3 12:10:01 2017
From: agawande at memphis.edu (Ashlesh Gawande (agawande))
Date: Tue, 3 Jan 2017 20:10:01 +0000
Subject: [Nfd-dev] NFD call 20170103
In-Reply-To: <201701031400.v03E01Ke013969@lectura.cs.arizona.edu>
References: <201701031400.v03E01Ke013969@lectura.cs.arizona.edu>
Message-ID: <BN3PR04MB2196C60150E1F4B9C96E5850D96E0@BN3PR04MB2196.namprd04.prod.outlook.com>

Correct link: https://bluejeans.com/505221277/

Ashlesh
________________________________
From: Nfd-dev <nfd-dev-bounces at lists.cs.ucla.edu> on behalf of NFD call notification <nfd-call-notification at mail1.yoursunny.com>
Sent: Tuesday, January 3, 2017 8:00:01 AM
To: nfd-dev at lists.cs.ucla.edu
Subject: [Nfd-dev] NFD call 20170103


Dear folks

This is a reminder of the upcoming NFD call using Bluejeans https://bluejeans.com/394441725. The current call time is every Tuesday 12:00-13:00 Pacific time and every Thursday 13:00-14:00 Pacific time. The current agenda includes the following issues:

________________________________

https://redmine.named-data.net/issues/3904#note-8<https://www.google.com/url?q=https://redmine.named-data.net/issues/3904%23note-8&sa=D&ust=1483455601519000&usg=AFQjCNGK9mkyQe3Dcbd4SyNRKCgVPBdyQQ>

NicManager design

need: Junxiao, Alex, Davide
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20170103/9a907660/attachment-0001.html>

From nfd-call-notification at mail1.yoursunny.com  Thu Jan  5 07:00:03 2017
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Thu, 5 Jan 2017 08:00:03 -0700
Subject: [Nfd-dev] NFD call 20170105
Message-ID: <201701051500.v05F035Y007679@lectura.cs.arizona.edu>

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

From nfd-call-notification at mail1.yoursunny.com  Mon Jan  9 12:53:05 2017
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Mon, 9 Jan 2017 13:53:05 -0700
Subject: [Nfd-dev] NFD call 20170109
Message-ID: <201701092053.v09Kr5bK014731@lectura.cs.arizona.edu>

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

From nfd-call-notification at mail1.yoursunny.com  Wed Jan 11 08:00:02 2017
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Wed, 11 Jan 2017 09:00:02 -0700
Subject: [Nfd-dev] NFD call 20170111
Message-ID: <201701111600.v0BG02K9023989@lectura.cs.arizona.edu>

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

From nfd-call-notification at mail1.yoursunny.com  Wed Jan 11 08:12:55 2017
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Wed, 11 Jan 2017 09:12:55 -0700
Subject: [Nfd-dev] NFD call 20170111
Message-ID: <201701111612.v0BGCtdf008780@lectura.cs.arizona.edu>

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

From toufiqulislam.bd at gmail.com  Wed Jan 11 09:49:30 2017
From: toufiqulislam.bd at gmail.com (Md Toufiqul Islam)
Date: Wed, 11 Jan 2017 18:49:30 +0100
Subject: [Nfd-dev] How to see data retrieve / download time using
 "ndngetfile" command?
Message-ID: <CAJ-PhXUCQ-0+O9XkQpd0hKwk5=Kb62X-gasxtcTkp6S=1cB5dA@mail.gmail.com>

Hello Everyone,

I hope all of you are doing great. I have a very small question which I
couldn't find any solution yet. I believe this is the right place to ask
about.

I have installed nfd, ndn-cxx and Repo-ng on two of computers willing to
insert & retrieve data to & from data repository. I have done this
successfully using ndnputfile & ndngetfile command. But after
retrieving any data using "ndngetfile" command, it doesn't show me any
message regarding how much time it needed to fetch the required data from
the repository. Can anyone help me regarding that? How can I see the
download time?

Here is an example. When I retrieve a file from one computer to other,
ndngetfile shows the following message:

>> ndngetfile /example/data/1/test.txt

INFO: End of file is reached.
INFO: Total # of segments received: 188
INFO: Total # bytes of content received: 187537

On the above, there are no information about retrieve/download time of the
received data. How can I see retrieve/download time? I will be glad to have
valuable reply from yours.

With regards
Muhammad Toufiqul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20170111/6fe6c455/attachment.html>

From klaus at cs.arizona.edu  Wed Jan 11 10:17:51 2017
From: klaus at cs.arizona.edu (Klaus Schneider)
Date: Wed, 11 Jan 2017 11:17:51 -0700
Subject: [Nfd-dev] How to see data retrieve / download time using
 "ndngetfile" command?
In-Reply-To: <CAJ-PhXUCQ-0+O9XkQpd0hKwk5=Kb62X-gasxtcTkp6S=1cB5dA@mail.gmail.com>
References: <CAJ-PhXUCQ-0+O9XkQpd0hKwk5=Kb62X-gasxtcTkp6S=1cB5dA@mail.gmail.com>
Message-ID: <8008c91e-b470-40bd-8326-187c62db7732@cs.arizona.edu>

Hi Muhammad,

you might want to use ndncatchunks/ndnputchunks from 
https://github.com/named-data/ndn-tools

Best regards,
Klaus

On 01/11/2017 10:49 AM, Md Toufiqul Islam wrote:
> Hello Everyone,
>
> I hope all of you are doing great. I have a very small question which I
> couldn't find any solution yet. I believe this is the right place to ask
> about.
>
> I have installed nfd, ndn-cxx and Repo-ng on two of computers willing to
> insert & retrieve data to & from data repository. I have done this
> successfully using ndnputfile & ndngetfile command. But after
> retrieving any data using "ndngetfile" command, it doesn't show me any
> message regarding how much time it needed to fetch the required data
> from the repository. Can anyone help me regarding that? How can I see
> the download time?
>
> Here is an example. When I retrieve a file from one computer to other,
> ndngetfile shows the following message:
>
>>> ndngetfile /example/data/1/test.txt
>
> INFO: End of file is reached.
> INFO: Total # of segments received: 188
> INFO: Total # bytes of content received: 187537
>
> On the above, there are no information about retrieve/download time of
> the received data. How can I see retrieve/download time? I will be glad
> to have valuable reply from yours.
>
> With regards
> Muhammad Toufiqul
>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>

From toufiqulislam.bd at gmail.com  Wed Jan 11 12:49:42 2017
From: toufiqulislam.bd at gmail.com (Md Toufiqul Islam)
Date: Wed, 11 Jan 2017 21:49:42 +0100
Subject: [Nfd-dev] How to see data retrieve / download time using
 "ndngetfile" command?
In-Reply-To: <8008c91e-b470-40bd-8326-187c62db7732@cs.arizona.edu>
References: <CAJ-PhXUCQ-0+O9XkQpd0hKwk5=Kb62X-gasxtcTkp6S=1cB5dA@mail.gmail.com>
	<8008c91e-b470-40bd-8326-187c62db7732@cs.arizona.edu>
Message-ID: <CAJ-PhXX4g42jMGqtpc+vZ2UOTqubX19rhYxwOdZ21UXS-r=Dng@mail.gmail.com>

Dear Klaus,

Thank you so much for your reply.  File transfer / retrieval is not the
problem. Problem is retrieval time (millisecond).

I have already tried ndncatchunks / ndnputchunks. But these doesn't provide
me any information about download time / retrieval time of the contents
either. Is there any other idea ?


Best regards
Muhammad


On Wed, Jan 11, 2017 at 7:17 PM, Klaus Schneider <klaus at cs.arizona.edu>
wrote:

> Hi Muhammad,
>
> you might want to use ndncatchunks/ndnputchunks from
> https://github.com/named-data/ndn-tools
>
> Best regards,
> Klaus
>
>
> On 01/11/2017 10:49 AM, Md Toufiqul Islam wrote:
>
>> Hello Everyone,
>>
>> I hope all of you are doing great. I have a very small question which I
>> couldn't find any solution yet. I believe this is the right place to ask
>> about.
>>
>> I have installed nfd, ndn-cxx and Repo-ng on two of computers willing to
>> insert & retrieve data to & from data repository. I have done this
>> successfully using ndnputfile & ndngetfile command. But after
>> retrieving any data using "ndngetfile" command, it doesn't show me any
>> message regarding how much time it needed to fetch the required data
>> from the repository. Can anyone help me regarding that? How can I see
>> the download time?
>>
>> Here is an example. When I retrieve a file from one computer to other,
>> ndngetfile shows the following message:
>>
>> ndngetfile /example/data/1/test.txt
>>>>
>>>
>> INFO: End of file is reached.
>> INFO: Total # of segments received: 188
>> INFO: Total # bytes of content received: 187537
>>
>> On the above, there are no information about retrieve/download time of
>> the received data. How can I see retrieve/download time? I will be glad
>> to have valuable reply from yours.
>>
>> With regards
>> Muhammad Toufiqul
>>
>>
>> _______________________________________________
>> 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/20170111/45162865/attachment-0001.html>

From klaus at cs.arizona.edu  Wed Jan 11 13:14:10 2017
From: klaus at cs.arizona.edu (Klaus Schneider)
Date: Wed, 11 Jan 2017 14:14:10 -0700
Subject: [Nfd-dev] How to see data retrieve / download time using
 "ndngetfile" command?
In-Reply-To: <CAJ-PhXX4g42jMGqtpc+vZ2UOTqubX19rhYxwOdZ21UXS-r=Dng@mail.gmail.com>
References: <CAJ-PhXUCQ-0+O9XkQpd0hKwk5=Kb62X-gasxtcTkp6S=1cB5dA@mail.gmail.com>
	<8008c91e-b470-40bd-8326-187c62db7732@cs.arizona.edu>
	<CAJ-PhXX4g42jMGqtpc+vZ2UOTqubX19rhYxwOdZ21UXS-r=Dng@mail.gmail.com>
Message-ID: <c8911475-9102-4736-40d9-8f3f230c79ad@cs.arizona.edu>

We are currently updating the ndncatchunks code: 
https://gerrit.named-data.net/#/c/3432/

you can check the code out via "git fetch 
https://gerrit.named-data.net/ndn-tools refs/changes/32/3432/4 && git 
checkout FETCH_HEAD"

It contains a function printSummary() which might be what you want:

> void
> PipelineInterestsFixedWindow::printSummary() const
> {
>   time::steady_clock::duration dur = time::steady_clock::now() - m_startTime;
>   double timePassed = static_cast<double>(dur.count()) / 1000000; // in ms
>   double throughput = (8 * m_receivedSize * 1000) / timePassed;
>   std::string throughputUnit;
>
>   computeThroughput(throughput, throughputUnit);
>
>   std::cerr << "\nAll segments have been received.\n"
>             << "Total # of segments received: " << m_nReceived << "\n"
>             << "Time used: " << timePassed << " ms" << "\n"
>             << "Goodput: " << throughput << " " << throughputUnit << "\n";
> }

Best regards,
Klaus

On 01/11/2017 01:49 PM, Md Toufiqul Islam wrote:
> Dear Klaus,
>
> Thank you so much for your reply.  File transfer / retrieval is not the
> problem. Problem is retrieval time (millisecond).
>
> I have already tried ndncatchunks / ndnputchunks. But these doesn't
> provide me any information about download time / retrieval time of the
> contents either. Is there any other idea ?
>
>
> Best regards
> Muhammad
>
>
> On Wed, Jan 11, 2017 at 7:17 PM, Klaus Schneider <klaus at cs.arizona.edu
> <mailto:klaus at cs.arizona.edu>> wrote:
>
>     Hi Muhammad,
>
>     you might want to use ndncatchunks/ndnputchunks from
>     https://github.com/named-data/ndn-tools
>     <https://github.com/named-data/ndn-tools>
>
>     Best regards,
>     Klaus
>
>
>     On 01/11/2017 10:49 AM, Md Toufiqul Islam wrote:
>
>         Hello Everyone,
>
>         I hope all of you are doing great. I have a very small question
>         which I
>         couldn't find any solution yet. I believe this is the right
>         place to ask
>         about.
>
>         I have installed nfd, ndn-cxx and Repo-ng on two of computers
>         willing to
>         insert & retrieve data to & from data repository. I have done this
>         successfully using ndnputfile & ndngetfile command. But after
>         retrieving any data using "ndngetfile" command, it doesn't show
>         me any
>         message regarding how much time it needed to fetch the required data
>         from the repository. Can anyone help me regarding that? How can
>         I see
>         the download time?
>
>         Here is an example. When I retrieve a file from one computer to
>         other,
>         ndngetfile shows the following message:
>
>                 ndngetfile /example/data/1/test.txt
>
>
>         INFO: End of file is reached.
>         INFO: Total # of segments received: 188
>         INFO: Total # bytes of content received: 187537
>
>         On the above, there are no information about retrieve/download
>         time of
>         the received data. How can I see retrieve/download time? I will
>         be glad
>         to have valuable reply from yours.
>
>         With regards
>         Muhammad Toufiqul
>
>
>         _______________________________________________
>         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>
>
>

From xaiki at endlessm.com  Wed Jan 11 14:20:59 2017
From: xaiki at endlessm.com (Niv Sardi)
Date: Wed, 11 Jan 2017 19:20:59 -0300
Subject: [Nfd-dev] How to see data retrieve / download time using
 "ndngetfile" command?
In-Reply-To: <c8911475-9102-4736-40d9-8f3f230c79ad@cs.arizona.edu>
References: <CAJ-PhXUCQ-0+O9XkQpd0hKwk5=Kb62X-gasxtcTkp6S=1cB5dA@mail.gmail.com>
	<8008c91e-b470-40bd-8326-187c62db7732@cs.arizona.edu>
	<CAJ-PhXX4g42jMGqtpc+vZ2UOTqubX19rhYxwOdZ21UXS-r=Dng@mail.gmail.com>
	<c8911475-9102-4736-40d9-8f3f230c79ad@cs.arizona.edu>
Message-ID: <CAFOjVw86=sbB91wU+Xrd-e-W7UT2ZRozCbZXW3qA1bCD+UNzTA@mail.gmail.com>

Hello,
you can check out our chunks implementation (a little different from the
NDN cat/put chunks one) that implements a GObject layer for
progress/complete signal if that's usefull for you:
https://github.com/endlessm/endless-ndn/blob/master/eos_data_distribution/ndn/chunks.py

On Wed, Jan 11, 2017 at 6:14 PM, Klaus Schneider <klaus at cs.arizona.edu>
wrote:

> We are currently updating the ndncatchunks code:
> https://gerrit.named-data.net/#/c/3432/
>
> you can check the code out via "git fetch https://gerrit.named-data.net/
> ndn-tools refs/changes/32/3432/4 && git checkout FETCH_HEAD"
>
> It contains a function printSummary() which might be what you want:
>
> void
>> PipelineInterestsFixedWindow::printSummary() const
>> {
>>   time::steady_clock::duration dur = time::steady_clock::now() -
>> m_startTime;
>>   double timePassed = static_cast<double>(dur.count()) / 1000000; // in
>> ms
>>   double throughput = (8 * m_receivedSize * 1000) / timePassed;
>>   std::string throughputUnit;
>>
>>   computeThroughput(throughput, throughputUnit);
>>
>>   std::cerr << "\nAll segments have been received.\n"
>>             << "Total # of segments received: " << m_nReceived << "\n"
>>             << "Time used: " << timePassed << " ms" << "\n"
>>             << "Goodput: " << throughput << " " << throughputUnit << "\n";
>> }
>>
>
> Best regards,
> Klaus
>
> On 01/11/2017 01:49 PM, Md Toufiqul Islam wrote:
>
>> Dear Klaus,
>>
>> Thank you so much for your reply.  File transfer / retrieval is not the
>> problem. Problem is retrieval time (millisecond).
>>
>> I have already tried ndncatchunks / ndnputchunks. But these doesn't
>> provide me any information about download time / retrieval time of the
>> contents either. Is there any other idea ?
>>
>>
>> Best regards
>> Muhammad
>>
>>
>> On Wed, Jan 11, 2017 at 7:17 PM, Klaus Schneider <klaus at cs.arizona.edu
>> <mailto:klaus at cs.arizona.edu>> wrote:
>>
>>     Hi Muhammad,
>>
>>     you might want to use ndncatchunks/ndnputchunks from
>>     https://github.com/named-data/ndn-tools
>>     <https://github.com/named-data/ndn-tools>
>>
>>     Best regards,
>>     Klaus
>>
>>
>>     On 01/11/2017 10:49 AM, Md Toufiqul Islam wrote:
>>
>>         Hello Everyone,
>>
>>         I hope all of you are doing great. I have a very small question
>>         which I
>>         couldn't find any solution yet. I believe this is the right
>>         place to ask
>>         about.
>>
>>         I have installed nfd, ndn-cxx and Repo-ng on two of computers
>>         willing to
>>         insert & retrieve data to & from data repository. I have done this
>>         successfully using ndnputfile & ndngetfile command. But after
>>         retrieving any data using "ndngetfile" command, it doesn't show
>>         me any
>>         message regarding how much time it needed to fetch the required
>> data
>>         from the repository. Can anyone help me regarding that? How can
>>         I see
>>         the download time?
>>
>>         Here is an example. When I retrieve a file from one computer to
>>         other,
>>         ndngetfile shows the following message:
>>
>>                 ndngetfile /example/data/1/test.txt
>>
>>
>>         INFO: End of file is reached.
>>         INFO: Total # of segments received: 188
>>         INFO: Total # bytes of content received: 187537
>>
>>         On the above, there are no information about retrieve/download
>>         time of
>>         the received data. How can I see retrieve/download time? I will
>>         be glad
>>         to have valuable reply from yours.
>>
>>         With regards
>>         Muhammad Toufiqul
>>
>>
>>         _______________________________________________
>>         Nfd-dev mailing list
>>         Nfd-dev at lists.cs.ucla.edu <mailto:Nfd-dev at lists.cs.ucla.edu>
>>         http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>         <http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev>
>>
>>
>> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20170111/28b1683a/attachment.html>

From tteixeira at engin.umass.edu  Wed Jan 11 16:53:48 2017
From: tteixeira at engin.umass.edu (Thiago Teixeira)
Date: Thu, 12 Jan 2017 00:53:48 +0000
Subject: [Nfd-dev] Ethernet multicast over multiple wireless hops
In-Reply-To: <CAOFH+ObWRCa7sRJcQ4U1L-s4g+f_mEg+H6Vi4jn4ispPsLDzcA@mail.gmail.com>
References: <5a80a39b92174530b3c95b20525ee710@engin.umass.edu>
	<CAOFH+ObWRCa7sRJcQ4U1L-s4g+f_mEg+H6Vi4jn4ispPsLDzcA@mail.gmail.com>
Message-ID: <d761ea6c558f4beb99300ba3c10d0785@engin.umass.edu>

Hi Junxiao,

Thanks for your comments.
I noticed that faces that use UDP or TCP tunnels seem to relay information over multiple hops, using the same strategy. Ethernet does not.
Could you clarify why this happens please?

I looked into the NFD Developer Guide and this older post:
http://www.lists.cs.ucla.edu/pipermail/ndn-interest/2015-June/000720.html

Thank you,
Thiago


From: Junxiao Shi [mailto:shijunxiao at email.arizona.edu]
Sent: Wednesday, December 21, 2016 8:46 PM
To: Thiago Teixeira <tteixeira at engin.umass.edu>
Cc: <nfd-dev at lists.cs.ucla.edu> <nfd-dev at lists.cs.ucla.edu>; Teng Liang <philoliang2011 at gmail.com>
Subject: Re: [Nfd-dev] Ethernet multicast over multiple wireless hops

Hi Thiago
NFD forwarding as of v0.5.0 is not designed for wireless networks.

Whether an Interest will be forwarded out of the same face as it came in is up to the strategy, as nothing in forwarding pipelines prevents such forwarding.
For BestRouteStrategy2, delete these lines https://github.com/named-data/NFD/blob/037f4ab4b62f42447c78d25ede0755f98409c9cb/daemon/fw/best-route-strategy2.cpp#L71-L73 enables such forwarding.

Incoming Data pipeline will not forward a Data out of the same face as it came in. This can be changed by deleting these lines https://github.com/named-data/NFD/blob/037f4ab4b62f42447c78d25ede0755f98409c9cb/daemon/fw/forwarder.cpp#L365-L367

I do not know the implication on loop detection and PIT aggregation after those changes are made. I'm CCing Teng Liang who recently implemented a broadcast-based forwarding strategy for sensor networks where each node has only one wireless NIC, as he may have a better idea on the implication.

Yours, Junxiao

On Wed, Dec 21, 2016 at 3:14 PM, Thiago Teixeira <tteixeira at engin.umass.edu<mailto:tteixeira at engin.umass.edu>> wrote:
I have a topology of five wireless nodes all running NFD v.0.5. on Ubuntu 16.04. I am using Ethernet as the transport method with one multicast group, as follows face_system.ether. mcast_group 01:00:5E:00:17:AA.

When I test connectivity using NDN-Ping it works between one hop neighbors, but not over multiple hops. I assume that is because the architecture prevents it from sending Int/Data packets over the same face it received, in order to prevent loops. Am I right?

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

From toufiqulislam.bd at gmail.com  Wed Jan 11 18:04:56 2017
From: toufiqulislam.bd at gmail.com (Md Toufiqul Islam)
Date: Thu, 12 Jan 2017 03:04:56 +0100
Subject: [Nfd-dev] How to see data retrieve / download time using
 "ndngetfile" command?
In-Reply-To: <CAFOjVw86=sbB91wU+Xrd-e-W7UT2ZRozCbZXW3qA1bCD+UNzTA@mail.gmail.com>
References: <CAJ-PhXUCQ-0+O9XkQpd0hKwk5=Kb62X-gasxtcTkp6S=1cB5dA@mail.gmail.com>
	<8008c91e-b470-40bd-8326-187c62db7732@cs.arizona.edu>
	<CAJ-PhXX4g42jMGqtpc+vZ2UOTqubX19rhYxwOdZ21UXS-r=Dng@mail.gmail.com>
	<c8911475-9102-4736-40d9-8f3f230c79ad@cs.arizona.edu>
	<CAFOjVw86=sbB91wU+Xrd-e-W7UT2ZRozCbZXW3qA1bCD+UNzTA@mail.gmail.com>
Message-ID: <CAJ-PhXWK_Z3GBeVWERrtGWOrVc6XG4Cii8RmVbfvcsYDeX7GaA@mail.gmail.com>

Dear Klaus,

Thank you once again for your great help. This is exactly what I need. But
as I have very bad programming experience, I couldn't able to configure it
properly. Is is possible or permissible to ask you for the modified cpp &
hpp file so that I can just replace with my old files?

regards
Muhammad

On Wed, Jan 11, 2017 at 11:20 PM, Niv Sardi <xaiki at endlessm.com> wrote:

> Hello,
> you can check out our chunks implementation (a little different from the
> NDN cat/put chunks one) that implements a GObject layer for
> progress/complete signal if that's usefull for you:
> https://github.com/endlessm/endless-ndn/blob/master/eos_
> data_distribution/ndn/chunks.py
>
> On Wed, Jan 11, 2017 at 6:14 PM, Klaus Schneider <klaus at cs.arizona.edu>
> wrote:
>
>> We are currently updating the ndncatchunks code:
>> https://gerrit.named-data.net/#/c/3432/
>>
>> you can check the code out via "git fetch https://gerrit.named-data.net/
>> ndn-tools refs/changes/32/3432/4 && git checkout FETCH_HEAD"
>>
>> It contains a function printSummary() which might be what you want:
>>
>> void
>>> PipelineInterestsFixedWindow::printSummary() const
>>> {
>>>   time::steady_clock::duration dur = time::steady_clock::now() -
>>> m_startTime;
>>>   double timePassed = static_cast<double>(dur.count()) / 1000000; // in
>>> ms
>>>   double throughput = (8 * m_receivedSize * 1000) / timePassed;
>>>   std::string throughputUnit;
>>>
>>>   computeThroughput(throughput, throughputUnit);
>>>
>>>   std::cerr << "\nAll segments have been received.\n"
>>>             << "Total # of segments received: " << m_nReceived << "\n"
>>>             << "Time used: " << timePassed << " ms" << "\n"
>>>             << "Goodput: " << throughput << " " << throughputUnit <<
>>> "\n";
>>> }
>>>
>>
>> Best regards,
>> Klaus
>>
>> On 01/11/2017 01:49 PM, Md Toufiqul Islam wrote:
>>
>>> Dear Klaus,
>>>
>>> Thank you so much for your reply.  File transfer / retrieval is not the
>>> problem. Problem is retrieval time (millisecond).
>>>
>>> I have already tried ndncatchunks / ndnputchunks. But these doesn't
>>> provide me any information about download time / retrieval time of the
>>> contents either. Is there any other idea ?
>>>
>>>
>>> Best regards
>>> Muhammad
>>>
>>>
>>> On Wed, Jan 11, 2017 at 7:17 PM, Klaus Schneider <klaus at cs.arizona.edu
>>> <mailto:klaus at cs.arizona.edu>> wrote:
>>>
>>>     Hi Muhammad,
>>>
>>>     you might want to use ndncatchunks/ndnputchunks from
>>>     https://github.com/named-data/ndn-tools
>>>     <https://github.com/named-data/ndn-tools>
>>>
>>>     Best regards,
>>>     Klaus
>>>
>>>
>>>     On 01/11/2017 10:49 AM, Md Toufiqul Islam wrote:
>>>
>>>         Hello Everyone,
>>>
>>>         I hope all of you are doing great. I have a very small question
>>>         which I
>>>         couldn't find any solution yet. I believe this is the right
>>>         place to ask
>>>         about.
>>>
>>>         I have installed nfd, ndn-cxx and Repo-ng on two of computers
>>>         willing to
>>>         insert & retrieve data to & from data repository. I have done
>>> this
>>>         successfully using ndnputfile & ndngetfile command. But after
>>>         retrieving any data using "ndngetfile" command, it doesn't show
>>>         me any
>>>         message regarding how much time it needed to fetch the required
>>> data
>>>         from the repository. Can anyone help me regarding that? How can
>>>         I see
>>>         the download time?
>>>
>>>         Here is an example. When I retrieve a file from one computer to
>>>         other,
>>>         ndngetfile shows the following message:
>>>
>>>                 ndngetfile /example/data/1/test.txt
>>>
>>>
>>>         INFO: End of file is reached.
>>>         INFO: Total # of segments received: 188
>>>         INFO: Total # bytes of content received: 187537
>>>
>>>         On the above, there are no information about retrieve/download
>>>         time of
>>>         the received data. How can I see retrieve/download time? I will
>>>         be glad
>>>         to have valuable reply from yours.
>>>
>>>         With regards
>>>         Muhammad Toufiqul
>>>
>>>
>>>         _______________________________________________
>>>         Nfd-dev mailing list
>>>         Nfd-dev at lists.cs.ucla.edu <mailto:Nfd-dev at lists.cs.ucla.edu>
>>>         http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>>         <http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev>
>>>
>>>
>>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20170112/fc61833e/attachment.html>

From klaus at cs.arizona.EDU  Wed Jan 11 20:38:50 2017
From: klaus at cs.arizona.EDU (Klaus Schneider)
Date: Wed, 11 Jan 2017 21:38:50 -0700
Subject: [Nfd-dev] How to see data retrieve / download time using
 "ndngetfile" command?
In-Reply-To: <CAJ-PhXWK_Z3GBeVWERrtGWOrVc6XG4Cii8RmVbfvcsYDeX7GaA@mail.gmail.com>
References: <CAJ-PhXUCQ-0+O9XkQpd0hKwk5=Kb62X-gasxtcTkp6S=1cB5dA@mail.gmail.com>
	<8008c91e-b470-40bd-8326-187c62db7732@cs.arizona.edu>
	<CAJ-PhXX4g42jMGqtpc+vZ2UOTqubX19rhYxwOdZ21UXS-r=Dng@mail.gmail.com>
	<c8911475-9102-4736-40d9-8f3f230c79ad@cs.arizona.edu>
	<CAFOjVw86=sbB91wU+Xrd-e-W7UT2ZRozCbZXW3qA1bCD+UNzTA@mail.gmail.com>
	<CAJ-PhXWK_Z3GBeVWERrtGWOrVc6XG4Cii8RmVbfvcsYDeX7GaA@mail.gmail.com>
Message-ID: <c2f88606-17f3-3509-5123-eeaa5d7529b1@cs.arizona.edu>

You can get all the files with:

# git clone https://gerrit.named-data.net/ndn-tools
# cd ndn-tools/
# git fetch https://gerrit.named-data.net/ndn-tools 
refs/changes/32/3432/4 && git checkout FETCH_HEAD

Then look in the folder "ndn-tools/tools/chunks/catchunks"

Moreover, you can find them on gerrit. For example: 
https://gerrit.named-data.net/#/c/3432/4/tools/chunks/catchunks/pipeline-interests-fixed-window.cpp

Best regards,
Klaus

On 01/11/2017 07:04 PM, Md Toufiqul Islam wrote:
> Dear Klaus,
>
> Thank you once again for your great help. This is exactly what I need.
> But as I have very bad programming experience, I couldn't able to
> configure it properly. Is is possible or permissible to ask you for the
> modified cpp & hpp file so that I can just replace with my old files?
>
> regards
> Muhammad
>
> On Wed, Jan 11, 2017 at 11:20 PM, Niv Sardi <xaiki at endlessm.com
> <mailto:xaiki at endlessm.com>> wrote:
>
>     Hello,
>     you can check out our chunks implementation (a little different from
>     the NDN cat/put chunks one) that implements a GObject layer for
>     progress/complete signal if that's usefull for you:
>     https://github.com/endlessm/endless-ndn/blob/master/eos_data_distribution/ndn/chunks.py
>     <https://github.com/endlessm/endless-ndn/blob/master/eos_data_distribution/ndn/chunks.py>
>
>     On Wed, Jan 11, 2017 at 6:14 PM, Klaus Schneider
>     <klaus at cs.arizona.edu <mailto:klaus at cs.arizona.edu>> wrote:
>
>         We are currently updating the ndncatchunks code:
>         https://gerrit.named-data.net/#/c/3432/
>         <https://gerrit.named-data.net/#/c/3432/>
>
>         you can check the code out via "git fetch
>         https://gerrit.named-data.net/ndn-tools
>         <https://gerrit.named-data.net/ndn-tools> refs/changes/32/3432/4
>         && git checkout FETCH_HEAD"
>
>         It contains a function printSummary() which might be what you want:
>
>             void
>             PipelineInterestsFixedWindow::printSummary() const
>             {
>               time::steady_clock::duration dur =
>             time::steady_clock::now() - m_startTime;
>               double timePassed = static_cast<double>(dur.count()) /
>             1000000; // in ms
>               double throughput = (8 * m_receivedSize * 1000) / timePassed;
>               std::string throughputUnit;
>
>               computeThroughput(throughput, throughputUnit);
>
>               std::cerr << "\nAll segments have been received.\n"
>                         << "Total # of segments received: " <<
>             m_nReceived << "\n"
>                         << "Time used: " << timePassed << " ms" << "\n"
>                         << "Goodput: " << throughput << " " <<
>             throughputUnit << "\n";
>             }
>
>
>         Best regards,
>         Klaus
>
>         On 01/11/2017 01:49 PM, Md Toufiqul Islam wrote:
>
>             Dear Klaus,
>
>             Thank you so much for your reply.  File transfer / retrieval
>             is not the
>             problem. Problem is retrieval time (millisecond).
>
>             I have already tried ndncatchunks / ndnputchunks. But these
>             doesn't
>             provide me any information about download time / retrieval
>             time of the
>             contents either. Is there any other idea ?
>
>
>             Best regards
>             Muhammad
>
>
>             On Wed, Jan 11, 2017 at 7:17 PM, Klaus Schneider
>             <klaus at cs.arizona.edu <mailto:klaus at cs.arizona.edu>
>             <mailto:klaus at cs.arizona.edu <mailto:klaus at cs.arizona.edu>>>
>             wrote:
>
>                 Hi Muhammad,
>
>                 you might want to use ndncatchunks/ndnputchunks from
>                 https://github.com/named-data/ndn-tools
>             <https://github.com/named-data/ndn-tools>
>                 <https://github.com/named-data/ndn-tools
>             <https://github.com/named-data/ndn-tools>>
>
>                 Best regards,
>                 Klaus
>
>
>                 On 01/11/2017 10:49 AM, Md Toufiqul Islam wrote:
>
>                     Hello Everyone,
>
>                     I hope all of you are doing great. I have a very
>             small question
>                     which I
>                     couldn't find any solution yet. I believe this is
>             the right
>                     place to ask
>                     about.
>
>                     I have installed nfd, ndn-cxx and Repo-ng on two of
>             computers
>                     willing to
>                     insert & retrieve data to & from data repository. I
>             have done this
>                     successfully using ndnputfile & ndngetfile command.
>             But after
>                     retrieving any data using "ndngetfile" command, it
>             doesn't show
>                     me any
>                     message regarding how much time it needed to fetch
>             the required data
>                     from the repository. Can anyone help me regarding
>             that? How can
>                     I see
>                     the download time?
>
>                     Here is an example. When I retrieve a file from one
>             computer to
>                     other,
>                     ndngetfile shows the following message:
>
>                             ndngetfile /example/data/1/test.txt
>
>
>                     INFO: End of file is reached.
>                     INFO: Total # of segments received: 188
>                     INFO: Total # bytes of content received: 187537
>
>                     On the above, there are no information about
>             retrieve/download
>                     time of
>                     the received data. How can I see retrieve/download
>             time? I will
>                     be glad
>                     to have valuable reply from yours.
>
>                     With regards
>                     Muhammad Toufiqul
>
>
>                     _______________________________________________
>                     Nfd-dev mailing list
>                     Nfd-dev at lists.cs.ucla.edu
>             <mailto:Nfd-dev at lists.cs.ucla.edu>
>             <mailto:Nfd-dev at lists.cs.ucla.edu
>             <mailto:Nfd-dev at lists.cs.ucla.edu>>
>
>             http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>             <http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev>
>
>             <http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>             <http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev>>
>
>
>         _______________________________________________
>         Nfd-dev mailing list
>         Nfd-dev at lists.cs.ucla.edu <mailto:Nfd-dev at lists.cs.ucla.edu>
>         http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>         <http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev>
>
>
>

From toufiqulislam.bd at gmail.com  Thu Jan 12 04:06:01 2017
From: toufiqulislam.bd at gmail.com (Md Toufiqul Islam)
Date: Thu, 12 Jan 2017 13:06:01 +0100
Subject: [Nfd-dev] How to see data retrieve / download time using
 "ndngetfile" command?
In-Reply-To: <c2f88606-17f3-3509-5123-eeaa5d7529b1@cs.arizona.edu>
References: <CAJ-PhXUCQ-0+O9XkQpd0hKwk5=Kb62X-gasxtcTkp6S=1cB5dA@mail.gmail.com>
	<8008c91e-b470-40bd-8326-187c62db7732@cs.arizona.edu>
	<CAJ-PhXX4g42jMGqtpc+vZ2UOTqubX19rhYxwOdZ21UXS-r=Dng@mail.gmail.com>
	<c8911475-9102-4736-40d9-8f3f230c79ad@cs.arizona.edu>
	<CAFOjVw86=sbB91wU+Xrd-e-W7UT2ZRozCbZXW3qA1bCD+UNzTA@mail.gmail.com>
	<CAJ-PhXWK_Z3GBeVWERrtGWOrVc6XG4Cii8RmVbfvcsYDeX7GaA@mail.gmail.com>
	<c2f88606-17f3-3509-5123-eeaa5d7529b1@cs.arizona.edu>
Message-ID: <CAJ-PhXWLXLamxeXaVWzWioSDEjFUEnbgi+TxsaKC1SiuThFqWg@mail.gmail.com>

Hi Klaus,

Thanks for your guideline. I have done exactly how you have explained. But
still no sign of showing the "Time used". Am I doing anything wrong?

*# ndnputchunks -p -v /abc < /home/remoteserver/Downloads/rony.txt*

Loading input ...
Created 1 chunks for prefix /abc
%FD%00%00%01Y%92%7F%7F%60
Data published with name: /abc/%FD%00%00%01Y%92%7F%7F%60


*# ndncatchunks -v -t aimd -S /abc*

RttEstimator initial parameters:
    Alpha = 0.125
    Beta = 0.25
    K = 4
    Initial RTO = 1000 milliseconds
    Min RTO = 200 milliseconds
    Max RTO = 4000 milliseconds
Pipeline basic parameters:
    Max retries on timeout or Nack = 3
    Interest life time = 4000 milliseconds
    Allow stale content
    Verbose output enabled
    Print summary to std err enabled
PipelineInterestsAimd initial parameters:
    Initial congestion window size = 1
    Initial slow start threshold = 2.14748e+09
    Multiplicative decrease factor = 0.5
    Additive increase step = 1
    RTO check interval = 10 milliseconds
    Max retries on timeout or Nack = 3
    Conservative Window Adaptation enabled
    Resetting cwnd to ssthresh when loss event occurs
Data: Name: /abc/%FD%00%00%01Y%92%7F%7F%60/%00%00
MetaInfo: ContentType: 0, FreshnessPeriod: 10000 milliseconds,
FinalBlockId: %00%00
Content: (size: 13)
Signature: (type: 1, value_length: 256)

Discovered version = 1484221546336
Timeout for Interest
/abc?ndn.MinSuffixComponents=3&ndn.MaxSuffixComponents=3&ndn.ChildSelector=1&ndn.Nonce=573151652&ndn.Exclude=*,%FD%00%00%01Y%92%7F%7F%60
Timeout for Interest
/abc?ndn.MinSuffixComponents=3&ndn.MaxSuffixComponents=3&ndn.ChildSelector=1&ndn.Nonce=2787869428&ndn.Exclude=*,%FD%00%00%01Y%92%7F%7F%60
Found data with the latest version: 1484221546336
Hi i am rony




*# ndncatchunks -v -t fixed -S /abc*Data: Name:
/abc/%FD%00%00%01Y%92%7F%7F%60/%00%00
MetaInfo: ContentType: 0, FreshnessPeriod: 10000 milliseconds,
FinalBlockId: %00%00
Content: (size: 13)
Signature: (type: 1, value_length: 256)

Discovered version = 1484221546336
Timeout for Interest
/abc?ndn.MinSuffixComponents=3&ndn.MaxSuffixComponents=3&ndn.ChildSelector=1&ndn.Nonce=3287183225&ndn.Exclude=*,%FD%00%00%01Y%92%7F%7F%60
Timeout for Interest
/abc?ndn.MinSuffixComponents=3&ndn.MaxSuffixComponents=3&ndn.ChildSelector=1&ndn.Nonce=252627901&ndn.Exclude=*,%FD%00%00%01Y%92%7F%7F%60
Found data with the latest version: 1484221546336
Hi i am rony



Best regards
Muhammad

On Thu, Jan 12, 2017 at 5:38 AM, Klaus Schneider <klaus at cs.arizona.edu>
wrote:

> You can get all the files with:
>
> # git clone https://gerrit.named-data.net/ndn-tools
> # cd ndn-tools/
> # git fetch https://gerrit.named-data.net/ndn-tools
> refs/changes/32/3432/4 && git checkout FETCH_HEAD
>
> Then look in the folder "ndn-tools/tools/chunks/catchunks"
>
> Moreover, you can find them on gerrit. For example:
> https://gerrit.named-data.net/#/c/3432/4/tools/chunks/catchu
> nks/pipeline-interests-fixed-window.cpp
>
> Best regards,
> Klaus
>
> On 01/11/2017 07:04 PM, Md Toufiqul Islam wrote:
>
>> Dear Klaus,
>>
>> Thank you once again for your great help. This is exactly what I need.
>> But as I have very bad programming experience, I couldn't able to
>> configure it properly. Is is possible or permissible to ask you for the
>> modified cpp & hpp file so that I can just replace with my old files?
>>
>> regards
>> Muhammad
>>
>> On Wed, Jan 11, 2017 at 11:20 PM, Niv Sardi <xaiki at endlessm.com
>> <mailto:xaiki at endlessm.com>> wrote:
>>
>>     Hello,
>>     you can check out our chunks implementation (a little different from
>>     the NDN cat/put chunks one) that implements a GObject layer for
>>     progress/complete signal if that's usefull for you:
>>     https://github.com/endlessm/endless-ndn/blob/master/eos_data
>> _distribution/ndn/chunks.py
>>     <https://github.com/endlessm/endless-ndn/blob/master/eos_dat
>> a_distribution/ndn/chunks.py>
>>
>>     On Wed, Jan 11, 2017 at 6:14 PM, Klaus Schneider
>>     <klaus at cs.arizona.edu <mailto:klaus at cs.arizona.edu>> wrote:
>>
>>         We are currently updating the ndncatchunks code:
>>         https://gerrit.named-data.net/#/c/3432/
>>         <https://gerrit.named-data.net/#/c/3432/>
>>
>>         you can check the code out via "git fetch
>>         https://gerrit.named-data.net/ndn-tools
>>         <https://gerrit.named-data.net/ndn-tools> refs/changes/32/3432/4
>>         && git checkout FETCH_HEAD"
>>
>>         It contains a function printSummary() which might be what you
>> want:
>>
>>             void
>>             PipelineInterestsFixedWindow::printSummary() const
>>             {
>>               time::steady_clock::duration dur =
>>             time::steady_clock::now() - m_startTime;
>>               double timePassed = static_cast<double>(dur.count()) /
>>             1000000; // in ms
>>               double throughput = (8 * m_receivedSize * 1000) /
>> timePassed;
>>               std::string throughputUnit;
>>
>>               computeThroughput(throughput, throughputUnit);
>>
>>               std::cerr << "\nAll segments have been received.\n"
>>                         << "Total # of segments received: " <<
>>             m_nReceived << "\n"
>>                         << "Time used: " << timePassed << " ms" << "\n"
>>                         << "Goodput: " << throughput << " " <<
>>             throughputUnit << "\n";
>>             }
>>
>>
>>         Best regards,
>>         Klaus
>>
>>         On 01/11/2017 01:49 PM, Md Toufiqul Islam wrote:
>>
>>             Dear Klaus,
>>
>>             Thank you so much for your reply.  File transfer / retrieval
>>             is not the
>>             problem. Problem is retrieval time (millisecond).
>>
>>             I have already tried ndncatchunks / ndnputchunks. But these
>>             doesn't
>>             provide me any information about download time / retrieval
>>             time of the
>>             contents either. Is there any other idea ?
>>
>>
>>             Best regards
>>             Muhammad
>>
>>
>>             On Wed, Jan 11, 2017 at 7:17 PM, Klaus Schneider
>>             <klaus at cs.arizona.edu <mailto:klaus at cs.arizona.edu>
>>             <mailto:klaus at cs.arizona.edu <mailto:klaus at cs.arizona.edu>>>
>>
>>             wrote:
>>
>>                 Hi Muhammad,
>>
>>                 you might want to use ndncatchunks/ndnputchunks from
>>                 https://github.com/named-data/ndn-tools
>>             <https://github.com/named-data/ndn-tools>
>>                 <https://github.com/named-data/ndn-tools
>>             <https://github.com/named-data/ndn-tools>>
>>
>>                 Best regards,
>>                 Klaus
>>
>>
>>                 On 01/11/2017 10:49 AM, Md Toufiqul Islam wrote:
>>
>>                     Hello Everyone,
>>
>>                     I hope all of you are doing great. I have a very
>>             small question
>>                     which I
>>                     couldn't find any solution yet. I believe this is
>>             the right
>>                     place to ask
>>                     about.
>>
>>                     I have installed nfd, ndn-cxx and Repo-ng on two of
>>             computers
>>                     willing to
>>                     insert & retrieve data to & from data repository. I
>>             have done this
>>                     successfully using ndnputfile & ndngetfile command.
>>             But after
>>                     retrieving any data using "ndngetfile" command, it
>>             doesn't show
>>                     me any
>>                     message regarding how much time it needed to fetch
>>             the required data
>>                     from the repository. Can anyone help me regarding
>>             that? How can
>>                     I see
>>                     the download time?
>>
>>                     Here is an example. When I retrieve a file from one
>>             computer to
>>                     other,
>>                     ndngetfile shows the following message:
>>
>>                             ndngetfile /example/data/1/test.txt
>>
>>
>>                     INFO: End of file is reached.
>>                     INFO: Total # of segments received: 188
>>                     INFO: Total # bytes of content received: 187537
>>
>>                     On the above, there are no information about
>>             retrieve/download
>>                     time of
>>                     the received data. How can I see retrieve/download
>>             time? I will
>>                     be glad
>>                     to have valuable reply from yours.
>>
>>                     With regards
>>                     Muhammad Toufiqul
>>
>>
>>                     _______________________________________________
>>                     Nfd-dev mailing list
>>                     Nfd-dev at lists.cs.ucla.edu
>>             <mailto:Nfd-dev at lists.cs.ucla.edu>
>>             <mailto:Nfd-dev at lists.cs.ucla.edu
>>             <mailto:Nfd-dev at lists.cs.ucla.edu>>
>>
>>             http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>             <http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev>
>>
>>             <http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>             <http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev>>
>>
>>
>>         _______________________________________________
>>         Nfd-dev mailing list
>>         Nfd-dev at lists.cs.ucla.edu <mailto:Nfd-dev at lists.cs.ucla.edu>
>>         http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>         <http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev>
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20170112/d49f7175/attachment-0001.html>

From toufiqulislam.bd at gmail.com  Thu Jan 12 04:52:30 2017
From: toufiqulislam.bd at gmail.com (Md Toufiqul Islam)
Date: Thu, 12 Jan 2017 13:52:30 +0100
Subject: [Nfd-dev] How to see data retrieve / download time using
 "ndngetfile" command?
In-Reply-To: <CAJ-PhXWLXLamxeXaVWzWioSDEjFUEnbgi+TxsaKC1SiuThFqWg@mail.gmail.com>
References: <CAJ-PhXUCQ-0+O9XkQpd0hKwk5=Kb62X-gasxtcTkp6S=1cB5dA@mail.gmail.com>
	<8008c91e-b470-40bd-8326-187c62db7732@cs.arizona.edu>
	<CAJ-PhXX4g42jMGqtpc+vZ2UOTqubX19rhYxwOdZ21UXS-r=Dng@mail.gmail.com>
	<c8911475-9102-4736-40d9-8f3f230c79ad@cs.arizona.edu>
	<CAFOjVw86=sbB91wU+Xrd-e-W7UT2ZRozCbZXW3qA1bCD+UNzTA@mail.gmail.com>
	<CAJ-PhXWK_Z3GBeVWERrtGWOrVc6XG4Cii8RmVbfvcsYDeX7GaA@mail.gmail.com>
	<c2f88606-17f3-3509-5123-eeaa5d7529b1@cs.arizona.edu>
	<CAJ-PhXWLXLamxeXaVWzWioSDEjFUEnbgi+TxsaKC1SiuThFqWg@mail.gmail.com>
Message-ID: <CAJ-PhXUAZ7XQRu15xrxWOKLOS5XDKYkSXc+tZc10pZcBqvCZPA@mail.gmail.com>

Dear Mr. Klaus,

I would like to thank you from deep of my heart for your help & guideline.

Things are working perfectly now, exactly what I am looking for. It was my
fault to use a very small txt file for testing purpose.

I wish you all the best. Be well & take care.


Best regards
Muhammad


On Thu, Jan 12, 2017 at 1:06 PM, Md Toufiqul Islam <
toufiqulislam.bd at gmail.com> wrote:

> Hi Klaus,
>
> Thanks for your guideline. I have done exactly how you have explained. But
> still no sign of showing the "Time used". Am I doing anything wrong?
>
> *# ndnputchunks -p -v /abc < /home/remoteserver/Downloads/rony.txt*
>
> Loading input ...
> Created 1 chunks for prefix /abc
> %FD%00%00%01Y%92%7F%7F%60
> Data published with name: /abc/%FD%00%00%01Y%92%7F%7F%60
>
>
> *# ndncatchunks -v -t aimd -S /abc*
>
> RttEstimator initial parameters:
>     Alpha = 0.125
>     Beta = 0.25
>     K = 4
>     Initial RTO = 1000 milliseconds
>     Min RTO = 200 milliseconds
>     Max RTO = 4000 milliseconds
> Pipeline basic parameters:
>     Max retries on timeout or Nack = 3
>     Interest life time = 4000 milliseconds
>     Allow stale content
>     Verbose output enabled
>     Print summary to std err enabled
> PipelineInterestsAimd initial parameters:
>     Initial congestion window size = 1
>     Initial slow start threshold = 2.14748e+09
>     Multiplicative decrease factor = 0.5
>     Additive increase step = 1
>     RTO check interval = 10 milliseconds
>     Max retries on timeout or Nack = 3
>     Conservative Window Adaptation enabled
>     Resetting cwnd to ssthresh when loss event occurs
> Data: Name: /abc/%FD%00%00%01Y%92%7F%7F%60/%00%00
> MetaInfo: ContentType: 0, FreshnessPeriod: 10000 milliseconds,
> FinalBlockId: %00%00
> Content: (size: 13)
> Signature: (type: 1, value_length: 256)
>
> Discovered version = 1484221546336
> Timeout for Interest /abc?ndn.MinSuffixComponents=
> 3&ndn.MaxSuffixComponents=3&ndn.ChildSelector=1&ndn.Nonce=
> 573151652&ndn.Exclude=*,%FD%00%00%01Y%92%7F%7F%60
> Timeout for Interest /abc?ndn.MinSuffixComponents=
> 3&ndn.MaxSuffixComponents=3&ndn.ChildSelector=1&ndn.Nonce=
> 2787869428&ndn.Exclude=*,%FD%00%00%01Y%92%7F%7F%60
> Found data with the latest version: 1484221546336
> Hi i am rony
>
>
>
>
> *# ndncatchunks -v -t fixed -S /abc*Data: Name:
> /abc/%FD%00%00%01Y%92%7F%7F%60/%00%00
> MetaInfo: ContentType: 0, FreshnessPeriod: 10000 milliseconds,
> FinalBlockId: %00%00
> Content: (size: 13)
> Signature: (type: 1, value_length: 256)
>
> Discovered version = 1484221546336
> Timeout for Interest /abc?ndn.MinSuffixComponents=
> 3&ndn.MaxSuffixComponents=3&ndn.ChildSelector=1&ndn.Nonce=
> 3287183225&ndn.Exclude=*,%FD%00%00%01Y%92%7F%7F%60
> Timeout for Interest /abc?ndn.MinSuffixComponents=
> 3&ndn.MaxSuffixComponents=3&ndn.ChildSelector=1&ndn.Nonce=
> 252627901&ndn.Exclude=*,%FD%00%00%01Y%92%7F%7F%60
> Found data with the latest version: 1484221546336
> Hi i am rony
>
>
>
> Best regards
> Muhammad
>
> On Thu, Jan 12, 2017 at 5:38 AM, Klaus Schneider <klaus at cs.arizona.edu>
> wrote:
>
>> You can get all the files with:
>>
>> # git clone https://gerrit.named-data.net/ndn-tools
>> # cd ndn-tools/
>> # git fetch https://gerrit.named-data.net/ndn-tools
>> refs/changes/32/3432/4 && git checkout FETCH_HEAD
>>
>> Then look in the folder "ndn-tools/tools/chunks/catchunks"
>>
>> Moreover, you can find them on gerrit. For example:
>> https://gerrit.named-data.net/#/c/3432/4/tools/chunks/catchu
>> nks/pipeline-interests-fixed-window.cpp
>>
>> Best regards,
>> Klaus
>>
>> On 01/11/2017 07:04 PM, Md Toufiqul Islam wrote:
>>
>>> Dear Klaus,
>>>
>>> Thank you once again for your great help. This is exactly what I need.
>>> But as I have very bad programming experience, I couldn't able to
>>> configure it properly. Is is possible or permissible to ask you for the
>>> modified cpp & hpp file so that I can just replace with my old files?
>>>
>>> regards
>>> Muhammad
>>>
>>> On Wed, Jan 11, 2017 at 11:20 PM, Niv Sardi <xaiki at endlessm.com
>>> <mailto:xaiki at endlessm.com>> wrote:
>>>
>>>     Hello,
>>>     you can check out our chunks implementation (a little different from
>>>     the NDN cat/put chunks one) that implements a GObject layer for
>>>     progress/complete signal if that's usefull for you:
>>>     https://github.com/endlessm/endless-ndn/blob/master/eos_data
>>> _distribution/ndn/chunks.py
>>>     <https://github.com/endlessm/endless-ndn/blob/master/eos_dat
>>> a_distribution/ndn/chunks.py>
>>>
>>>     On Wed, Jan 11, 2017 at 6:14 PM, Klaus Schneider
>>>     <klaus at cs.arizona.edu <mailto:klaus at cs.arizona.edu>> wrote:
>>>
>>>         We are currently updating the ndncatchunks code:
>>>         https://gerrit.named-data.net/#/c/3432/
>>>         <https://gerrit.named-data.net/#/c/3432/>
>>>
>>>         you can check the code out via "git fetch
>>>         https://gerrit.named-data.net/ndn-tools
>>>         <https://gerrit.named-data.net/ndn-tools> refs/changes/32/3432/4
>>>         && git checkout FETCH_HEAD"
>>>
>>>         It contains a function printSummary() which might be what you
>>> want:
>>>
>>>             void
>>>             PipelineInterestsFixedWindow::printSummary() const
>>>             {
>>>               time::steady_clock::duration dur =
>>>             time::steady_clock::now() - m_startTime;
>>>               double timePassed = static_cast<double>(dur.count()) /
>>>             1000000; // in ms
>>>               double throughput = (8 * m_receivedSize * 1000) /
>>> timePassed;
>>>               std::string throughputUnit;
>>>
>>>               computeThroughput(throughput, throughputUnit);
>>>
>>>               std::cerr << "\nAll segments have been received.\n"
>>>                         << "Total # of segments received: " <<
>>>             m_nReceived << "\n"
>>>                         << "Time used: " << timePassed << " ms" << "\n"
>>>                         << "Goodput: " << throughput << " " <<
>>>             throughputUnit << "\n";
>>>             }
>>>
>>>
>>>         Best regards,
>>>         Klaus
>>>
>>>         On 01/11/2017 01:49 PM, Md Toufiqul Islam wrote:
>>>
>>>             Dear Klaus,
>>>
>>>             Thank you so much for your reply.  File transfer / retrieval
>>>             is not the
>>>             problem. Problem is retrieval time (millisecond).
>>>
>>>             I have already tried ndncatchunks / ndnputchunks. But these
>>>             doesn't
>>>             provide me any information about download time / retrieval
>>>             time of the
>>>             contents either. Is there any other idea ?
>>>
>>>
>>>             Best regards
>>>             Muhammad
>>>
>>>
>>>             On Wed, Jan 11, 2017 at 7:17 PM, Klaus Schneider
>>>             <klaus at cs.arizona.edu <mailto:klaus at cs.arizona.edu>
>>>             <mailto:klaus at cs.arizona.edu <mailto:klaus at cs.arizona.edu>>>
>>>
>>>             wrote:
>>>
>>>                 Hi Muhammad,
>>>
>>>                 you might want to use ndncatchunks/ndnputchunks from
>>>                 https://github.com/named-data/ndn-tools
>>>             <https://github.com/named-data/ndn-tools>
>>>                 <https://github.com/named-data/ndn-tools
>>>             <https://github.com/named-data/ndn-tools>>
>>>
>>>                 Best regards,
>>>                 Klaus
>>>
>>>
>>>                 On 01/11/2017 10:49 AM, Md Toufiqul Islam wrote:
>>>
>>>                     Hello Everyone,
>>>
>>>                     I hope all of you are doing great. I have a very
>>>             small question
>>>                     which I
>>>                     couldn't find any solution yet. I believe this is
>>>             the right
>>>                     place to ask
>>>                     about.
>>>
>>>                     I have installed nfd, ndn-cxx and Repo-ng on two of
>>>             computers
>>>                     willing to
>>>                     insert & retrieve data to & from data repository. I
>>>             have done this
>>>                     successfully using ndnputfile & ndngetfile command.
>>>             But after
>>>                     retrieving any data using "ndngetfile" command, it
>>>             doesn't show
>>>                     me any
>>>                     message regarding how much time it needed to fetch
>>>             the required data
>>>                     from the repository. Can anyone help me regarding
>>>             that? How can
>>>                     I see
>>>                     the download time?
>>>
>>>                     Here is an example. When I retrieve a file from one
>>>             computer to
>>>                     other,
>>>                     ndngetfile shows the following message:
>>>
>>>                             ndngetfile /example/data/1/test.txt
>>>
>>>
>>>                     INFO: End of file is reached.
>>>                     INFO: Total # of segments received: 188
>>>                     INFO: Total # bytes of content received: 187537
>>>
>>>                     On the above, there are no information about
>>>             retrieve/download
>>>                     time of
>>>                     the received data. How can I see retrieve/download
>>>             time? I will
>>>                     be glad
>>>                     to have valuable reply from yours.
>>>
>>>                     With regards
>>>                     Muhammad Toufiqul
>>>
>>>
>>>                     _______________________________________________
>>>                     Nfd-dev mailing list
>>>                     Nfd-dev at lists.cs.ucla.edu
>>>             <mailto:Nfd-dev at lists.cs.ucla.edu>
>>>             <mailto:Nfd-dev at lists.cs.ucla.edu
>>>             <mailto:Nfd-dev at lists.cs.ucla.edu>>
>>>
>>>             http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>>             <http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev>
>>>
>>>             <http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>>             <http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev>>
>>>
>>>
>>>         _______________________________________________
>>>         Nfd-dev mailing list
>>>         Nfd-dev at lists.cs.ucla.edu <mailto:Nfd-dev at lists.cs.ucla.edu>
>>>         http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>>         <http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev>
>>>
>>>
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20170112/804e2cf6/attachment-0001.html>

From tteixeira at engin.umass.edu  Thu Jan 12 08:15:41 2017
From: tteixeira at engin.umass.edu (Thiago Teixeira)
Date: Thu, 12 Jan 2017 16:15:41 +0000
Subject: [Nfd-dev] Ethernet multicast over multiple wireless hops
References: <5a80a39b92174530b3c95b20525ee710@engin.umass.edu>
	<CAOFH+ObWRCa7sRJcQ4U1L-s4g+f_mEg+H6Vi4jn4ispPsLDzcA@mail.gmail.com> 
Message-ID: <e52ea8a6897a456eb67c6783eaf30b2f@engin.umass.edu>

Sorry, please disconsider this!



From: Thiago Teixeira
Sent: Wednesday, January 11, 2017 7:54 PM
To: 'Junxiao Shi' <shijunxiao at email.arizona.edu>
Cc: <nfd-dev at lists.cs.ucla.edu> <nfd-dev at lists.cs.ucla.edu>; Teng Liang <philoliang2011 at gmail.com>
Subject: RE: [Nfd-dev] Ethernet multicast over multiple wireless hops

Hi Junxiao,

Thanks for your comments.
I noticed that faces that use UDP or TCP tunnels seem to relay information over multiple hops, using the same strategy. Ethernet does not.
Could you clarify why this happens please?

I looked into the NFD Developer Guide and this older post:
http://www.lists.cs.ucla.edu/pipermail/ndn-interest/2015-June/000720.html

Thank you,
Thiago


From: Junxiao Shi [mailto:shijunxiao at email.arizona.edu]
Sent: Wednesday, December 21, 2016 8:46 PM
To: Thiago Teixeira <tteixeira at engin.umass.edu<mailto:tteixeira at engin.umass.edu>>
Cc: <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>> <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>; Teng Liang <philoliang2011 at gmail.com<mailto:philoliang2011 at gmail.com>>
Subject: Re: [Nfd-dev] Ethernet multicast over multiple wireless hops

Hi Thiago
NFD forwarding as of v0.5.0 is not designed for wireless networks.

Whether an Interest will be forwarded out of the same face as it came in is up to the strategy, as nothing in forwarding pipelines prevents such forwarding.
For BestRouteStrategy2, delete these lines https://github.com/named-data/NFD/blob/037f4ab4b62f42447c78d25ede0755f98409c9cb/daemon/fw/best-route-strategy2.cpp#L71-L73 enables such forwarding.

Incoming Data pipeline will not forward a Data out of the same face as it came in. This can be changed by deleting these lines https://github.com/named-data/NFD/blob/037f4ab4b62f42447c78d25ede0755f98409c9cb/daemon/fw/forwarder.cpp#L365-L367

I do not know the implication on loop detection and PIT aggregation after those changes are made. I'm CCing Teng Liang who recently implemented a broadcast-based forwarding strategy for sensor networks where each node has only one wireless NIC, as he may have a better idea on the implication.

Yours, Junxiao

On Wed, Dec 21, 2016 at 3:14 PM, Thiago Teixeira <tteixeira at engin.umass.edu<mailto:tteixeira at engin.umass.edu>> wrote:
I have a topology of five wireless nodes all running NFD v.0.5. on Ubuntu 16.04. I am using Ethernet as the transport method with one multicast group, as follows face_system.ether. mcast_group 01:00:5E:00:17:AA.

When I test connectivity using NDN-Ping it works between one hop neighbors, but not over multiple hops. I assume that is because the architecture prevents it from sending Int/Data packets over the same face it received, in order to prevent loops. Am I right?

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

From nfd-call-notification at mail1.yoursunny.com  Mon Jan 16 08:00:03 2017
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Mon, 16 Jan 2017 09:00:03 -0700
Subject: [Nfd-dev] NFD call 20170116
Message-ID: <201701161600.v0GG03rh030460@lectura.cs.arizona.edu>

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

From nfd-call-notification at mail1.yoursunny.com  Wed Jan 18 08:00:02 2017
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Wed, 18 Jan 2017 09:00:02 -0700
Subject: [Nfd-dev] NFD call 20170118
Message-ID: <201701181600.v0IG02Bg005386@lectura.cs.arizona.edu>

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

From peter at remap.ucla.edu  Wed Jan 18 10:45:55 2017
From: peter at remap.ucla.edu (Gusev, Peter)
Date: Wed, 18 Jan 2017 18:45:55 +0000
Subject: [Nfd-dev] NFD call 20170118
In-Reply-To: <201701181600.v0IG02Bg005386@lectura.cs.arizona.edu>
References: <201701181600.v0IG02Bg005386@lectura.cs.arizona.edu>
Message-ID: <4D49C76D-1C46-44B4-8E56-8D43D748A5AE@remap.ucla.edu>

Hi all,

I?d like to join the call with the intent to get a feedback on one issue we discussed with JeffT yesterday. This concerns using instance identities vs user identities in ChronoChat. Hopefully, this should be a quick discussion.

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

On Jan 18, 2017, at 8:00 AM, NFD call notification <nfd-call-notification at mail1.yoursunny.com<mailto: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. 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:

________________________________



Jan 16 call is cancelled.


https://redmine.named-data.net/issues/3859<https://www.google.com/url?q=https://redmine.named-data.net/issues/3859&sa=D&ust=1484758802119000&usg=AFQjCNHwvksmzMjI2_BByefSmyFlZMZS1g>

Release planning
AA: 0.5.1 to be the last release before breaking changes to the (general) certificate format, key naming, and (ndn-cxx) new keychain, new validators.
While it is early to say, need a plan on whether to release 0.6.0 (with breaking changes) before NDNcomm or after.

_______________________________________________
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/20170118/bc74e7a9/attachment-0001.html>

From shijunxiao at email.arizona.edu  Wed Jan 18 15:03:40 2017
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Wed, 18 Jan 2017 16:03:40 -0700
Subject: [Nfd-dev] NDNLP Seq Number Length
In-Reply-To: <3043fe41-938c-8987-384f-1717e670787b@cs.arizona.edu>
References: <3043fe41-938c-8987-384f-1717e670787b@cs.arizona.edu>
Message-ID: <CAOFH+OajdV3JCgChYg4v_Z4ELAKEOo0dbMi_2aTyiyZn8tAzwQ@mail.gmail.com>

Hi Klaus

NDNLPv2 spec does not require the Sequence number field to have a specific
width. It's a per-link decision.

Sequence contains a sequence number that is useful in multiple features.
This field is REQUIRED if any enabled feature is using sequence numbers,
otherwise it's OPTIONAL.
Bit width of the sequence is determined on a per-link basis; 8-octet is
recommended for today's links.
A host MUST generate consecutive sequence numbers for outgoing packets on
the same face.


To choose the Sequence width on a link, one should consider a trade-off
between
(1) the Sequence should be wide enough to avoid wrapping sooner than a few
RTTs;
(2) the bandwidth consumption of the Sequence field, especially on low-MTU
links.

The recommendation of 8-octet applies to most links in Internet
infrastructure, home Internet access, data center, etc.
Sensor networks and personal area networks may need shorter Sequence field.
Core Internet (100Gbps or above) may need longer Sequence field.

Yours, Junxiao

On Fri, Jan 13, 2017 at 5:24 PM, Klaus Schneider <klaus at cs.arizona.edu>
wrote:

> Hi Junxiao,
>
> the NDNLP Wiki describes a sequence number as 32bit (
> https://redmine.named-data.net/projects/nfd/wiki/NDNLPv2), but in the
> code it's 64 bit:
>
>
>> #45 Updated by Eric Newberry about 6 hours ago
>>
>> Klaus Schneider wrote:
>>
>> Minor point: The NDNLP Spec. says that the sequence number is a
>> "fixed-width unsigned integer", the ACK number however is "64-bit
>> non-negative integer".
>>
>> Shouldn't it be the same length?
>>
>> Good catch. In the current implementation of NDNLP, a Sequence is defined
>> as a uint64_t. I corrected the slides to use the NDNLP notation.
>>
>
>
> Should we change the Wiki Entry to 64 bit?
>
> Best regards
> Klaus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20170118/8cd9039e/attachment.html>

From jlee700 at illinois.edu  Thu Jan 19 15:32:16 2017
From: jlee700 at illinois.edu (Lee, Jongdeog)
Date: Thu, 19 Jan 2017 23:32:16 +0000
Subject: [Nfd-dev] NDN certificate & auto prefix propagation
Message-ID: <BCBFBC0B008B2443A454A13CD91EBEDA2DC71C9A@CITESMBX6.ad.uillinois.edu>

Dear all,

  Hope all of you are doing good. I have a question for NDN certificates & auto prefix propagation issue.

  Suppose that we have three machines: producer (P), consumer (C), and forwarder (F).

  What I did are followings:

1. P: the valid certificate is installed (/ndn/edu/illinois/jlee700).
    (check here: https://ndncert.named-data.net/cert/list/html)
2. P: nfdc register /ndn/edu/illinois/jlee700 tcp://forwarder's IP.
3. P: ndnpingserver /ndn/edu/illinois/jlee700/test
4. C: nfdc register /ndn/edu/illinois/jlee700 tcp://forwarder's IP.
5. C: ndnping /ndn/edu/illinois/jlee700/test  (NOT WORKING)

  The problem is /ndn/edu/illinois/jlee700 is not registered on F's fib.
  This worked before (3 months ago), but now is not working.
  Any helps would be appreciated.

Best wishes,
Jongdeog Lee (JD)

------------------------------------------------
Ph.D. Student
Department of Computer Science
University of Illinois at Urbana-Champaign
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20170119/7c768832/attachment.html>

From ilyaslahmer93 at gmail.com  Fri Jan 20 13:16:48 2017
From: ilyaslahmer93 at gmail.com (lahmer ilyas)
Date: Fri, 20 Jan 2017 22:16:48 +0100
Subject: [Nfd-dev] can't register a face in ndn
Message-ID: <CAD6hRmkLhop04CmtkBdzKJK9XuQMPy_+JFF+0AGHjR7_=bsCkQ@mail.gmail.com>

Hi, I am trying to register a face in nfd but I'm getting th following
error "public key decoding error". I installed nfd using apt-get and I am
using with two VMs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20170120/c94f4ca6/attachment.html>

From ilyaslahmer93 at gmail.com  Fri Jan 20 13:13:30 2017
From: ilyaslahmer93 at gmail.com (lahmer ilyas)
Date: Fri, 20 Jan 2017 22:13:30 +0100
Subject: [Nfd-dev] can't register a face in ndn
Message-ID: <CAD6hRm=ZQFSqsLadzqTQ3d7jhZO5hDihOQG3jcNBqTmZXwOduA@mail.gmail.com>

Hi, I am trying to register a face in nfd but I'm getting th following
error "public key decoding error". I installed nfd using apt-get and I am
using with two VMs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20170120/a9062019/attachment.html>

From aa at CS.UCLA.EDU  Fri Jan 20 13:21:16 2017
From: aa at CS.UCLA.EDU (Alex Afanasyev)
Date: Fri, 20 Jan 2017 13:21:16 -0800
Subject: [Nfd-dev] can't register a face in ndn
In-Reply-To: <CAD6hRmkLhop04CmtkBdzKJK9XuQMPy_+JFF+0AGHjR7_=bsCkQ@mail.gmail.com>
References: <CAD6hRmkLhop04CmtkBdzKJK9XuQMPy_+JFF+0AGHjR7_=bsCkQ@mail.gmail.com>
Message-ID: <D0E1FF24-FF11-4567-8841-66B25C6BDE19@cs.ucla.edu>

Most likely you have a permission problem for your ~/.ndn folder or something related to it. I can recommend stopping NFD, deleting ~/.ndn folder, executing nfd-start as **your normal user** (it will ask for sudo password in the process), and then start server app.


> On Jan 20, 2017, at 1:16 PM, lahmer ilyas <ilyaslahmer93 at gmail.com> wrote:
> 
> Hi, I am trying to register a face in nfd but I'm getting th following error "public key decoding error". I installed nfd using apt-get and I am using with two VMs
> _______________________________________________
> 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  Fri Jan 20 15:39:47 2017
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Fri, 20 Jan 2017 16:39:47 -0700
Subject: [Nfd-dev] NDN certificate & auto prefix propagation
In-Reply-To: <BCBFBC0B008B2443A454A13CD91EBEDA2DC71C9A@CITESMBX6.ad.uillinois.edu>
References: <BCBFBC0B008B2443A454A13CD91EBEDA2DC71C9A@CITESMBX6.ad.uillinois.edu>
Message-ID: <2A780D2D-EF5F-4264-AB3D-B4BE7131FAF8@email.arizona.edu>

Hi Jongdeog

You never tell the P that F is a testbed router by registering a /localhop/nfd route.
See Let the World Reach Your NFD <https://yoursunny.com/t/2016/nfd-prefix/> ?how to trigger a propagation? section.

Yours, Junxiao

> On Jan 19, 2017, at 4:32 PM, Lee, Jongdeog <jlee700 at illinois.edu> wrote:
> 
> Dear all,
> 
>   Hope all of you are doing good. I have a question for NDN certificates & auto prefix propagation issue. 
> 
>   Suppose that we have three machines: producer (P), consumer (C), and forwarder (F).
> 
>   What I did are followings:
> 
> 1. P: the valid certificate is installed (/ndn/edu/illinois/jlee700). 
>     (check here: https://ndncert.named-data.net/cert/list/html <https://ndncert.named-data.net/cert/list/html>)
> 2. P: nfdc register /ndn/edu/illinois/jlee700 tcp://forwarder's <tcp://forwarder's> IP.
> 3. P: ndnpingserver /ndn/edu/illinois/jlee700/test
> 4. C: nfdc register /ndn/edu/illinois/jlee700 tcp://forwarder's <tcp://forwarder's> IP.
> 5. C: ndnping /ndn/edu/illinois/jlee700/test  (NOT WORKING)
> 
>   The problem is /ndn/edu/illinois/jlee700 is not registered on F's fib.
>   This worked before (3 months ago), but now is not working. 
>   Any helps would be appreciated.
> 
> Best wishes,
> Jongdeog Lee (JD)
> 
> ------------------------------------------------
> Ph.D. Student
> Department of Computer Science
> University of Illinois at Urbana-Champaign
> _______________________________________________
> 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/20170120/25c2bf2d/attachment-0001.html>

From jlee700 at illinois.edu  Mon Jan 23 07:36:07 2017
From: jlee700 at illinois.edu (Lee, Jongdeog)
Date: Mon, 23 Jan 2017 15:36:07 +0000
Subject: [Nfd-dev] NDN certificate & auto prefix propagation
In-Reply-To: <2A780D2D-EF5F-4264-AB3D-B4BE7131FAF8@email.arizona.edu>
References: <BCBFBC0B008B2443A454A13CD91EBEDA2DC71C9A@CITESMBX6.ad.uillinois.edu>,
	<2A780D2D-EF5F-4264-AB3D-B4BE7131FAF8@email.arizona.edu>
Message-ID: <BCBFBC0B008B2443A454A13CD91EBEDA2DC71DA1@CITESMBX6.ad.uillinois.edu>

Hi Junxiao,

  Thanks. I forgot to do 'nfdc register /localhop/nfd udp4://ndnx.cs.illinois.edu'.
  Unfortunately, even with that, it is not working (cannot find the prefix in the router status page)

  Here is the ndndump result at the illinois ndn node after executing ndnpingserver.

=============================================
jdlee at NDNx-server:~$ sudo ndndump | grep jlee
1485185520.982023 From: 128.174.246.46, To: 72.36.112.82, Tunnel Type: UDP, INTEREST: /localhop/nfd/rib/register/h%28%07%1D%08%03ndn%08%03edu%08%08illinois%08%07jlee700i%01%00o%01Aj%01%0F/%00%00%01Y%CB%F4%1D%ED/%0A%BF%9CL%11L%FCW/%16E%1B%01%01%1C%40%07%3E%08%03ndn%08%03edu%08%08illinois%08%03KEY%08%07jlee700%08%11ksk-1474469518919%08%07ID-CERT/%17%FD%01%00S%29k%EC%5Dy%0D%1C%7DZKD%A6%E4%DE%9A%3B%81%DC%A9%F4%CBm%B0%A4%16%97%B8%FB%B6%8Cho%3FfH%A3%1E%F5%C9%23a%5E%E9S%92Gm%DC%0D%C2Sn%9Al%0A%DC%12%B8j%C4b%BB%E93%7E%CEoe%0C%D3%D4Ip%7D%01%CA%13%E9%95%BC%EAnzd%3F%F0%E7%DC%16Vb%FD%E2%AC%06%174%B8%F5%06%AC%CB%F7%25%2A%B9%A4%B4%B8%A2%FB%24%AB%86%CB%CE%C1%E6%9A%04Ai%9A%EE-%7DYC%15%DC%9A%C9%93%83C%FE%87%B2R%9DJ%F4%E5%3F%AE%04f%12%DE%B3%B1%E6%D1%09T%C5%9A%D2%D42%16%27%00%2C%92%AC%18x%FD%96%88%A8d%D9%E8%97%26%E0%CB%D5%E00%E7%C8%0E%5E%92%03%E9%A4%1E%CA%7F%06%AA%EA%CC%AE%F0v%8D%AD%9Fr%86%AF%20%FCJu%7B%92%7C%5E%88%28d%CEg%BB%0DQ%FF%E7%CEl%00%10%2C%9FPK%EB%9C%81%ED%9A%24%93%86%98%CF%F5C0%B2%E7%29%5E%2Fm%EF%8Ex%0B?ndn.InterestLifetime=10000&ndn.Nonce=1902251253
1485185520.991994 From: 72.36.112.82, To: 128.174.246.46, Tunnel Type: UDP, DATA: /localhop/nfd/rib/register/h%28%07%1D%08%03ndn%08%03edu%08%08illinois%08%07jlee700i%01%00o%01Aj%01%0F/%00%00%01Y%CB%F4%1D%ED/%0A%BF%9CL%11L%FCW/%16E%1B%01%01%1C%40%07%3E%08%03ndn%08%03edu%08%08illinois%08%03KEY%08%07jlee700%08%11ksk-1474469518919%08%07ID-CERT/%17%FD%01%00S%29k%EC%5Dy%0D%1C%7DZKD%A6%E4%DE%9A%3B%81%DC%A9%F4%CBm%B0%A4%16%97%B8%FB%B6%8Cho%3FfH%A3%1E%F5%C9%23a%5E%E9S%92Gm%DC%0D%C2Sn%9Al%0A%DC%12%B8j%C4b%BB%E93%7E%CEoe%0C%D3%D4Ip%7D%01%CA%13%E9%95%BC%EAnzd%3F%F0%E7%DC%16Vb%FD%E2%AC%06%174%B8%F5%06%AC%CB%F7%25%2A%B9%A4%B4%B8%A2%FB%24%AB%86%CB%CE%C1%E6%9A%04Ai%9A%EE-%7DYC%15%DC%9A%C9%93%83C%FE%87%B2R%9DJ%F4%E5%3F%AE%04f%12%DE%B3%B1%E6%D1%09T%C5%9A%D2%D42%16%27%00%2C%92%AC%18x%FD%96%88%A8d%D9%E8%97%26%E0%CB%D5%E00%E7%C8%0E%5E%92%03%E9%A4%1E%CA%7F%06%AA%EA%CC%AE%F0v%8D%AD%9Fr%86%AF%20%FCJu%7B%92%7C%5E%88%28d%CEg%BB%0DQ%FF%E7%CEl%00%10%2C%9FPK%EB%9C%81%ED%9A%24%93%86%98%CF%F5C0%B2%E7%29%5E%2Fm%EF%8Ex%0B
=============================================

  Any other suggestions?

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, January 20, 2017 5:39 PM
To: Lee, Jongdeog
Cc: nfd-dev at lists.cs.ucla.edu
Subject: Re: [Nfd-dev] NDN certificate & auto prefix propagation

Hi Jongdeog

You never tell the P that F is a testbed router by registering a /localhop/nfd route.
See Let the World Reach Your NFD<https://urldefense.proofpoint.com/v2/url?u=https-3A__yoursunny.com_t_2016_nfd-2Dprefix_&d=DwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Z7ZyWHGeVXO4-LRL2FeI1ZE8d269MMOL_mjEf1LVJpE&m=0rQcv-WCZ7t0cVhSKB28pTRRgN_QS3JXIAQICEzrzfk&s=WLNjQT6w4TAlRrgSWT9vpuA_dAQYC5s2ovjwOqiK1jo&e=> ?how to trigger a propagation? section.

Yours, Junxiao

On Jan 19, 2017, at 4:32 PM, Lee, Jongdeog <jlee700 at illinois.edu<mailto:jlee700 at illinois.edu>> wrote:

Dear all,

  Hope all of you are doing good. I have a question for NDN certificates & auto prefix propagation issue.

  Suppose that we have three machines: producer (P), consumer (C), and forwarder (F).

  What I did are followings:

1. P: the valid certificate is installed (/ndn/edu/illinois/jlee700).
    (check here: https://ndncert.named-data.net/cert/list/html<https://urldefense.proofpoint.com/v2/url?u=https-3A__ndncert.named-2Ddata.net_cert_list_html&d=DwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Z7ZyWHGeVXO4-LRL2FeI1ZE8d269MMOL_mjEf1LVJpE&m=0rQcv-WCZ7t0cVhSKB28pTRRgN_QS3JXIAQICEzrzfk&s=-0dDA0cy_hgZTqK6RKHXGEI-tXyRSOCncqVkVj9ZfJ8&e=>)
2. P: nfdc register /ndn/edu/illinois/jlee700 tcp://forwarder's<UrlBlockedError.aspx> IP.
3. P: ndnpingserver /ndn/edu/illinois/jlee700/test
4. C: nfdc register /ndn/edu/illinois/jlee700 tcp://forwarder's<UrlBlockedError.aspx> IP.
5. C: ndnping /ndn/edu/illinois/jlee700/test  (NOT WORKING)

  The problem is /ndn/edu/illinois/jlee700 is not registered on F's fib.
  This worked before (3 months ago), but now is not working.
  Any helps would be appreciated.

Best wishes,
Jongdeog Lee (JD)

------------------------------------------------
Ph.D. Student
Department of Computer Science
University of Illinois at Urbana-Champaign
_______________________________________________
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<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.lists.cs.ucla.edu_mailman_listinfo_nfd-2Ddev&d=DwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Z7ZyWHGeVXO4-LRL2FeI1ZE8d269MMOL_mjEf1LVJpE&m=0rQcv-WCZ7t0cVhSKB28pTRRgN_QS3JXIAQICEzrzfk&s=zWB5S_4iv0E-_TSM5ZGd6ms1mPYxBOQOppjxU6bymdI&e=>

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

From nfd-call-notification at mail1.yoursunny.com  Mon Jan 23 08:00:02 2017
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Mon, 23 Jan 2017 09:00:02 -0700
Subject: [Nfd-dev] NFD call 20170123
Message-ID: <201701231600.v0NG025T017211@lectura.cs.arizona.edu>

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

From shijunxiao at email.arizona.edu  Mon Jan 23 08:03:33 2017
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Mon, 23 Jan 2017 09:03:33 -0700
Subject: [Nfd-dev] NDN certificate & auto prefix propagation
In-Reply-To: <BCBFBC0B008B2443A454A13CD91EBEDA2DC71DA1@CITESMBX6.ad.uillinois.edu>
References: <BCBFBC0B008B2443A454A13CD91EBEDA2DC71C9A@CITESMBX6.ad.uillinois.edu>
	<2A780D2D-EF5F-4264-AB3D-B4BE7131FAF8@email.arizona.edu>
	<BCBFBC0B008B2443A454A13CD91EBEDA2DC71DA1@CITESMBX6.ad.uillinois.edu>
Message-ID: <CAOFH+OaHov=Je24j9zpTdZxt-FHeGmWF7r6h7bUZG8NZZC8xBg@mail.gmail.com>

HI Jongdeog

Can you attach tcpdump logs (.pcap) instead of ndndump text output?
ndndump cannot show Data payload so it's useless to see what's the error.

Yours, Junxiao

On Mon, Jan 23, 2017 at 8:36 AM, Lee, Jongdeog <jlee700 at illinois.edu> wrote:

> Hi Junxiao,
>
>   Thanks. I forgot to do 'nfdc register /localhop/nfd udp4://
> ndnx.cs.illinois.edu'.
>   Unfortunately, even with that, it is not working (cannot find the prefix
> in the router status page)
>
>   Here is the ndndump result at the illinois ndn node after executing
> ndnpingserver.
>
> =============================================
> jdlee at NDNx-server:~$ sudo ndndump | grep jlee
> 1485185520.982023 From: 128.174.246.46, To: 72.36.112.82, Tunnel Type:
> UDP, INTEREST: /localhop/nfd/rib/register/h%28%07%1D%08%03ndn%08%03edu%08%
> 08illinois%08%07jlee700i%01%00o%01Aj%01%0F/%00%00%01Y%CB%
> F4%1D%ED/%0A%BF%9CL%11L%FCW/%16E%1B%01%01%1C%40%07%3E%08%
> 03ndn%08%03edu%08%08illinois%08%03KEY%08%07jlee700%08%
> 11ksk-1474469518919%08%07ID-CERT/%17%FD%01%00S%29k%EC%5Dy%
> 0D%1C%7DZKD%A6%E4%DE%9A%3B%81%DC%A9%F4%CBm%B0%A4%16%97%B8%
> FB%B6%8Cho%3FfH%A3%1E%F5%C9%23a%5E%E9S%92Gm%DC%0D%C2Sn%
> 9Al%0A%DC%12%B8j%C4b%BB%E93%7E%CEoe%0C%D3%D4Ip%7D%01%CA%
> 13%E9%95%BC%EAnzd%3F%F0%E7%DC%16Vb%FD%E2%AC%06%174%B8%F5%06%
> AC%CB%F7%25%2A%B9%A4%B4%B8%A2%FB%24%AB%86%CB%CE%C1%E6%9A%
> 04Ai%9A%EE-%7DYC%15%DC%9A%C9%93%83C%FE%87%B2R%9DJ%F4%E5%3F%
> AE%04f%12%DE%B3%B1%E6%D1%09T%C5%9A%D2%D42%16%27%00%2C%92%
> AC%18x%FD%96%88%A8d%D9%E8%97%26%E0%CB%D5%E00%E7%C8%0E%5E%
> 92%03%E9%A4%1E%CA%7F%06%AA%EA%CC%AE%F0v%8D%AD%9Fr%86%AF%20%
> FCJu%7B%92%7C%5E%88%28d%CEg%BB%0DQ%FF%E7%CEl%00%10%2C%
> 9FPK%EB%9C%81%ED%9A%24%93%86%98%CF%F5C0%B2%E7%29%5E%2Fm%EF%
> 8Ex%0B?ndn.InterestLifetime=10000&ndn.Nonce=1902251253
> 1485185520.991994 From: 72.36.112.82, To: 128.174.246.46, Tunnel Type:
> UDP, DATA: /localhop/nfd/rib/register/h%28%07%1D%08%03ndn%08%03edu%08%
> 08illinois%08%07jlee700i%01%00o%01Aj%01%0F/%00%00%01Y%CB%
> F4%1D%ED/%0A%BF%9CL%11L%FCW/%16E%1B%01%01%1C%40%07%3E%08%
> 03ndn%08%03edu%08%08illinois%08%03KEY%08%07jlee700%08%
> 11ksk-1474469518919%08%07ID-CERT/%17%FD%01%00S%29k%EC%5Dy%
> 0D%1C%7DZKD%A6%E4%DE%9A%3B%81%DC%A9%F4%CBm%B0%A4%16%97%B8%
> FB%B6%8Cho%3FfH%A3%1E%F5%C9%23a%5E%E9S%92Gm%DC%0D%C2Sn%
> 9Al%0A%DC%12%B8j%C4b%BB%E93%7E%CEoe%0C%D3%D4Ip%7D%01%CA%
> 13%E9%95%BC%EAnzd%3F%F0%E7%DC%16Vb%FD%E2%AC%06%174%B8%F5%06%
> AC%CB%F7%25%2A%B9%A4%B4%B8%A2%FB%24%AB%86%CB%CE%C1%E6%9A%
> 04Ai%9A%EE-%7DYC%15%DC%9A%C9%93%83C%FE%87%B2R%9DJ%F4%E5%3F%
> AE%04f%12%DE%B3%B1%E6%D1%09T%C5%9A%D2%D42%16%27%00%2C%92%
> AC%18x%FD%96%88%A8d%D9%E8%97%26%E0%CB%D5%E00%E7%C8%0E%5E%
> 92%03%E9%A4%1E%CA%7F%06%AA%EA%CC%AE%F0v%8D%AD%9Fr%86%AF%20%
> FCJu%7B%92%7C%5E%88%28d%CEg%BB%0DQ%FF%E7%CEl%00%10%2C%
> 9FPK%EB%9C%81%ED%9A%24%93%86%98%CF%F5C0%B2%E7%29%5E%2Fm%EF%8Ex%0B
> =============================================
>
>   Any other suggestions?
>
> Best wishes,
> Jongdeog Lee (JD)
>
> ------------------------------------------------
> *Ph.D. Student*
> *Department of Computer Science*
> *University of Illinois at Urbana-Champaign*
> ------------------------------
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20170123/5a70ea3c/attachment-0001.html>

From jlee700 at illinois.edu  Mon Jan 23 08:09:14 2017
From: jlee700 at illinois.edu (Lee, Jongdeog)
Date: Mon, 23 Jan 2017 16:09:14 +0000
Subject: [Nfd-dev] NDN certificate & auto prefix propagation
In-Reply-To: <CAOFH+OaHov=Je24j9zpTdZxt-FHeGmWF7r6h7bUZG8NZZC8xBg@mail.gmail.com>
References: <BCBFBC0B008B2443A454A13CD91EBEDA2DC71C9A@CITESMBX6.ad.uillinois.edu>
	<2A780D2D-EF5F-4264-AB3D-B4BE7131FAF8@email.arizona.edu>
	<BCBFBC0B008B2443A454A13CD91EBEDA2DC71DA1@CITESMBX6.ad.uillinois.edu>,
	<CAOFH+OaHov=Je24j9zpTdZxt-FHeGmWF7r6h7bUZG8NZZC8xBg@mail.gmail.com>
Message-ID: <BCBFBC0B008B2443A454A13CD91EBEDA2DC71DB6@CITESMBX6.ad.uillinois.edu>

I am using ndn-cxx 0.4.0 now due to compatibility issue.
Let me try the latest version and see what happen.

If it does not work, I will attach the log file.

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: Monday, January 23, 2017 10:03 AM
To: Lee, Jongdeog
Cc: nfd-dev at lists.cs.ucla.edu
Subject: Re: [Nfd-dev] NDN certificate & auto prefix propagation

HI Jongdeog

Can you attach tcpdump logs (.pcap) instead of ndndump text output?
ndndump cannot show Data payload so it's useless to see what's the error.

Yours, Junxiao

On Mon, Jan 23, 2017 at 8:36 AM, Lee, Jongdeog <jlee700 at illinois.edu<mailto:jlee700 at illinois.edu>> wrote:
Hi Junxiao,

  Thanks. I forgot to do 'nfdc register /localhop/nfd udp4://ndnx.cs.illinois.edu<http://ndnx.cs.illinois.edu>'.
  Unfortunately, even with that, it is not working (cannot find the prefix in the router status page)

  Here is the ndndump result at the illinois ndn node after executing ndnpingserver.

=============================================
jdlee at NDNx-server:~$ sudo ndndump | grep jlee
1485185520.982023 From: 128.174.246.46, To: 72.36.112.82, Tunnel Type: UDP, INTEREST: /localhop/nfd/rib/register/h%28%07%1D%08%03ndn%08%03edu%08%08illinois%08%07jlee700i%01%00o%01Aj%01%0F/%00%00%01Y%CB%F4%1D%ED/%0A%BF%9CL%11L%FCW/%16E%1B%01%01%1C%40%07%3E%08%03ndn%08%03edu%08%08illinois%08%03KEY%08%07jlee700%08%11ksk-1474469518919%08%07ID-CERT/%17%FD%01%00S%29k%EC%5Dy%0D%1C%7DZKD%A6%E4%DE%9A%3B%81%DC%A9%F4%CBm%B0%A4%16%97%B8%FB%B6%8Cho%3FfH%A3%1E%F5%C9%23a%5E%E9S%92Gm%DC%0D%C2Sn%9Al%0A%DC%12%B8j%C4b%BB%E93%7E%CEoe%0C%D3%D4Ip%7D%01%CA%13%E9%95%BC%EAnzd%3F%F0%E7%DC%16Vb%FD%E2%AC%06%174%B8%F5%06%AC%CB%F7%25%2A%B9%A4%B4%B8%A2%FB%24%AB%86%CB%CE%C1%E6%9A%04Ai%9A%EE-%7DYC%15%DC%9A%C9%93%83C%FE%87%B2R%9DJ%F4%E5%3F%AE%04f%12%DE%B3%B1%E6%D1%09T%C5%9A%D2%D42%16%27%00%2C%92%AC%18x%FD%96%88%A8d%D9%E8%97%26%E0%CB%D5%E00%E7%C8%0E%5E%92%03%E9%A4%1E%CA%7F%06%AA%EA%CC%AE%F0v%8D%AD%9Fr%86%AF%20%FCJu%7B%92%7C%5E%88%28d%CEg%BB%0DQ%FF%E7%CEl%00%10%2C%9FPK%EB%9C%81%ED%9A%24%93%86%98%CF%F5C0%B2%E7%29%5E%2Fm%EF%8Ex%0B?ndn.InterestLifetime=10000&ndn.Nonce=1902251253
1485185520.991994 From: 72.36.112.82, To: 128.174.246.46, Tunnel Type: UDP, DATA: /localhop/nfd/rib/register/h%28%07%1D%08%03ndn%08%03edu%08%08illinois%08%07jlee700i%01%00o%01Aj%01%0F/%00%00%01Y%CB%F4%1D%ED/%0A%BF%9CL%11L%FCW/%16E%1B%01%01%1C%40%07%3E%08%03ndn%08%03edu%08%08illinois%08%03KEY%08%07jlee700%08%11ksk-1474469518919%08%07ID-CERT/%17%FD%01%00S%29k%EC%5Dy%0D%1C%7DZKD%A6%E4%DE%9A%3B%81%DC%A9%F4%CBm%B0%A4%16%97%B8%FB%B6%8Cho%3FfH%A3%1E%F5%C9%23a%5E%E9S%92Gm%DC%0D%C2Sn%9Al%0A%DC%12%B8j%C4b%BB%E93%7E%CEoe%0C%D3%D4Ip%7D%01%CA%13%E9%95%BC%EAnzd%3F%F0%E7%DC%16Vb%FD%E2%AC%06%174%B8%F5%06%AC%CB%F7%25%2A%B9%A4%B4%B8%A2%FB%24%AB%86%CB%CE%C1%E6%9A%04Ai%9A%EE-%7DYC%15%DC%9A%C9%93%83C%FE%87%B2R%9DJ%F4%E5%3F%AE%04f%12%DE%B3%B1%E6%D1%09T%C5%9A%D2%D42%16%27%00%2C%92%AC%18x%FD%96%88%A8d%D9%E8%97%26%E0%CB%D5%E00%E7%C8%0E%5E%92%03%E9%A4%1E%CA%7F%06%AA%EA%CC%AE%F0v%8D%AD%9Fr%86%AF%20%FCJu%7B%92%7C%5E%88%28d%CEg%BB%0DQ%FF%E7%CEl%00%10%2C%9FPK%EB%9C%81%ED%9A%24%93%86%98%CF%F5C0%B2%E7%29%5E%2Fm%EF%8Ex%0B
=============================================

  Any other suggestions?

Best wishes,
Jongdeog Lee (JD)

------------------------------------------------
Ph.D. Student
Department of Computer Science
University of Illinois at Urbana-Champaign
________________________________

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

From jlee700 at illinois.edu  Mon Jan 23 08:32:05 2017
From: jlee700 at illinois.edu (Lee, Jongdeog)
Date: Mon, 23 Jan 2017 16:32:05 +0000
Subject: [Nfd-dev] NDN certificate & auto prefix propagation
In-Reply-To: <BCBFBC0B008B2443A454A13CD91EBEDA2DC71DB6@CITESMBX6.ad.uillinois.edu>
References: <BCBFBC0B008B2443A454A13CD91EBEDA2DC71C9A@CITESMBX6.ad.uillinois.edu>
	<2A780D2D-EF5F-4264-AB3D-B4BE7131FAF8@email.arizona.edu>
	<BCBFBC0B008B2443A454A13CD91EBEDA2DC71DA1@CITESMBX6.ad.uillinois.edu>,
	<CAOFH+OaHov=Je24j9zpTdZxt-FHeGmWF7r6h7bUZG8NZZC8xBg@mail.gmail.com>,
	<BCBFBC0B008B2443A454A13CD91EBEDA2DC71DB6@CITESMBX6.ad.uillinois.edu>
Message-ID: <BCBFBC0B008B2443A454A13CD91EBEDA2DC71DC4@CITESMBX6.ad.uillinois.edu>

Dear Junxiao,

  Hi. Please find the attached.
  The log file is the result of 'sudo tcpdump -s 0 port 6363 -i eth0 -w log.pcap' at the producer side.

  In the file, 72.36.112.82 is the illinois ndn node and 128.174.246.46 is the producer node.

Best wishes,
Jongdeog Lee (JD)

------------------------------------------------
Ph.D. Student
Department of Computer Science
University of Illinois at Urbana-Champaign
________________________________
From: Lee, Jongdeog
Sent: Monday, January 23, 2017 10:09 AM
To: Junxiao Shi
Cc: nfd-dev at lists.cs.ucla.edu
Subject: RE: [Nfd-dev] NDN certificate & auto prefix propagation

I am using ndn-cxx 0.4.0 now due to compatibility issue.
Let me try the latest version and see what happen.

If it does not work, I will attach the log file.

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: Monday, January 23, 2017 10:03 AM
To: Lee, Jongdeog
Cc: nfd-dev at lists.cs.ucla.edu
Subject: Re: [Nfd-dev] NDN certificate & auto prefix propagation

HI Jongdeog

Can you attach tcpdump logs (.pcap) instead of ndndump text output?
ndndump cannot show Data payload so it's useless to see what's the error.

Yours, Junxiao

On Mon, Jan 23, 2017 at 8:36 AM, Lee, Jongdeog <jlee700 at illinois.edu<mailto:jlee700 at illinois.edu>> wrote:
Hi Junxiao,

  Thanks. I forgot to do 'nfdc register /localhop/nfd udp4://ndnx.cs.illinois.edu<http://ndnx.cs.illinois.edu>'.
  Unfortunately, even with that, it is not working (cannot find the prefix in the router status page)

  Here is the ndndump result at the illinois ndn node after executing ndnpingserver.

=============================================
jdlee at NDNx-server:~$ sudo ndndump | grep jlee
1485185520.982023 From: 128.174.246.46, To: 72.36.112.82, Tunnel Type: UDP, INTEREST: /localhop/nfd/rib/register/h%28%07%1D%08%03ndn%08%03edu%08%08illinois%08%07jlee700i%01%00o%01Aj%01%0F/%00%00%01Y%CB%F4%1D%ED/%0A%BF%9CL%11L%FCW/%16E%1B%01%01%1C%40%07%3E%08%03ndn%08%03edu%08%08illinois%08%03KEY%08%07jlee700%08%11ksk-1474469518919%08%07ID-CERT/%17%FD%01%00S%29k%EC%5Dy%0D%1C%7DZKD%A6%E4%DE%9A%3B%81%DC%A9%F4%CBm%B0%A4%16%97%B8%FB%B6%8Cho%3FfH%A3%1E%F5%C9%23a%5E%E9S%92Gm%DC%0D%C2Sn%9Al%0A%DC%12%B8j%C4b%BB%E93%7E%CEoe%0C%D3%D4Ip%7D%01%CA%13%E9%95%BC%EAnzd%3F%F0%E7%DC%16Vb%FD%E2%AC%06%174%B8%F5%06%AC%CB%F7%25%2A%B9%A4%B4%B8%A2%FB%24%AB%86%CB%CE%C1%E6%9A%04Ai%9A%EE-%7DYC%15%DC%9A%C9%93%83C%FE%87%B2R%9DJ%F4%E5%3F%AE%04f%12%DE%B3%B1%E6%D1%09T%C5%9A%D2%D42%16%27%00%2C%92%AC%18x%FD%96%88%A8d%D9%E8%97%26%E0%CB%D5%E00%E7%C8%0E%5E%92%03%E9%A4%1E%CA%7F%06%AA%EA%CC%AE%F0v%8D%AD%9Fr%86%AF%20%FCJu%7B%92%7C%5E%88%28d%CEg%BB%0DQ%FF%E7%CEl%00%10%2C%9FPK%EB%9C%81%ED%9A%24%93%86%98%CF%F5C0%B2%E7%29%5E%2Fm%EF%8Ex%0B?ndn.InterestLifetime=10000&ndn.Nonce=1902251253
1485185520.991994 From: 72.36.112.82, To: 128.174.246.46, Tunnel Type: UDP, DATA: /localhop/nfd/rib/register/h%28%07%1D%08%03ndn%08%03edu%08%08illinois%08%07jlee700i%01%00o%01Aj%01%0F/%00%00%01Y%CB%F4%1D%ED/%0A%BF%9CL%11L%FCW/%16E%1B%01%01%1C%40%07%3E%08%03ndn%08%03edu%08%08illinois%08%03KEY%08%07jlee700%08%11ksk-1474469518919%08%07ID-CERT/%17%FD%01%00S%29k%EC%5Dy%0D%1C%7DZKD%A6%E4%DE%9A%3B%81%DC%A9%F4%CBm%B0%A4%16%97%B8%FB%B6%8Cho%3FfH%A3%1E%F5%C9%23a%5E%E9S%92Gm%DC%0D%C2Sn%9Al%0A%DC%12%B8j%C4b%BB%E93%7E%CEoe%0C%D3%D4Ip%7D%01%CA%13%E9%95%BC%EAnzd%3F%F0%E7%DC%16Vb%FD%E2%AC%06%174%B8%F5%06%AC%CB%F7%25%2A%B9%A4%B4%B8%A2%FB%24%AB%86%CB%CE%C1%E6%9A%04Ai%9A%EE-%7DYC%15%DC%9A%C9%93%83C%FE%87%B2R%9DJ%F4%E5%3F%AE%04f%12%DE%B3%B1%E6%D1%09T%C5%9A%D2%D42%16%27%00%2C%92%AC%18x%FD%96%88%A8d%D9%E8%97%26%E0%CB%D5%E00%E7%C8%0E%5E%92%03%E9%A4%1E%CA%7F%06%AA%EA%CC%AE%F0v%8D%AD%9Fr%86%AF%20%FCJu%7B%92%7C%5E%88%28d%CEg%BB%0DQ%FF%E7%CEl%00%10%2C%9FPK%EB%9C%81%ED%9A%24%93%86%98%CF%F5C0%B2%E7%29%5E%2Fm%EF%8Ex%0B
=============================================

  Any other suggestions?

Best wishes,
Jongdeog Lee (JD)

------------------------------------------------
Ph.D. Student
Department of Computer Science
University of Illinois at Urbana-Champaign
________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20170123/b41b9479/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: log.pcap
Type: application/vnd.tcpdump.pcap
Size: 3823 bytes
Desc: log.pcap
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20170123/b41b9479/attachment-0001.bin>

From jlee700 at illinois.edu  Tue Jan 24 09:17:46 2017
From: jlee700 at illinois.edu (Lee, Jongdeog)
Date: Tue, 24 Jan 2017 17:17:46 +0000
Subject: [Nfd-dev] NDN certificate & auto prefix propagation
In-Reply-To: <BCBFBC0B008B2443A454A13CD91EBEDA2DC71DC4@CITESMBX6.ad.uillinois.edu>
References: <BCBFBC0B008B2443A454A13CD91EBEDA2DC71C9A@CITESMBX6.ad.uillinois.edu>
	<2A780D2D-EF5F-4264-AB3D-B4BE7131FAF8@email.arizona.edu>
	<BCBFBC0B008B2443A454A13CD91EBEDA2DC71DA1@CITESMBX6.ad.uillinois.edu>,
	<CAOFH+OaHov=Je24j9zpTdZxt-FHeGmWF7r6h7bUZG8NZZC8xBg@mail.gmail.com>,
	<BCBFBC0B008B2443A454A13CD91EBEDA2DC71DB6@CITESMBX6.ad.uillinois.edu>,
	<BCBFBC0B008B2443A454A13CD91EBEDA2DC71DC4@CITESMBX6.ad.uillinois.edu>
Message-ID: <BCBFBC0B008B2443A454A13CD91EBEDA2DC71E66@CITESMBX6.ad.uillinois.edu>

Dear Junxiao,

  OK. I fixed it. The automatic prefix propagation's key chain contained an invalid certificate (/tmp-identity/...). Not sure what it is since I never created it. Is it fine to delete all tmp-identity, then? Anyway, after deleting it, it works fine.

  Also, what is a good command to check validity of certificates? 'ndnsec list' does not provide much information.

Best wishes,
Jongdeog Lee (JD)

------------------------------------------------
Ph.D. Student
Department of Computer Science
University of Illinois at Urbana-Champaign
________________________________
From: Lee, Jongdeog
Sent: Monday, January 23, 2017 10:32 AM
To: Junxiao Shi
Cc: nfd-dev at lists.cs.ucla.edu
Subject: RE: [Nfd-dev] NDN certificate & auto prefix propagation

Dear Junxiao,

  Hi. Please find the attached.
  The log file is the result of 'sudo tcpdump -s 0 port 6363 -i eth0 -w log.pcap' at the producer side.

  In the file, 72.36.112.82 is the illinois ndn node and 128.174.246.46 is the producer node.

Best wishes,
Jongdeog Lee (JD)

------------------------------------------------
Ph.D. Student
Department of Computer Science
University of Illinois at Urbana-Champaign
________________________________
From: Lee, Jongdeog
Sent: Monday, January 23, 2017 10:09 AM
To: Junxiao Shi
Cc: nfd-dev at lists.cs.ucla.edu
Subject: RE: [Nfd-dev] NDN certificate & auto prefix propagation

I am using ndn-cxx 0.4.0 now due to compatibility issue.
Let me try the latest version and see what happen.

If it does not work, I will attach the log file.

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: Monday, January 23, 2017 10:03 AM
To: Lee, Jongdeog
Cc: nfd-dev at lists.cs.ucla.edu
Subject: Re: [Nfd-dev] NDN certificate & auto prefix propagation

HI Jongdeog

Can you attach tcpdump logs (.pcap) instead of ndndump text output?
ndndump cannot show Data payload so it's useless to see what's the error.

Yours, Junxiao

On Mon, Jan 23, 2017 at 8:36 AM, Lee, Jongdeog <jlee700 at illinois.edu<mailto:jlee700 at illinois.edu>> wrote:
Hi Junxiao,

  Thanks. I forgot to do 'nfdc register /localhop/nfd udp4://ndnx.cs.illinois.edu<http://ndnx.cs.illinois.edu>'.
  Unfortunately, even with that, it is not working (cannot find the prefix in the router status page)

  Here is the ndndump result at the illinois ndn node after executing ndnpingserver.

=============================================
jdlee at NDNx-server:~$ sudo ndndump | grep jlee
1485185520.982023 From: 128.174.246.46, To: 72.36.112.82, Tunnel Type: UDP, INTEREST: /localhop/nfd/rib/register/h%28%07%1D%08%03ndn%08%03edu%08%08illinois%08%07jlee700i%01%00o%01Aj%01%0F/%00%00%01Y%CB%F4%1D%ED/%0A%BF%9CL%11L%FCW/%16E%1B%01%01%1C%40%07%3E%08%03ndn%08%03edu%08%08illinois%08%03KEY%08%07jlee700%08%11ksk-1474469518919%08%07ID-CERT/%17%FD%01%00S%29k%EC%5Dy%0D%1C%7DZKD%A6%E4%DE%9A%3B%81%DC%A9%F4%CBm%B0%A4%16%97%B8%FB%B6%8Cho%3FfH%A3%1E%F5%C9%23a%5E%E9S%92Gm%DC%0D%C2Sn%9Al%0A%DC%12%B8j%C4b%BB%E93%7E%CEoe%0C%D3%D4Ip%7D%01%CA%13%E9%95%BC%EAnzd%3F%F0%E7%DC%16Vb%FD%E2%AC%06%174%B8%F5%06%AC%CB%F7%25%2A%B9%A4%B4%B8%A2%FB%24%AB%86%CB%CE%C1%E6%9A%04Ai%9A%EE-%7DYC%15%DC%9A%C9%93%83C%FE%87%B2R%9DJ%F4%E5%3F%AE%04f%12%DE%B3%B1%E6%D1%09T%C5%9A%D2%D42%16%27%00%2C%92%AC%18x%FD%96%88%A8d%D9%E8%97%26%E0%CB%D5%E00%E7%C8%0E%5E%92%03%E9%A4%1E%CA%7F%06%AA%EA%CC%AE%F0v%8D%AD%9Fr%86%AF%20%FCJu%7B%92%7C%5E%88%28d%CEg%BB%0DQ%FF%E7%CEl%00%10%2C%9FPK%EB%9C%81%ED%9A%24%93%86%98%CF%F5C0%B2%E7%29%5E%2Fm%EF%8Ex%0B?ndn.InterestLifetime=10000&ndn.Nonce=1902251253
1485185520.991994 From: 72.36.112.82, To: 128.174.246.46, Tunnel Type: UDP, DATA: /localhop/nfd/rib/register/h%28%07%1D%08%03ndn%08%03edu%08%08illinois%08%07jlee700i%01%00o%01Aj%01%0F/%00%00%01Y%CB%F4%1D%ED/%0A%BF%9CL%11L%FCW/%16E%1B%01%01%1C%40%07%3E%08%03ndn%08%03edu%08%08illinois%08%03KEY%08%07jlee700%08%11ksk-1474469518919%08%07ID-CERT/%17%FD%01%00S%29k%EC%5Dy%0D%1C%7DZKD%A6%E4%DE%9A%3B%81%DC%A9%F4%CBm%B0%A4%16%97%B8%FB%B6%8Cho%3FfH%A3%1E%F5%C9%23a%5E%E9S%92Gm%DC%0D%C2Sn%9Al%0A%DC%12%B8j%C4b%BB%E93%7E%CEoe%0C%D3%D4Ip%7D%01%CA%13%E9%95%BC%EAnzd%3F%F0%E7%DC%16Vb%FD%E2%AC%06%174%B8%F5%06%AC%CB%F7%25%2A%B9%A4%B4%B8%A2%FB%24%AB%86%CB%CE%C1%E6%9A%04Ai%9A%EE-%7DYC%15%DC%9A%C9%93%83C%FE%87%B2R%9DJ%F4%E5%3F%AE%04f%12%DE%B3%B1%E6%D1%09T%C5%9A%D2%D42%16%27%00%2C%92%AC%18x%FD%96%88%A8d%D9%E8%97%26%E0%CB%D5%E00%E7%C8%0E%5E%92%03%E9%A4%1E%CA%7F%06%AA%EA%CC%AE%F0v%8D%AD%9Fr%86%AF%20%FCJu%7B%92%7C%5E%88%28d%CEg%BB%0DQ%FF%E7%CEl%00%10%2C%9FPK%EB%9C%81%ED%9A%24%93%86%98%CF%F5C0%B2%E7%29%5E%2Fm%EF%8Ex%0B
=============================================

  Any other suggestions?

Best wishes,
Jongdeog Lee (JD)

------------------------------------------------
Ph.D. Student
Department of Computer Science
University of Illinois at Urbana-Champaign
________________________________

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

From nfd-call-notification at mail1.yoursunny.com  Wed Jan 25 08:00:03 2017
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Wed, 25 Jan 2017 09:00:03 -0700
Subject: [Nfd-dev] NFD call 20170125
Message-ID: <201701251600.v0PG03lE014291@lectura.cs.arizona.edu>

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

From bzhang at cs.arizona.EDU  Wed Jan 25 10:59:01 2017
From: bzhang at cs.arizona.EDU (Beichuan Zhang)
Date: Wed, 25 Jan 2017 11:59:01 -0700
Subject: [Nfd-dev] NFD call 20170125
In-Reply-To: <201701251600.v0PG03lE014291@lectura.cs.arizona.edu>
References: <201701251600.v0PG03lE014291@lectura.cs.arizona.edu>
Message-ID: <E4D75C87-B034-4334-847A-8DE14DE3A128@cs.arizona.edu>

I?d like to cancel today?s call, and resume it next Monday. Sorry for the late notice.

Beichuan

> On Jan 25, 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/20170125/6a3b6cf4/attachment.html>

From aa at CS.UCLA.EDU  Wed Jan 25 21:49:30 2017
From: aa at CS.UCLA.EDU (Alex Afanasyev)
Date: Thu, 26 Jan 2017 00:49:30 -0500
Subject: [Nfd-dev] NFD version 0.5.1 release
Message-ID: <589B21A4-7AFA-4DE1-9061-A475C15C79F7@cs.ucla.edu>

Dear all,

We are pleased to announce the release of version 0.5.1 of Named Data
Networking Forwarding Daemon (NFD).

The detailed notes for the release: 
  https://named-data.net/doc/NFD/0.5.1/RELEASE_NOTES.html

Source code, instruction how to install NFD on Ubuntu Linux (14.04,
16.04, and 16.10) and macOS (10.10, 10.11, 10.12), tutorials, HOWTOs,
a FAQ and other useful resources are available on the official NFD
website:
  https://named-data.net/doc/NFD/0.5.1/

Binary packages of Ubuntu Linux will be available soon in our main PPA
repository (https://launchpad.net/~named-data/+archive/ubuntu/ppa) and
are available in the dev-channel PPA
(https://launchpad.net/~named-data/+archive/ubuntu/ppa-dev)

**NEW** PPA binary packages now include support for arm64, armhf, and
ppc64el CPU architectures.

* * *

Other related updates:

- ndn-cxx library to version 0.5.1
  https://named-data.net/doc/ndn-cxx/0.5.1/RELEASE_NOTES.html

- NLSR to version 0.3.1
  https://named-data.net/doc/NLSR/0.3.1/RELEASE-NOTES.html

- NDN Essential Tools to version 0.4:
  https://github.com/named-data/ndn-tools

* * *

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



From ilyaslahmer93 at gmail.com  Thu Jan 26 09:44:11 2017
From: ilyaslahmer93 at gmail.com (lahmer ilyas)
Date: Thu, 26 Jan 2017 18:44:11 +0100
Subject: [Nfd-dev] How can I use Wifi Direct with nfd-android
Message-ID: <CAD6hRmn13o1JJvJskbaxn_1Fap3xYuv07BQ=OP5T89Y+g8-PnQ@mail.gmail.com>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20170126/9fa79ecb/attachment.html>

From nou.mail at gmail.com  Thu Jan 26 22:11:53 2017
From: nou.mail at gmail.com (Nour El Houda Ben Youssef)
Date: Fri, 27 Jan 2017 07:11:53 +0100
Subject: [Nfd-dev] Ndn traffic generator logging problem
Message-ID: <CAJ8opn2pJ1tQf=crD9a9sBdHi0tf_yq7LjDZD1jgLdcG44g9zQ@mail.gmail.com>

Dear community

I would like to ask about ndn traffic generator logging



I deployed 5 clients but I am only getting 2 client log files that have
sometimes mismatched lines



Am I supposed to get a log file per client? If yes what could be the problem



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

From shijunxiao at email.arizona.EDU  Fri Jan 27 12:40:42 2017
From: shijunxiao at email.arizona.EDU (Junxiao Shi)
Date: Fri, 27 Jan 2017 13:40:42 -0700
Subject: [Nfd-dev] ndn-cxx potentially breaking change: SIGNER_TYPE_PIB_*
Message-ID: <CAOFH+OYNoRSn5O7wciBTRgu4XiX=ABSSGtif4SmhPs4R5fGE0Q@mail.gmail.com>

Dear folks

I'm simplifying ndn::security::SigningInfo: SIGNER_TYPE_PIB_ID and
SIGNER_TYPE_PIB_KEY are being merged into SIGNER_TYPE_ID and
SIGNER_TYPE_KEY. Old enum members are deleted altogether, since I don't
anticipate any usage given they are only compatible with v2::KeyChain which
is not yet the default. Nevertheless, this is a potential breaking change.

This change will merge no earlier than Jan 29.
You can compile your projects with ndn-cxx Change
https://gerrit.named-data.net/3624 and verify it works.

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

From lixia at CS.UCLA.EDU  Sun Jan 29 10:06:42 2017
From: lixia at CS.UCLA.EDU (Lixia Zhang)
Date: Sun, 29 Jan 2017 10:06:42 -0800
Subject: [Nfd-dev] How can I use Wifi Direct with nfd-android
In-Reply-To: <CAD6hRmn13o1JJvJskbaxn_1Fap3xYuv07BQ=OP5T89Y+g8-PnQ@mail.gmail.com>
References: <CAD6hRmn13o1JJvJskbaxn_1Fap3xYuv07BQ=OP5T89Y+g8-PnQ@mail.gmail.com>
Message-ID: <645A91EB-9177-433B-A1BD-8A1F8BF7E1C6@cs.ucla.edu>


> On Jan 26, 2017, at 9:44 AM, lahmer ilyas <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)

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

From nfd-call-notification at mail1.yoursunny.com  Mon Jan 30 08:00:03 2017
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Mon, 30 Jan 2017 09:00:03 -0700
Subject: [Nfd-dev] NFD call 20170130
Message-ID: <201701301600.v0UG03cY026059@lectura.cs.arizona.edu>

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

From jlee700 at illinois.edu  Tue Jan 31 07:47:18 2017
From: jlee700 at illinois.edu (Lee, Jongdeog)
Date: Tue, 31 Jan 2017 15:47:18 +0000
Subject: [Nfd-dev] Expiration time of the RIB entry at the NDN nodes
Message-ID: <BCBFBC0B008B2443A454A13CD91EBEDA2DC7229B@CITESMBX6.ad.uillinois.edu>

Dear nfd team,

  Hope all of you are doing fine.
  I have a question about expiration time of the RIB entry at the NDN nodes.

  Suppose that my producer successfully registered one prefix at the Illinois node (through auto prefix propagation). And I keep running ndnpingserver on the producer side. Empirically, it seems the prefix is expired after a day. How can I control the expiration time? If I want to register it longer, should I periodically register the prefix?

  Sorry if this question is duplicate.

Best wishes,
Jongdeog Lee (JD)

------------------------------------------------
Ph.D. Student
Department of Computer Science
University of Illinois at Urbana-Champaign
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20170131/b77ddc35/attachment.html>

From shijunxiao at email.arizona.EDU  Tue Jan 31 09:12:24 2017
From: shijunxiao at email.arizona.EDU (Junxiao Shi)
Date: Tue, 31 Jan 2017 10:12:24 -0700
Subject: [Nfd-dev] Expiration time of the RIB entry at the NDN nodes
In-Reply-To: <BCBFBC0B008B2443A454A13CD91EBEDA2DC7229B@CITESMBX6.ad.uillinois.edu>
References: <BCBFBC0B008B2443A454A13CD91EBEDA2DC7229B@CITESMBX6.ad.uillinois.edu>
Message-ID: <CAOFH+OZeRYsY-VO+u+p9Gi-nD87f6mqx-xcZbRV7oStOEO2+SA@mail.gmail.com>

Hi Jongdeog

Which node did the prefix disappear from?

On *producer end host*:
ndnpingserver is supposed to set the expiration time to "never", which
means it should not disappear until ndnpingserver disconnects from local
NFD.

On *Illinois router*:
Auto prefix propagation is supposed to refresh the registration
periodically. The interval is controlled by rib.auto_prefix_propagate.
refresh_interval
<https://github.com/named-data/NFD/blob/c31080d47048eb2598f0f491655d1e6f26d0fa05/nfd.conf.sample.in#L359>
config key.
To diagnose problems in this area, on the end host, set
AutoPrefixPropagator=TRACE loglevel, and you can see whether there is any
failed registrations.


Is your pingserver constantly receiving Interests, or is it mostly idle?
A mostly idle producer would rely on the registration packets to keep the
face alive at router side. A busy producer sends Data to keep the face
alive.


>From Illinois router side, after the prefix has disappeared, do you still
see a face going to the producer end host? Is the FaceId same as the FaceId
when you first start the producer end host?
If the face has disappeared or FaceId has changed, this indicates there has
been no traffic (registration packets or Data) from the producer end host
for longer than face_system.udp.idle_timeout
<https://github.com/named-data/NFD/blob/c31080d47048eb2598f0f491655d1e6f26d0fa05/nfd.conf.sample.in#L116>.
Once the new face (with a new FaceId) is established by a new registration
packet, that registration may be failing (and you'll see why by setting
AutoPrefixPropagator=TRACE loglevel at producer end host) so you don't see
the prefix.


Yours, Junxiao

On Tue, Jan 31, 2017 at 8:47 AM, Lee, Jongdeog <jlee700 at illinois.edu> wrote:

> Dear nfd team,
>
>   Hope all of you are doing fine.
>   I have a question about expiration time of the RIB entry at the NDN
> nodes.
>
>   Suppose that my producer successfully registered one prefix at the
> Illinois node (through auto prefix propagation). And I keep running
> ndnpingserver on the producer side. Empirically, it seems the prefix is
> expired after a day. How can I control the expiration time? If I want to
> register it longer, should I periodically register the prefix?
>
>   Sorry if this question is duplicate.
>
> Best wishes,
> Jongdeog Lee (JD)
>
> ------------------------------------------------
> *Ph.D. Student*
> *Department of Computer Science*
> *University of Illinois at Urbana-Champaign*
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20170131/88fb9f06/attachment-0001.html>

From shijunxiao at email.arizona.EDU  Tue Jan 31 09:45:39 2017
From: shijunxiao at email.arizona.EDU (Junxiao Shi)
Date: Tue, 31 Jan 2017 10:45:39 -0700
Subject: [Nfd-dev] nfdc implicit face creation problems
Message-ID: <CAOFH+OZ=BCG6mPqHhP9dYHW3EH0VJ2ubTZRr+s=ekoohmK+Jsw@mail.gmail.com>

Dear folks

Back in Apr 2014 <https://redmine.named-data.net/issues/1515>, we
introduced *implicit face creation* to nfdc. This feature allows an
operator to type a command:
nfdc register / udp://hobo.cs.arizona.edu
to perform two actions: (1) create a face to the specified router if it
does not exist (2) register a route toward the specified face.

However, there has been some problems in this feature:

1.
Only unicast UDP and TCP faces can be used in the FaceUri. Multicast UDP
faces and Ethernet faces cannot be written as FaceUri, but must be
specified as FaceId. This has led to user confusions. To name a few:
http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2016-June/001839.html
https://redmine.named-data.net/issues/3276
http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2015-April/001013.html

2.
nfdc register can implicitly create a face, but nfdc unregister cannot.

3.
When creating a face, it's necessary to specify its persistency. This isn't
currently possible with implicit face creation, although there is a feature
request:
https://redmine.named-data.net/issues/3229

4.
If the operator mistypes a FaceUri in nfdc register command, there would be
no warning.
https://redmine.named-data.net/issues/1515#note-10 argues against
implicitly creating a face in nfdc unregister command because of that, but
the same argument applies to nfdc register as well.


I propose dropping implicit face creation feature during nfdc refactoring:
(1) nfdc face create is the only subcommand that can create a face.
(2) nfdc route add and nfdc route remove (replacements of nfdc
register and nfdc
unregister) do not implicitly create faces. They can accept either FaceId
or FaceUri. When specifying FaceUri, we query the existing faces whose
RemoteUri matches the specified FaceUri. If one exact match is found, that
face is used. If no face with that RemoteUri is found, an error message is
printed. If two or more matches are found, an error message is printed with
the list of matched faces, and the operator can re-run the command with one
of the FaceIds from that list.

This is consistent with iproute2 programs, where you must explicitly create
an interface before using it in IP routing tables.


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

From davide.pesavento at lip6.fr  Tue Jan 31 09:53:23 2017
From: davide.pesavento at lip6.fr (Davide Pesavento)
Date: Tue, 31 Jan 2017 17:53:23 +0000
Subject: [Nfd-dev] nfdc implicit face creation problems
In-Reply-To: <CAOFH+OZ=BCG6mPqHhP9dYHW3EH0VJ2ubTZRr+s=ekoohmK+Jsw@mail.gmail.com>
References: <CAOFH+OZ=BCG6mPqHhP9dYHW3EH0VJ2ubTZRr+s=ekoohmK+Jsw@mail.gmail.com>
Message-ID: <CADfzvvY3RzMiv=AaywCpSdEp3f6qwBP06Lfh=x89cDsj_ng4=w@mail.gmail.com>

On Tue, Jan 31, 2017, 12:46 PM Junxiao Shi <shijunxiao at email.arizona.edu>
wrote:

>
> I propose dropping implicit face creation feature during nfdc refactoring:
> (1) nfdc face create is the only subcommand that can create a face.
> (2) nfdc route add and nfdc route remove (replacements of nfdc register
> and nfdc unregister) do not implicitly create faces. They can accept
> either FaceId or FaceUri. When specifying FaceUri, we query the existing
> faces whose RemoteUri matches the specified FaceUri. If one exact match is
> found, that face is used. If no face with that RemoteUri is found, an error
> message is printed. If two or more matches are found, an error message is
> printed with the list of matched faces, and the operator can re-run the
> command with one of the FaceIds from that list.
>
> This is consistent with iproute2 programs, where you must explicitly
> create an interface before using it in IP routing tables.
>

I support this proposal.

Thanks,
Davide
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20170131/6306f2f6/attachment.html>

From aa at CS.UCLA.EDU  Tue Jan 31 09:59:29 2017
From: aa at CS.UCLA.EDU (Alex Afanasyev)
Date: Tue, 31 Jan 2017 09:59:29 -0800
Subject: [Nfd-dev] nfdc implicit face creation problems
In-Reply-To: <CADfzvvY3RzMiv=AaywCpSdEp3f6qwBP06Lfh=x89cDsj_ng4=w@mail.gmail.com>
References: <CAOFH+OZ=BCG6mPqHhP9dYHW3EH0VJ2ubTZRr+s=ekoohmK+Jsw@mail.gmail.com>
	<CADfzvvY3RzMiv=AaywCpSdEp3f6qwBP06Lfh=x89cDsj_ng4=w@mail.gmail.com>
Message-ID: <1480FEC6-2F97-4C2F-958B-4646578A3BE7@cs.ucla.edu>


> On Jan 31, 2017, at 9:53 AM, Davide Pesavento <davide.pesavento at lip6.fr> wrote:
> 
> On Tue, Jan 31, 2017, 12:46 PM Junxiao Shi <shijunxiao at email.arizona.edu <mailto:shijunxiao at email.arizona.edu>> wrote:
> 
> I propose dropping implicit face creation feature during nfdc refactoring:
> (1) nfdc face create is the only subcommand that can create a face.
> (2) nfdc route add and nfdc route remove (replacements of nfdc register and nfdc unregister) do not implicitly create faces. They can accept either FaceId or FaceUri. When specifying FaceUri, we query the existing faces whose RemoteUri matches the specified FaceUri. If one exact match is found, that face is used. If no face with that RemoteUri is found, an error message is printed. If two or more matches are found, an error message is printed with the list of matched faces, and the operator can re-run the command with one of the FaceIds from that list.
> 
> This is consistent with iproute2 programs, where you must explicitly create an interface before using it in IP routing tables.
> 
> I support this proposal.

I do not support this proposal.  This creates inter-commmand dependency for basic operations as registering prefix to a new face.  We should not create more obstacles for users for the sake of having consistent interface with IP tools.

---
Alex

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

From jlee700 at illinois.edu  Tue Jan 31 10:06:30 2017
From: jlee700 at illinois.edu (Lee, Jongdeog)
Date: Tue, 31 Jan 2017 18:06:30 +0000
Subject: [Nfd-dev] Expiration time of the RIB entry at the NDN nodes
In-Reply-To: <CAOFH+OZeRYsY-VO+u+p9Gi-nD87f6mqx-xcZbRV7oStOEO2+SA@mail.gmail.com>
References: <BCBFBC0B008B2443A454A13CD91EBEDA2DC7229B@CITESMBX6.ad.uillinois.edu>,
	<CAOFH+OZeRYsY-VO+u+p9Gi-nD87f6mqx-xcZbRV7oStOEO2+SA@mail.gmail.com>
Message-ID: <BCBFBC0B008B2443A454A13CD91EBEDA2DC722CF@CITESMBX6.ad.uillinois.edu>

Hi Junxiao,

  Thanks for your reply. Regarding your answers and questions,

1.Which node did the prefix disappear from?
-> I am talking about the Illinois router

2. Is your pingserver constantly receiving Interests, or is it mostly idle?
-> It is mostly idle, especially between night and morning. And I guess the prefix disappeared during this period.

3. If the face has disappeared or FaceId has changed, this indicates there has been no traffic (registration packets or Data) from the producer end host for longer than face_system.udp.idle_timeout<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_named-2Ddata_NFD_blob_c31080d47048eb2598f0f491655d1e6f26d0fa05_nfd.conf.sample.in-23L116&d=DwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Z7ZyWHGeVXO4-LRL2FeI1ZE8d269MMOL_mjEf1LVJpE&m=QsMzIxn98Vt7BO3MepBiqT6g2quOqTeIw23Q-0lCcLk&s=mNxokWfPAvrTHE3OnaoZz1lMK5JfgL9nbs6ufPSdP44&e=>.
-> Yes. I suspect this case. Let me check auto propagation log as your advice.

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

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: Tuesday, January 31, 2017 11:12 AM
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

Which node did the prefix disappear from?

On producer end host:
ndnpingserver is supposed to set the expiration time to "never", which means it should not disappear until ndnpingserver disconnects from local NFD.

On Illinois router:
Auto prefix propagation is supposed to refresh the registration periodically. The interval is controlled by rib.auto_prefix_propagate.refresh_interval<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_named-2Ddata_NFD_blob_c31080d47048eb2598f0f491655d1e6f26d0fa05_nfd.conf.sample.in-23L359&d=DwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Z7ZyWHGeVXO4-LRL2FeI1ZE8d269MMOL_mjEf1LVJpE&m=QsMzIxn98Vt7BO3MepBiqT6g2quOqTeIw23Q-0lCcLk&s=k6KwRSVHyFyoa6u-Zczag2Mz9w1lNFFDxxe7Ji3aSyg&e=> config key.
To diagnose problems in this area, on the end host, set AutoPrefixPropagator=TRACE loglevel, and you can see whether there is any failed registrations.


Is your pingserver constantly receiving Interests, or is it mostly idle?
A mostly idle producer would rely on the registration packets to keep the face alive at router side. A busy producer sends Data to keep the face alive.


>From Illinois router side, after the prefix has disappeared, do you still see a face going to the producer end host? Is the FaceId same as the FaceId when you first start the producer end host?
If the face has disappeared or FaceId has changed, this indicates there has been no traffic (registration packets or Data) from the producer end host for longer than face_system.udp.idle_timeout<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_named-2Ddata_NFD_blob_c31080d47048eb2598f0f491655d1e6f26d0fa05_nfd.conf.sample.in-23L116&d=DwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Z7ZyWHGeVXO4-LRL2FeI1ZE8d269MMOL_mjEf1LVJpE&m=QsMzIxn98Vt7BO3MepBiqT6g2quOqTeIw23Q-0lCcLk&s=mNxokWfPAvrTHE3OnaoZz1lMK5JfgL9nbs6ufPSdP44&e=>. Once the new face (with a new FaceId) is established by a new registration packet, that registration may be failing (and you'll see why by setting AutoPrefixPropagator=TRACE loglevel at producer end host) so you don't see the prefix.


Yours, Junxiao

On Tue, Jan 31, 2017 at 8:47 AM, Lee, Jongdeog <jlee700 at illinois.edu<mailto:jlee700 at illinois.edu>> wrote:
Dear nfd team,

  Hope all of you are doing fine.
  I have a question about expiration time of the RIB entry at the NDN nodes.

  Suppose that my producer successfully registered one prefix at the Illinois node (through auto prefix propagation). And I keep running ndnpingserver on the producer side. Empirically, it seems the prefix is expired after a day. How can I control the expiration time? If I want to register it longer, should I periodically register the prefix?

  Sorry if this question is duplicate.

Best wishes,
Jongdeog Lee (JD)

------------------------------------------------
Ph.D. Student
Department of Computer Science
University of Illinois at Urbana-Champaign

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

From davide.pesavento at lip6.fr  Tue Jan 31 10:15:02 2017
From: davide.pesavento at lip6.fr (Davide Pesavento)
Date: Tue, 31 Jan 2017 13:15:02 -0500
Subject: [Nfd-dev] nfdc implicit face creation problems
In-Reply-To: <1480FEC6-2F97-4C2F-958B-4646578A3BE7@cs.ucla.edu>
References: <CAOFH+OZ=BCG6mPqHhP9dYHW3EH0VJ2ubTZRr+s=ekoohmK+Jsw@mail.gmail.com>
	<CADfzvvY3RzMiv=AaywCpSdEp3f6qwBP06Lfh=x89cDsj_ng4=w@mail.gmail.com>
	<1480FEC6-2F97-4C2F-958B-4646578A3BE7@cs.ucla.edu>
Message-ID: <CADfzvvZRBThf34CzgmgmDempEFmp5FV9Sk+zjp1jx8kAn3AQcQ@mail.gmail.com>

On Tue, Jan 31, 2017 at 12:59 PM, Alex Afanasyev <aa at cs.ucla.edu> wrote:
>
> On Jan 31, 2017, at 9:53 AM, Davide Pesavento <davide.pesavento at lip6.fr>
> wrote:
>
> On Tue, Jan 31, 2017, 12:46 PM Junxiao Shi <shijunxiao at email.arizona.edu>
> wrote:
>>
>>
>> I propose dropping implicit face creation feature during nfdc refactoring:
>> (1) nfdc face create is the only subcommand that can create a face.
>> (2) nfdc route add and nfdc route remove (replacements of nfdc register
>> and nfdc unregister) do not implicitly create faces. They can accept either
>> FaceId or FaceUri. When specifying FaceUri, we query the existing faces
>> whose RemoteUri matches the specified FaceUri. If one exact match is found,
>> that face is used. If no face with that RemoteUri is found, an error message
>> is printed. If two or more matches are found, an error message is printed
>> with the list of matched faces, and the operator can re-run the command with
>> one of the FaceIds from that list.
>>
>> This is consistent with iproute2 programs, where you must explicitly
>> create an interface before using it in IP routing tables.
>
>
> I support this proposal.
>
>
> I do not support this proposal.  This creates inter-commmand dependency for
> basic operations as registering prefix to a new face.  We should not create
> more obstacles for users for the sake of having consistent interface with IP
> tools.
>

Junxiao listed 4 problems with the current approach. Consistency with
iproute2 is not one of them. It would be an additional bonus (assuming
we consider interface == face, which is arguable), but it's definitely
not the main reason behind this proposal.

Can you elaborate on the "inter-command dependency"? I'm not sure what
you mean and how it is a problem.

Thanks,
Davide

From shijunxiao at email.arizona.EDU  Tue Jan 31 10:18:48 2017
From: shijunxiao at email.arizona.EDU (Junxiao Shi)
Date: Tue, 31 Jan 2017 11:18:48 -0700
Subject: [Nfd-dev] nfdc implicit face creation problems
In-Reply-To: <1480FEC6-2F97-4C2F-958B-4646578A3BE7@cs.ucla.edu>
References: <CAOFH+OZ=BCG6mPqHhP9dYHW3EH0VJ2ubTZRr+s=ekoohmK+Jsw@mail.gmail.com>
	<CADfzvvY3RzMiv=AaywCpSdEp3f6qwBP06Lfh=x89cDsj_ng4=w@mail.gmail.com>
	<1480FEC6-2F97-4C2F-958B-4646578A3BE7@cs.ucla.edu>
Message-ID: <CAOFH+OaDfdw6g9C1iR2_paR=A8ZCgBBUsY8=dYrYn0Rs=4m1AA@mail.gmail.com>

Dear folks

I do not support this proposal.  This creates inter-commmand dependency for
> basic operations as registering prefix to a new face.  We should not create
> more obstacles for users for the sake of having consistent interface with
> IP tools.
>

Let's rewarm the original rationale of introducing *implicit face creation*:
what we needed is not implicit face creation, but the ability to write
FaceUri into nfdc register command in place of FaceId.
Before #1515, nfdc register command only accepts FaceId. A caller must
first invoke nfdc create, scrape its output (or nfd-status -f output), and
then invoke nfdc register. This is the "inter-command dependency".

At that time, there were no faces/query operation, so that the easiest way
to obtain FaceId from FaceUri is to execute faces/create command. It has
caused a long list of concerns in #1515
<https://redmine.named-data.net/issues/1515>.
When faces/query operation was later introduced, some of the concerns are
solved, but it's too late the change the semantics of nfdc register
subcommand.

Under the new proposal, nfdc route add command accepts FaceUri and uses
that to query an existing face. This should not be considered
"inter-command dependency", because the operator can simply run "nfdc face
create udp://hobo.cs.arizona.edu && nfdc route add / udp://
hobo.cs.arizona.edu" without scraping the output of the first subcommand.

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

From aa at CS.UCLA.EDU  Tue Jan 31 10:22:36 2017
From: aa at CS.UCLA.EDU (Alex Afanasyev)
Date: Tue, 31 Jan 2017 10:22:36 -0800
Subject: [Nfd-dev] nfdc implicit face creation problems
In-Reply-To: <CADfzvvZRBThf34CzgmgmDempEFmp5FV9Sk+zjp1jx8kAn3AQcQ@mail.gmail.com>
References: <CAOFH+OZ=BCG6mPqHhP9dYHW3EH0VJ2ubTZRr+s=ekoohmK+Jsw@mail.gmail.com>
	<CADfzvvY3RzMiv=AaywCpSdEp3f6qwBP06Lfh=x89cDsj_ng4=w@mail.gmail.com>
	<1480FEC6-2F97-4C2F-958B-4646578A3BE7@cs.ucla.edu>
	<CADfzvvZRBThf34CzgmgmDempEFmp5FV9Sk+zjp1jx8kAn3AQcQ@mail.gmail.com>
Message-ID: <CB2B52B8-C1E5-4BFE-A2E1-76A32BAECAEE@cs.ucla.edu>


> On Jan 31, 2017, at 10:15 AM, Davide Pesavento <davide.pesavento at lip6.fr> wrote:
> 
> On Tue, Jan 31, 2017 at 12:59 PM, Alex Afanasyev <aa at cs.ucla.edu> wrote:
>> 
>> On Jan 31, 2017, at 9:53 AM, Davide Pesavento <davide.pesavento at lip6.fr>
>> wrote:
>> 
>> On Tue, Jan 31, 2017, 12:46 PM Junxiao Shi <shijunxiao at email.arizona.edu>
>> wrote:
>>> 
>>> 
>>> I propose dropping implicit face creation feature during nfdc refactoring:
>>> (1) nfdc face create is the only subcommand that can create a face.
>>> (2) nfdc route add and nfdc route remove (replacements of nfdc register
>>> and nfdc unregister) do not implicitly create faces. They can accept either
>>> FaceId or FaceUri. When specifying FaceUri, we query the existing faces
>>> whose RemoteUri matches the specified FaceUri. If one exact match is found,
>>> that face is used. If no face with that RemoteUri is found, an error message
>>> is printed. If two or more matches are found, an error message is printed
>>> with the list of matched faces, and the operator can re-run the command with
>>> one of the FaceIds from that list.
>>> 
>>> This is consistent with iproute2 programs, where you must explicitly
>>> create an interface before using it in IP routing tables.
>> 
>> 
>> I support this proposal.
>> 
>> 
>> I do not support this proposal.  This creates inter-commmand dependency for
>> basic operations as registering prefix to a new face.  We should not create
>> more obstacles for users for the sake of having consistent interface with IP
>> tools.
>> 
> 
> Junxiao listed 4 problems with the current approach. Consistency with
> iproute2 is not one of them. It would be an additional bonus (assuming
> we consider interface == face, which is arguable), but it's definitely
> not the main reason behind this proposal.
> 
> Can you elaborate on the "inter-command dependency"? I'm not sure what
> you mean and how it is a problem.

How would you register a route to a new face?  For what I understand the proposal is:

- nfdc face create udp:/bla
then look what the random face id is returned, remember it

- nfdc register the-remembered-face-id

I read the list of issues, but do not see them as problems.  Yes, there is no guarantee it going to work.  The helper method that accept faceUri is helper methods.  Bad analogy, bug with git you're probably using many helpers, instead of calling individual low-level commands (receive-pack, upload-pack, etc.).

---
Alex

From shijunxiao at email.arizona.EDU  Tue Jan 31 10:26:22 2017
From: shijunxiao at email.arizona.EDU (Junxiao Shi)
Date: Tue, 31 Jan 2017 11:26:22 -0700
Subject: [Nfd-dev] nfdc implicit face creation problems
In-Reply-To: <CB2B52B8-C1E5-4BFE-A2E1-76A32BAECAEE@cs.ucla.edu>
References: <CAOFH+OZ=BCG6mPqHhP9dYHW3EH0VJ2ubTZRr+s=ekoohmK+Jsw@mail.gmail.com>
	<CADfzvvY3RzMiv=AaywCpSdEp3f6qwBP06Lfh=x89cDsj_ng4=w@mail.gmail.com>
	<1480FEC6-2F97-4C2F-958B-4646578A3BE7@cs.ucla.edu>
	<CADfzvvZRBThf34CzgmgmDempEFmp5FV9Sk+zjp1jx8kAn3AQcQ@mail.gmail.com>
	<CB2B52B8-C1E5-4BFE-A2E1-76A32BAECAEE@cs.ucla.edu>
Message-ID: <CAOFH+ObvdDYOf_9dA7SK5uw8A_gPN8pdAzWoU6C7piJB5Bw4=Q@mail.gmail.com>

Hi Alex

How would you register a route to a new face?  For what I understand the
> proposal is:
>
> - nfdc face create udp:/bla
> then look what the random face id is returned, remember it
>
> - nfdc register the-remembered-face-id
>

Of course not! This is the main problem #1515 is trying to solve. It became
implicit face creation due to the lack of faces/query operation at the time.

You can run:
nfdc face create udp://hobo.cs.arizona.edu && nfdc route add / udp://
hobo.cs.arizona.edu

There is no need to remember FaceId.

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

From aa at CS.UCLA.EDU  Tue Jan 31 10:27:13 2017
From: aa at CS.UCLA.EDU (Alex Afanasyev)
Date: Tue, 31 Jan 2017 10:27:13 -0800
Subject: [Nfd-dev] nfdc implicit face creation problems
In-Reply-To: <CAOFH+OaDfdw6g9C1iR2_paR=A8ZCgBBUsY8=dYrYn0Rs=4m1AA@mail.gmail.com>
References: <CAOFH+OZ=BCG6mPqHhP9dYHW3EH0VJ2ubTZRr+s=ekoohmK+Jsw@mail.gmail.com>
	<CADfzvvY3RzMiv=AaywCpSdEp3f6qwBP06Lfh=x89cDsj_ng4=w@mail.gmail.com>
	<1480FEC6-2F97-4C2F-958B-4646578A3BE7@cs.ucla.edu>
	<CAOFH+OaDfdw6g9C1iR2_paR=A8ZCgBBUsY8=dYrYn0Rs=4m1AA@mail.gmail.com>
Message-ID: <FD0DB3E1-8799-4354-9617-DFB95408EAA5@cs.ucla.edu>


> On Jan 31, 2017, at 10:18 AM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:
> 
> Dear folks
> 
> I do not support this proposal.  This creates inter-commmand dependency for basic operations as registering prefix to a new face.  We should not create more obstacles for users for the sake of having consistent interface with IP tools.
>  
> Let's rewarm the original rationale of introducing implicit face creation: what we needed is not implicit face creation, but the ability to write FaceUri into nfdc register command in place of FaceId.
> Before #1515, nfdc register command only accepts FaceId. A caller must first invoke nfdc create, scrape its output (or nfd-status -f output), and then invoke nfdc register. This is the "inter-command dependency".
> 
> At that time, there were no faces/query operation, so that the easiest way to obtain FaceId from FaceUri is to execute faces/create command. It has caused a long list of concerns in #1515 <https://redmine.named-data.net/issues/1515>.
> When faces/query operation was later introduced, some of the concerns are solved, but it's too late the change the semantics of nfdc register subcommand.
> 
> Under the new proposal, nfdc route add command accepts FaceUri and uses that to query an existing face. This should not be considered "inter-command dependency", because the operator can simply run "nfdc face create udp://hobo.cs.arizona.edu <http://hobo.cs.arizona.edu/> && nfdc route add / udp://hobo.cs.arizona.edu <http://hobo.cs.arizona.edu/>" without scraping the output of the first subcommand.

I that case, I don't understand what the question/proposal is really about.  Remove faceUri handling for unregister?  unregister doesn't support faceUri (per man page) already.

--
Alex


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

From shijunxiao at email.arizona.edu  Tue Jan 31 10:31:05 2017
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Tue, 31 Jan 2017 11:31:05 -0700
Subject: [Nfd-dev] nfdc implicit face creation problems
In-Reply-To: <FD0DB3E1-8799-4354-9617-DFB95408EAA5@cs.ucla.edu>
References: <CAOFH+OZ=BCG6mPqHhP9dYHW3EH0VJ2ubTZRr+s=ekoohmK+Jsw@mail.gmail.com>
	<CADfzvvY3RzMiv=AaywCpSdEp3f6qwBP06Lfh=x89cDsj_ng4=w@mail.gmail.com>
	<1480FEC6-2F97-4C2F-958B-4646578A3BE7@cs.ucla.edu>
	<CAOFH+OaDfdw6g9C1iR2_paR=A8ZCgBBUsY8=dYrYn0Rs=4m1AA@mail.gmail.com>
	<FD0DB3E1-8799-4354-9617-DFB95408EAA5@cs.ucla.edu>
Message-ID: <CAOFH+Oa5ncJhM+nqooKpt+s5wGOCDgg+RUQ5c37S+E0Uu=FFog@mail.gmail.com>

Hi Alex

Under the new proposal, nfdc route add command accepts FaceUri and uses
> that to query an existing face. This should not be considered
> "inter-command dependency", because the operator can simply run "nfdc
> face create udp://hobo.cs.arizona.edu && nfdc route add / udp://
> hobo.cs.arizona.edu" without scraping the output of the first subcommand.
>
>
> I that case, I don't understand what the question/proposal is really
> about.  Remove faceUri handling for unregister?  unregister doesn't support
> faceUri (per man page) already.
>
> The proposal is about:

   - FaceUri is accepted in most places where FaceId is accepted, including
   but not limited to nfdc face destroy, nfdc route add, nfdc route remove.
   - In these commands, FaceUri can only *reference an existing face* (via
   faces/query operation), it *cannot implicitly create* a new face.

Also, old nfdc register command will remain unchanged until its removal.


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

From aa at CS.UCLA.EDU  Tue Jan 31 10:56:55 2017
From: aa at CS.UCLA.EDU (Alex Afanasyev)
Date: Tue, 31 Jan 2017 10:56:55 -0800
Subject: [Nfd-dev] nfdc implicit face creation problems
In-Reply-To: <CAOFH+Oa5ncJhM+nqooKpt+s5wGOCDgg+RUQ5c37S+E0Uu=FFog@mail.gmail.com>
References: <CAOFH+OZ=BCG6mPqHhP9dYHW3EH0VJ2ubTZRr+s=ekoohmK+Jsw@mail.gmail.com>
	<CADfzvvY3RzMiv=AaywCpSdEp3f6qwBP06Lfh=x89cDsj_ng4=w@mail.gmail.com>
	<1480FEC6-2F97-4C2F-958B-4646578A3BE7@cs.ucla.edu>
	<CAOFH+OaDfdw6g9C1iR2_paR=A8ZCgBBUsY8=dYrYn0Rs=4m1AA@mail.gmail.com>
	<FD0DB3E1-8799-4354-9617-DFB95408EAA5@cs.ucla.edu>
	<CAOFH+Oa5ncJhM+nqooKpt+s5wGOCDgg+RUQ5c37S+E0Uu=FFog@mail.gmail.com>
Message-ID: <956204C5-61F5-457B-930A-6920FC205C9E@cs.ucla.edu>


> On Jan 31, 2017, at 10:31 AM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:
> 
> Hi Alex 
> 
>> Under the new proposal, nfdc route add command accepts FaceUri and uses that to query an existing face. This should not be considered "inter-command dependency", because the operator can simply run "nfdc face create udp://hobo.cs.arizona.edu <http://hobo.cs.arizona.edu/> && nfdc route add / udp://hobo.cs.arizona.edu <http://hobo.cs.arizona.edu/>" without scraping the output of the first subcommand.
> 
> I that case, I don't understand what the question/proposal is really about.  Remove faceUri handling for unregister?  unregister doesn't support faceUri (per man page) already.
> 
> The proposal is about:
> FaceUri is accepted in most places where FaceId is accepted, including but not limited to nfdc face destroy, nfdc route add, nfdc route remove.
> In these commands, FaceUri can only reference an existing face (via faces/query operation), it cannot implicitly create a new face.
> Also, old nfdc register command will remain unchanged until its removal.


Ok. Sorry for my misunderstanding.  I have no objections for the above proposal and support it.

--
Alex

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