From jefft0 at remap.UCLA.EDU  Sun Feb  1 08:58:52 2015
From: jefft0 at remap.UCLA.EDU (Thompson, Jeff)
Date: Sun, 1 Feb 2015 16:58:52 +0000
Subject: [Nfd-dev] Avoid inline functions to reduce code size bloat
In-Reply-To: <CAOFH+OZSL=fSa6jXb2oOZDWQLOeMViDhFgc5i9iP6uOng_WsoQ@mail.gmail.com>
References: <CAOFH+OZSL=fSa6jXb2oOZDWQLOeMViDhFgc5i9iP6uOng_WsoQ@mail.gmail.com>
Message-ID: <D0F3995E.1F472%jefft0@remap.ucla.edu>

Bloat is especially a problem with inline virtual functions. This is because every bit of code that instantiates a class has to make a copy of the code for every inline virtual function in that class, even if it doesn't call the function. This is because the instantiated object can be passed to another piece of code which could call one of the virtual functions, so it must be defined. And since it is inline, the code must be defined at the place where the object is instantiated.

For example, see the 20-line inline virtual function HyperKeyLocatorNameChecker::check
https://github.com/named-data/ndn-cxx/blob/5ec0ee3b1e90f0b3c44f74430cd080fa583e16dc/src/security/conf/key-locator-checker.hpp#L196
Every piece of code which instantiates a HyperKeyLocatorNameChecker must include the code for HyperKeyLocatorNameChecker::check, even if it does't call it.

Of course, if the virtual functions of a class are not inline, but are defined in the class's .cpp file, then this problem is avoided. Therefore, at least inline virtual functions should not be used.

- Jeff T

From: Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>
Date: Saturday, January 31, 2015 at 22:23
To: nfd-dev <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: [Nfd-dev] Avoid inline functions to reduce code size bloat

Dear folks

Back in June, in issue 1694, I have pointed out that ndn-cxx has a tendency of over-using inline functions.
According to C++ Dos and Don'ts<http://www.chromium.org/developers/coding-style/cpp-dos-and-donts#TOC-Stop-inlining-code-in-headers> from Chromium project, using too much inline functions creates additional work for the linker, because every file that includes those headers would emit a version of an inline function in the object file (.o), and the linker has to eliminate those duplicates.
There's also evidence that inline functions can lead to binary size bloat, which is bad news of devices with small memory or storage, such as home routers and IoT gadgets. Even if ndn-cxx can fit into those devices, bloated binaries will consume precious memory space, and reduce available memory for ContentStore.

A decision was made in 20140708 conference call<http://redmine.named-data.net/issues/1694#note-6> that we should stop adding new inline functions unless they are trivial getters/setters, but fixing old code is low priority.
Of course, if a function is template, and all possible template parameters are not known in advance, it can be inline.


During the review of issue 2183, I suggested Change Owner to move inline functions into .cpp, as per the decision above.
However, this suggestion was rejected.
The reply was "whatever you saying. I'm refusing to do change here". No valid reason is given with this reply.


To finally resolve this and similar disputes, I request a review on the decision about inline function usage.
Please give your opinion about where inline functions should be used, along with necessary reasons and citations.

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

From alexander.afanasyev at ucla.edu  Sun Feb  1 14:24:15 2015
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Sun, 1 Feb 2015 14:24:15 -0800
Subject: [Nfd-dev] Package libndn-cxx was not found
In-Reply-To: <CAEakb=GqwAUUkzgq8AVnnPR32i=m2mHo8RhWEdhEhafgwsdXMg@mail.gmail.com>
References: <CAEakb=GqwAUUkzgq8AVnnPR32i=m2mHo8RhWEdhEhafgwsdXMg@mail.gmail.com>
Message-ID: <D41151B5-016B-43E5-B9BF-7663B166A72F@ucla.edu>

(Moved to nfd-dev mailing list)

Hi Bassem,

Did you install ndn-cxx library after building (with sudo ./waf install)?  If you have have used custom paths, then you should update PKG_CONFIG_PATH variable appropriately.

?
Alex

> On Feb 1, 2015, at 11:29 AM, Bassem Labib <bassem.labib at gmail.com> wrote:
> 
> Hi,
> 
> I have downloaded and install NFD and ndn-cxx packages and its prerequisites, on Ubuntu 14.04, as described in
> http://named-data.net/doc/ndn-cxx/current/INSTALL.html <http://named-data.net/doc/ndn-cxx/current/INSTALL.html>
> 
> but when I tried to Build ndn-cxx using the command [./waf configure]
>  it failed!!? as shown in the attachment.
> [Checking for 'libndn-cxx'                  : not found
> The configuration failed]
> 
> and in the log file:
> Checking for 'libndn-cxx'
> ['/usr/bin/pkg-config', '--cflags', '--libs', 'libndn-cxx']
> err: Package libndn-cxx was not found in the pkg-config search path.
> Perhaps you should add the directory containing `libndn-cxx.pc'
> to the PKG_CONFIG_PATH environment variable
> No package 'libndn-cxx' found
> not found
> from /home/basem/NFD: The configuration failed
> 
> Also I tried to check NFD status it gave me the following:
> ERROR: error while connecting to the forwarder (No such file or directory)
> 
> Please, help to solve this issue.
> 
> Best Regards,
> Bassem Labib
> <Screenshot from 2015-02-01 20:57:48.png>_______________________________________________
> Ndn-interest mailing list
> Ndn-interest at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150201/c0899b5a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150201/c0899b5a/attachment.bin>

From shijunxiao at email.arizona.edu  Sun Feb  1 14:27:37 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Sun, 1 Feb 2015 15:27:37 -0700
Subject: [Nfd-dev] HOWTO: assign a Redmine issue to yourself
Message-ID: <CAOFH+Obrufgbi4hjUaxy=GwNMpQdcbqj73ei8LfMiXTJenYX-g@mail.gmail.com>

I got a question on how to assign a Redmine issue to oneself. Here's the
procedure:

1. navigate to http://redmine.named-data.net , login to the website
2. type issue number in search box, press ENTER key
3. on issue page, tap Update button
4. in Assignee dropdown, select "<me>"
5. change other fields as necessary
6. if Description or Notes is entered or updated, tap Preview button and
confirm Markdown syntax is rendered correctly
7. tap Submit button to save the changes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150201/fe2bde58/attachment.html>

From alexander.afanasyev at ucla.edu  Sun Feb  1 14:33:04 2015
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Sun, 1 Feb 2015 14:33:04 -0800
Subject: [Nfd-dev] Avoid inline functions to reduce code size bloat
In-Reply-To: <D0F3995E.1F472%jefft0@remap.ucla.edu>
References: <CAOFH+OZSL=fSa6jXb2oOZDWQLOeMViDhFgc5i9iP6uOng_WsoQ@mail.gmail.com>
	<D0F3995E.1F472%jefft0@remap.ucla.edu>
Message-ID: <06222A62-C6F5-4BD0-8963-675BA1FB518C@ucla.edu>

Virtual methods are not normally inlined by the compiler at all.  In most cases it is impossible by the virtue of virtual dispatch (in some   cases compiler can be smart, but it is up to the compiler).  Conversation about ?code bloat? for me is moot here.

Implementing something in header file is just a choice of developer convenience in some cases, as one referenced about HyperKeyLocatorNameChecker.

?
Alex

> On Feb 1, 2015, at 8:58 AM, Thompson, Jeff <jefft0 at remap.ucla.edu> wrote:
> 
> Bloat is especially a problem with inline virtual functions. This is because every bit of code that instantiates a class has to make a copy of the code for every inline virtual function in that class, even if it doesn't call the function. This is because the instantiated object can be passed to another piece of code which could call one of the virtual functions, so it must be defined. And since it is inline, the code must be defined at the place where the object is instantiated.
> 
> For example, see the 20-line inline virtual function HyperKeyLocatorNameChecker::check
> https://github.com/named-data/ndn-cxx/blob/5ec0ee3b1e90f0b3c44f74430cd080fa583e16dc/src/security/conf/key-locator-checker.hpp#L196 <https://github.com/named-data/ndn-cxx/blob/5ec0ee3b1e90f0b3c44f74430cd080fa583e16dc/src/security/conf/key-locator-checker.hpp#L196>
> Every piece of code which instantiates a HyperKeyLocatorNameChecker must include the code for HyperKeyLocatorNameChecker::check, even if it does't call it.
> 
> Of course, if the virtual functions of a class are not inline, but are defined in the class's .cpp file, then this problem is avoided. Therefore, at least inline virtual functions should not be used.
> 
> - Jeff T
> 
> From: Junxiao Shi <shijunxiao at email.arizona.edu <mailto:shijunxiao at email.arizona.edu>>
> Date: Saturday, January 31, 2015 at 22:23
> To: nfd-dev <nfd-dev at lists.cs.ucla.edu <mailto:nfd-dev at lists.cs.ucla.edu>>
> Subject: [Nfd-dev] Avoid inline functions to reduce code size bloat
> 
> Dear folks
> 
> Back in June, in issue 1694, I have pointed out that ndn-cxx has a tendency of over-using inline functions.
> According to C++ Dos and Don'ts <http://www.chromium.org/developers/coding-style/cpp-dos-and-donts#TOC-Stop-inlining-code-in-headers> from Chromium project, using too much inline functions creates additional work for the linker, because every file that includes those headers would emit a version of an inline function in the object file (.o), and the linker has to eliminate those duplicates.
> There's also evidence that inline functions can lead to binary size bloat, which is bad news of devices with small memory or storage, such as home routers and IoT gadgets. Even if ndn-cxx can fit into those devices, bloated binaries will consume precious memory space, and reduce available memory for ContentStore.
> 
> A decision was made in 20140708 conference call <http://redmine.named-data.net/issues/1694#note-6> that we should stop adding new inline functions unless they are trivial getters/setters, but fixing old code is low priority.
> Of course, if a function is template, and all possible template parameters are not known in advance, it can be inline.
> 
> 
> During the review of issue 2183, I suggested Change Owner to move inline functions into .cpp, as per the decision above.
> However, this suggestion was rejected.
> The reply was "whatever you saying. I'm refusing to do change here". No valid reason is given with this reply.
> 
> 
> To finally resolve this and similar disputes, I request a review on the decision about inline function usage.
> Please give your opinion about where inline functions should be used, along with necessary reasons and citations.
> 
> Yours, Junxiao
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150201/9d86cd77/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150201/9d86cd77/attachment.bin>

From shijunxiao at email.arizona.edu  Sun Feb  1 15:20:37 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Sun, 1 Feb 2015 16:20:37 -0700
Subject: [Nfd-dev] [Ndn-interest] Package libndn-cxx was not found
In-Reply-To: <CAEakb=G8-Co0dQdfDZB=JaadCynscd3MRdXUpw4S7vPcKQUHuQ@mail.gmail.com>
References: <CAEakb=GqwAUUkzgq8AVnnPR32i=m2mHo8RhWEdhEhafgwsdXMg@mail.gmail.com>
	<CAOFH+OZaCkhTfEW9bUUO+7vBv3uqTya+9-FzQV2LV3P=NgcMBg@mail.gmail.com>
	<CAEakb=G8-Co0dQdfDZB=JaadCynscd3MRdXUpw4S7vPcKQUHuQ@mail.gmail.com>
Message-ID: <CAOFH+OaiaWWqwTOV9RhGh4Zw_u8m5f8ohUofA9QWLODPPpioVA@mail.gmail.com>

Hi Bassem

ndn-cxx installation is unnecessary if you are installing from PPA.

Yours, Junxiao

On Feb 1, 2015 4:18 PM, "Bassem Labib" <bassem.labib at gmail.com> wrote:
>
> Hi Junxiao,
>
> I was trying to install NFD using the NDN PPA Repository, but it seems I
did something
> wrong, so I will try to install and building from source and let you
know.
> Thanks for your fast response.
>
> Best Regards,
> Bassem Labib
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150201/ab001257/attachment.html>

From shijunxiao at email.arizona.edu  Sun Feb  1 21:32:19 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Sun, 1 Feb 2015 22:32:19 -0700
Subject: [Nfd-dev] NDN-RTC: NFD processing logs
In-Reply-To: <FF26AA9A-F092-469B-9B5E-6F3F10CF64CB@remap.ucla.edu>
References: <82C9DE44-8E98-413B-8B62-2BB3FA7F9FEE@remap.ucla.edu>
	<FF26AA9A-F092-469B-9B5E-6F3F10CF64CB@remap.ucla.edu>
Message-ID: <CAOFH+Ob_u4Up50zUq0vTD_cfphWDznCGnFYLp6vyEqW2Bk0TTQ@mail.gmail.com>

Hi Peter

There's a clock skew among three machines.
I picked one of the earliest Interests as a sample:

CONSUMER
1422581537.761808 DEBUG: [Forwarder] onOutgoingInterest face=259
interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/key/5/data/%00%00

HUB
1422581504.112268 DEBUG: [Forwarder] onIncomingInterest face=266
interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/key/5/data/%00%00
1422581504.112966 DEBUG: [Forwarder] onOutgoingInterest face=264
interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/key/5/data/%00%00

PRODUCER
1422581537.499525 DEBUG: [Forwarder] onIncomingInterest face=266
interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/key/5/data/%00%00


Assuming 2ms link delay: clock on HUB is ~33651ms behind of CONSUMER; clock
on PRODUCER is ~266ms behind of CONSUMER.


After compensating for the clock skew, the log snippet below says (in terms
of CONSUMER clock, milliseconds):

CONSUMER
55424 send Interest 1
55718 send Interest 2
55950 receive Data 1
55956 receive Data 2

HUB
55425 receive and send Interest 1
55948 receive and send Data 1
55954 receive Interest 2, send Data 2 from ContentStore

PRODUCER
55522 receive Interest 1
55570 send Data 1


Observations:

   - The link between HUB and PRODUCER is congested.
   Evidence: Interest 1 is received 97ms after it's sent. Data 1 is
   received 378ms after it's sent.
   - Interest 2 from CONSUMER to HUB is delayed.
   - HUB log reveals that face 266 (toward CONSUMER) and face 264 (toward
   PRODUCER) are both UDP and have same local IP address.
   The delay of Interest 2 from CONSUMER to HUB might be caused by the
   congestion between HUB and PRODUCER, because part of CONSUMER-HUB logical
   link shares same IP-layer link.


Yours, Junxiao

On Thu, Jan 29, 2015 at 7:56 PM, Gusev, Peter <peter at remap.ucla.edu> wrote:

>  Hi all,
>
>  I?m doing tests and explorations on the reasons, why does NdnCon
> experience rebufferings (i.e. interruptions in video stream which lead to
> algorithm restart).
> I would appreciate any help/suggestions/advices in debugging/analyzing NFD
> logs and NFD itself.
>
>  More specifically, I?d like to hear your comments on the following case.
> With the same configuration as before ([Consumer] <?> [*NFD1*] <==
> *Ethernet**_link*==> [*NFD2*] <==*Ethernet_link*==> [*NFD3*] <?>
> [Producer]) consumer experienced interruption after getting frame 640. So I
> tracked down frame?s 641 interests and data in NFD logs:
>
>  *NFD1 log: **($ cat consumer/nfd.log | grep "**/641/data/%00%00?)*
>
>  1422581555.423600 DEBUG: [Forwarder] onIncomingInterest face=265
> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
> 1422581555.423943 DEBUG: [Forwarder] onOutgoingInterest face=259
> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
> 1422581555.424205 DEBUG: [BestRouteStrategy2]
> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=
> *1282205730* from=265 newPitEntry-to=259
> *^ 294ms (retransmission, confirmed by consumer log)*
> 1422581555.718095 DEBUG: [Forwarder] onIncomingInterest face=265
> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
> 1422581555.718589 DEBUG: [Forwarder] onOutgoingInterest face=259
> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
> 1422581555.718929 DEBUG: [BestRouteStrategy2]
> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=589980969
> from=265 retransmit-retry-to=259
> *^ 232ms*
> 1422581555.950466 DEBUG: [Forwarder] onIncomingData face=259
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
> 1422581555.950763 DEBUG: [Forwarder] onIncomingData
> matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
> 1422581555.950998 DEBUG: [Strategy] beforeSatisfyPendingInterest
> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
> inFace=259
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
> 1422581555.951438 DEBUG: [Forwarder] onOutgoingData face=265
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
> *^ 5ms*
> 1422581555.956230 DEBUG: [Forwarder] *onIncomingData* face=259
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
> 1422581555.956496 DEBUG: [Forwarder] onIncomingData
> matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
> 1422581555.956724 DEBUG: [Strategy] beforeSatisfyPendingInterest
> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
> inFace=259
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
>
>  *NFD2 log: **($ cat hub/nfd.log | grep "**/641/data/%00%00?)*
>
>  1422581521.773468 DEBUG: [Forwarder] onIncomingInterest face=266
> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
> 1422581521.773947 DEBUG: [Forwarder] onOutgoingInterest face=264
> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
> 1422581521.774352 DEBUG: [BestRouteStrategy2]
> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=
> *1282205730* from=266 newPitEntry-to=264
> *^ 522ms (??? where is the retransmission interest?)*
> 1422581522.296967 DEBUG: [Forwarder] onIncomingData face=264
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
> 1422581522.297347 DEBUG: [Forwarder] onIncomingData
> matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
> 1422581522.297614 DEBUG: [Strategy] beforeSatisfyPendingInterest
> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
> inFace=264
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
> 1422581522.298123 DEBUG: [Forwarder] onOutgoingData face=266
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
> *^ 5ms (ah, here it is? how?)*
> 1422581522.303090 DEBUG: [Forwarder] onIncomingInterest face=266
> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
> 1422581522.303430 DEBUG: [Forwarder] onOutgoingData face=266
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
>
>  *NFD3 log: **($ cat producer/nfd.log | grep "**/641/data/%00%00?)*
>
>  1422581555.255647 DEBUG: [Forwarder] onIncomingInterest face=266
> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
> 1422581555.256007 DEBUG: [Forwarder] onOutgoingInterest face=269
> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
> 1422581555.256334 DEBUG: [BestRouteStrategy2]
> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=
> *1282205730* from=266 newPitEntry-to=269
> *^ 47ms (!!! interest arrival was not late, data generation was not
> delayed)*
> 1422581555.303275 DEBUG: [Forwarder] onIncomingData face=269
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
> 1422581555.303640 DEBUG: [Forwarder] onIncomingData
> matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
> 1422581555.303928 DEBUG: [Strategy] beforeSatisfyPendingInterest
> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
> inFace=269
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
> 1422581555.304458 DEBUG: [Forwarder] onOutgoingData face=266
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
>
>
>  The questions here are:
> 1. How did the retransmission interest arrived on NFD2 ~220ms later than
> was expected and actually after the first interest was already answered?
> 2. If the data was generated and answered by NFD3 in timely manner, why
> did data arrived on NFD2 after 522ms but not after ~50ms?
>
>  Some peculiar place of NFD2?s log:
>  *$ sed -n 38830,38840p hub/nfd.log *
>
>  1422581521.916149 DEBUG: [Forwarder] onIncomingData face=264
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/638/data/%00%0A/14/661/22/0
> 1422581521.916515 DEBUG: [Forwarder] onIncomingData
> matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/638/data/%00%0A
> 1422581521.916799 DEBUG: [Strategy] beforeSatisfyPendingInterest
> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/638/data/%00%0A
> inFace=264
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/638/data/%00%0A/14/661/22/0
> 1422581521.917301 DEBUG: [Forwarder] onOutgoingData face=266
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/638/data/%00%0A/14/661/22/0
> ^ 360ms
> 1422581522.277620 DEBUG: [Forwarder] onInterestUnsatisfied
> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/499/data/%00%06
> 1422581522.278080 DEBUG: [Strategy] beforeExpirePendingInterest
> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/499/data/%00%06
> 1422581522.278524 DEBUG: [Forwarder] onInterestUnsatisfied
> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/500/data/%00%06
> 1422581522.278901 DEBUG: [Strategy] beforeExpirePendingInterest
> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/500/data/%00%06
> 1422581522.279352 DEBUG: [Forwarder] onInterestUnsatisfied
> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/501/data/%00%05
> 1422581522.279742 DEBUG: [Strategy] beforeExpirePendingInterest
> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/501/data/%00%05
> 1422581522.280119 DEBUG: [Forwarder] onInterestUnsatisfied
> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/501/data/%00%06
>
>
>  I would appreciate any help.
> Looking forward for the insights of NFD developers,
>
>    Thanks,
>
>  PS. full logs are attached
>
>  --
> Peter Gusev
>  Programmer/Analyst @ REMAP, UCLA
>
> peter at remap.ucla.edu
> +1 213 5872748
> peetonn_ (skype)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150201/b7707295/attachment.html>

From bassem.labib at gmail.com  Sun Feb  1 16:05:44 2015
From: bassem.labib at gmail.com (Bassem Labib)
Date: Mon, 2 Feb 2015 02:05:44 +0200
Subject: [Nfd-dev] [Ndn-interest] Package libndn-cxx was not found
In-Reply-To: <CAOFH+OaiaWWqwTOV9RhGh4Zw_u8m5f8ohUofA9QWLODPPpioVA@mail.gmail.com>
References: <CAEakb=GqwAUUkzgq8AVnnPR32i=m2mHo8RhWEdhEhafgwsdXMg@mail.gmail.com>
	<CAOFH+OZaCkhTfEW9bUUO+7vBv3uqTya+9-FzQV2LV3P=NgcMBg@mail.gmail.com>
	<CAEakb=G8-Co0dQdfDZB=JaadCynscd3MRdXUpw4S7vPcKQUHuQ@mail.gmail.com>
	<CAOFH+OaiaWWqwTOV9RhGh4Zw_u8m5f8ohUofA9QWLODPPpioVA@mail.gmail.com>
Message-ID: <CAEakb=G2+xdGHxpyUg+rWuFXAW1cbsnoLVeHx-mmdVg8YD15+w@mail.gmail.com>

Hi Junxiao,

I tried to install from source successfully, it works fine now.
As I sent before, I was installing from PPA and it did not work with me,
maybe because of the PKG_CONFIG_PATH as Alex said.

Note: first time I download the ndn-cxx it stored under that path
[/usr/share/doc], but second time I found it under home path!!

Thanks for your support,
Bassem Labib

On Mon, Feb 2, 2015 at 1:20 AM, Junxiao Shi <shijunxiao at email.arizona.edu>
wrote:

> Hi Bassem
>
> ndn-cxx installation is unnecessary if you are installing from PPA.
>
> Yours, Junxiao
>
> On Feb 1, 2015 4:18 PM, "Bassem Labib" <bassem.labib at gmail.com> wrote:
> >
> > Hi Junxiao,
> >
> > I was trying to install NFD using the NDN PPA Repository, but it seems I
> did something
> > wrong, so I will try to install and building from source and let you
> know.
> > Thanks for your fast response.
> >
> > Best Regards,
> > Bassem Labib
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150202/91670f3f/attachment.html>

From peter at remap.UCLA.EDU  Mon Feb  2 11:24:31 2015
From: peter at remap.UCLA.EDU (Gusev, Peter)
Date: Mon, 2 Feb 2015 19:24:31 +0000
Subject: [Nfd-dev] NDN-RTC: NFD processing logs
In-Reply-To: <CAOFH+Ob_u4Up50zUq0vTD_cfphWDznCGnFYLp6vyEqW2Bk0TTQ@mail.gmail.com>
References: <82C9DE44-8E98-413B-8B62-2BB3FA7F9FEE@remap.ucla.edu>
	<FF26AA9A-F092-469B-9B5E-6F3F10CF64CB@remap.ucla.edu>
	<CAOFH+Ob_u4Up50zUq0vTD_cfphWDznCGnFYLp6vyEqW2Bk0TTQ@mail.gmail.com>
Message-ID: <2F36281B-7C01-4A7A-A12C-17A224A9ABFB@remap.ucla.edu>

Hi Junxiao,

Thanks for your  analysis!
You?re right, there?s a clock skew (even though all three machines are NTP-synchronized to the time1.ucla.edu<http://time1.ucla.edu>).


  *   HUB log reveals that face 266 (toward CONSUMER) and face 264 (toward PRODUCER) are both UDP and have same local IP address.
The delay of Interest 2 from CONSUMER to HUB might be caused by the congestion between HUB and PRODUCER, because part of CONSUMER-HUB logical link shares same IP-layer link.

I didn?t quite get this statement - do you mean that consumer and producer run on the same machine? In the scenario I run, there were three machines (consumer 128.97.152.44, hub 131.179.141.51 and producer 131.179.141.33) connected using 1Gbit switches (LAN). Do you think this could be a congestion problem still?
I?ll run new tests now eliminating one network segment by connecting consumer to the 131.179.141.xx subnet.

Thanks,

--
Peter Gusev
Programmer/Analyst @ REMAP, UCLA

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

On Feb 1, 2015, at 9:32 PM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:

Hi Peter

There's a clock skew among three machines.
I picked one of the earliest Interests as a sample:
CONSUMER
1422581537.761808 DEBUG: [Forwarder] onOutgoingInterest face=259 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/key/5/data/%00%00

HUB
1422581504.112268 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/key/5/data/%00%00
1422581504.112966 DEBUG: [Forwarder] onOutgoingInterest face=264 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/key/5/data/%00%00

PRODUCER
1422581537.499525 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/key/5/data/%00%00

Assuming 2ms link delay: clock on HUB is ~33651ms behind of CONSUMER; clock on PRODUCER is ~266ms behind of CONSUMER.


After compensating for the clock skew, the log snippet below says (in terms of CONSUMER clock, milliseconds):
CONSUMER
55424 send Interest 1
55718 send Interest 2
55950 receive Data 1
55956 receive Data 2

HUB
55425 receive and send Interest 1
55948 receive and send Data 1
55954 receive Interest 2, send Data 2 from ContentStore

PRODUCER
55522 receive Interest 1
55570 send Data 1

Observations:

  *   The link between HUB and PRODUCER is congested.
Evidence: Interest 1 is received 97ms after it's sent. Data 1 is received 378ms after it's sent.
  *   Interest 2 from CONSUMER to HUB is delayed.
  *   HUB log reveals that face 266 (toward CONSUMER) and face 264 (toward PRODUCER) are both UDP and have same local IP address.
The delay of Interest 2 from CONSUMER to HUB might be caused by the congestion between HUB and PRODUCER, because part of CONSUMER-HUB logical link shares same IP-layer link.

Yours, Junxiao

On Thu, Jan 29, 2015 at 7:56 PM, Gusev, Peter <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>> wrote:
Hi all,

I?m doing tests and explorations on the reasons, why does NdnCon experience rebufferings (i.e. interruptions in video stream which lead to algorithm restart).
I would appreciate any help/suggestions/advices in debugging/analyzing NFD logs and NFD itself.

More specifically, I?d like to hear your comments on the following case.
With the same configuration as before ([Consumer] <?> [NFD1] <==Ethernet_link==> [NFD2] <==Ethernet_link==> [NFD3] <?> [Producer]) consumer experienced interruption after getting frame 640. So I tracked down frame?s 641 interests and data in NFD logs:

NFD1 log: ($ cat consumer/nfd.log | grep "/641/data/%00%00?)

1422581555.423600 DEBUG: [Forwarder] onIncomingInterest face=265 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581555.423943 DEBUG: [Forwarder] onOutgoingInterest face=259 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581555.424205 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=1282205730 from=265 newPitEntry-to=259
^ 294ms (retransmission, confirmed by consumer log)
1422581555.718095 DEBUG: [Forwarder] onIncomingInterest face=265 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581555.718589 DEBUG: [Forwarder] onOutgoingInterest face=259 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581555.718929 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=589980969 from=265 retransmit-retry-to=259
^ 232ms
1422581555.950466 DEBUG: [Forwarder] onIncomingData face=259 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
1422581555.950763 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581555.950998 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00 inFace=259 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
1422581555.951438 DEBUG: [Forwarder] onOutgoingData face=265 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
^ 5ms
1422581555.956230 DEBUG: [Forwarder] onIncomingData face=259 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
1422581555.956496 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581555.956724 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00 inFace=259 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0

NFD2 log: ($ cat hub/nfd.log | grep "/641/data/%00%00?)

1422581521.773468 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581521.773947 DEBUG: [Forwarder] onOutgoingInterest face=264 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581521.774352 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=1282205730 from=266 newPitEntry-to=264
^ 522ms (??? where is the retransmission interest?)
1422581522.296967 DEBUG: [Forwarder] onIncomingData face=264 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
1422581522.297347 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581522.297614 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00 inFace=264 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
1422581522.298123 DEBUG: [Forwarder] onOutgoingData face=266 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
^ 5ms (ah, here it is? how?)
1422581522.303090 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581522.303430 DEBUG: [Forwarder] onOutgoingData face=266 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0

NFD3 log: ($ cat producer/nfd.log | grep "/641/data/%00%00?)

1422581555.255647 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581555.256007 DEBUG: [Forwarder] onOutgoingInterest face=269 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581555.256334 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=1282205730 from=266 newPitEntry-to=269
^ 47ms (!!! interest arrival was not late, data generation was not delayed)
1422581555.303275 DEBUG: [Forwarder] onIncomingData face=269 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
1422581555.303640 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581555.303928 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00 inFace=269 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
1422581555.304458 DEBUG: [Forwarder] onOutgoingData face=266 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0


The questions here are:
1. How did the retransmission interest arrived on NFD2 ~220ms later than was expected and actually after the first interest was already answered?
2. If the data was generated and answered by NFD3 in timely manner, why did data arrived on NFD2 after 522ms but not after ~50ms?

Some peculiar place of NFD2?s log:
$ sed -n 38830,38840p hub/nfd.log

1422581521.916149 DEBUG: [Forwarder] onIncomingData face=264 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/638/data/%00%0A/14/661/22/0
1422581521.916515 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/638/data/%00%0A
1422581521.916799 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/638/data/%00%0A inFace=264 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/638/data/%00%0A/14/661/22/0
1422581521.917301 DEBUG: [Forwarder] onOutgoingData face=266 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/638/data/%00%0A/14/661/22/0
^ 360ms
1422581522.277620 DEBUG: [Forwarder] onInterestUnsatisfied interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/499/data/%00%06
1422581522.278080 DEBUG: [Strategy] beforeExpirePendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/499/data/%00%06
1422581522.278524 DEBUG: [Forwarder] onInterestUnsatisfied interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/500/data/%00%06
1422581522.278901 DEBUG: [Strategy] beforeExpirePendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/500/data/%00%06
1422581522.279352 DEBUG: [Forwarder] onInterestUnsatisfied interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/501/data/%00%05
1422581522.279742 DEBUG: [Strategy] beforeExpirePendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/501/data/%00%05
1422581522.280119 DEBUG: [Forwarder] onInterestUnsatisfied interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/501/data/%00%06


I would appreciate any help.
Looking forward for the insights of NFD developers,

Thanks,

PS. full logs are attached

--
Peter Gusev
Programmer/Analyst @ REMAP, UCLA

peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>
+1 213 5872748<tel:%2B1%20213%205872748>
peetonn_ (skype)


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

From shijunxiao at email.arizona.edu  Mon Feb  2 11:32:15 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Mon, 2 Feb 2015 12:32:15 -0700
Subject: [Nfd-dev] NDN-RTC: NFD processing logs
In-Reply-To: <2F36281B-7C01-4A7A-A12C-17A224A9ABFB@remap.ucla.edu>
References: <82C9DE44-8E98-413B-8B62-2BB3FA7F9FEE@remap.ucla.edu>
	<FF26AA9A-F092-469B-9B5E-6F3F10CF64CB@remap.ucla.edu>
	<CAOFH+Ob_u4Up50zUq0vTD_cfphWDznCGnFYLp6vyEqW2Bk0TTQ@mail.gmail.com>
	<2F36281B-7C01-4A7A-A12C-17A224A9ABFB@remap.ucla.edu>
Message-ID: <CAOFH+OaL8Ng6YBtkOB0pYT+CHx4hXwnM3J4S1Dn3rMwauoeLZQ@mail.gmail.com>

Hi Peter

This statement means:
Both CONSUMER-HUB and HUB-PRODUCER links are using the same physical NIC of
HUB router.
Thus, a congestion on HUB-PRODUCER can cause an underlying congestion on
this physical NIC, and therefore cause a delay on CONSUMER-HUB link.

To eliminate this factor, use two physical NICs on the HUB, so that
CONSUMER-HUB and HUB-PRODUCER links won't affect each other.

Yours, Junxiao

On Mon, Feb 2, 2015 at 12:24 PM, Gusev, Peter <peter at remap.ucla.edu> wrote:

>  Hi Junxiao,
>
>  Thanks for your  analysis!
> You?re right, there?s a clock skew (even though all three machines are
> NTP-synchronized to the time1.ucla.edu).
>
>
>    - HUB log reveals that face 266 (toward CONSUMER) and face 264 (toward
>    PRODUCER) are both UDP and have same local IP address.
>    The delay of Interest 2 from CONSUMER to HUB might be caused by the
>    congestion between HUB and PRODUCER, because part of CONSUMER-HUB logical
>    link shares same IP-layer link.
>
>   I didn?t quite get this statement - do you mean that consumer and
> producer run on the same machine? In the scenario I run, there were three
> machines (consumer 128.97.152.44, hub 131.179.141.51 and
> producer 131.179.141.33) connected using 1Gbit switches (LAN). Do you think
> this could be a congestion problem still?
>  I?ll run new tests now eliminating one network segment by connecting
> consumer to the 131.179.141.xx subnet.
>
>    Thanks,
>
>  --
> Peter Gusev
>  Programmer/Analyst @ REMAP, UCLA
>
> peter at remap.ucla.edu
> +1 213 5872748
> peetonn_ (skype)
>
>  On Feb 1, 2015, at 9:32 PM, Junxiao Shi <shijunxiao at email.arizona.edu>
> wrote:
>
>  Hi Peter
>
>  There's a clock skew among three machines.
> I picked one of the earliest Interests as a sample:
>
> CONSUMER
>  1422581537.761808 DEBUG: [Forwarder] onOutgoingInterest face=259
> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/key/5/data/%00%00
>
>  HUB
>  1422581504.112268 DEBUG: [Forwarder] onIncomingInterest face=266
> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/key/5/data/%00%00
>  1422581504.112966 DEBUG: [Forwarder] onOutgoingInterest face=264
> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/key/5/data/%00%00
>
>  PRODUCER
>  1422581537.499525 DEBUG: [Forwarder] onIncomingInterest face=266
> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/key/5/data/%00%00
>
>
>  Assuming 2ms link delay: clock on HUB is ~33651ms behind of CONSUMER;
> clock on PRODUCER is ~266ms behind of CONSUMER.
>
>
>  After compensating for the clock skew, the log snippet below says (in
> terms of CONSUMER clock, milliseconds):
>
> CONSUMER
> 55424 send Interest 1
> 55718 send Interest 2
> 55950 receive Data 1
> 55956 receive Data 2
>
>  HUB
> 55425 receive and send Interest 1
> 55948 receive and send Data 1
> 55954 receive Interest 2, send Data 2 from ContentStore
>
>  PRODUCER
> 55522 receive Interest 1
> 55570 send Data 1
>
>
>  Observations:
>
>    - The link between HUB and PRODUCER is congested.
>    Evidence: Interest 1 is received 97ms after it's sent. Data 1 is
>    received 378ms after it's sent.
>    - Interest 2 from CONSUMER to HUB is delayed.
>    - HUB log reveals that face 266 (toward CONSUMER) and face 264 (toward
>    PRODUCER) are both UDP and have same local IP address.
>    The delay of Interest 2 from CONSUMER to HUB might be caused by the
>    congestion between HUB and PRODUCER, because part of CONSUMER-HUB logical
>    link shares same IP-layer link.
>
>
>  Yours, Junxiao
>
> On Thu, Jan 29, 2015 at 7:56 PM, Gusev, Peter <peter at remap.ucla.edu>
> wrote:
>
>>  Hi all,
>>
>>  I?m doing tests and explorations on the reasons, why does NdnCon
>> experience rebufferings (i.e. interruptions in video stream which lead to
>> algorithm restart).
>> I would appreciate any help/suggestions/advices in debugging/analyzing
>> NFD logs and NFD itself.
>>
>>  More specifically, I?d like to hear your comments on the following case.
>> With the same configuration as before ([Consumer] <?> [*NFD1*] <==
>> *Ethernet**_link*==> [*NFD2*] <==*Ethernet_link*==> [*NFD3*] <?>
>> [Producer]) consumer experienced interruption after getting frame 640. So I
>> tracked down frame?s 641 interests and data in NFD logs:
>>
>>  *NFD1 log: **($ cat consumer/nfd.log | grep "**/641/data/%00%00?)*
>>
>>  1422581555.423600 DEBUG: [Forwarder] onIncomingInterest face=265
>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
>> 1422581555.423943 DEBUG: [Forwarder] onOutgoingInterest face=259
>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
>> 1422581555.424205 DEBUG: [BestRouteStrategy2]
>> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=
>> *1282205730* from=265 newPitEntry-to=259
>> *^ 294ms (retransmission, confirmed by consumer log)*
>> 1422581555.718095 DEBUG: [Forwarder] onIncomingInterest face=265
>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
>> 1422581555.718589 DEBUG: [Forwarder] onOutgoingInterest face=259
>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
>> 1422581555.718929 DEBUG: [BestRouteStrategy2]
>> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=589980969
>> from=265 retransmit-retry-to=259
>> *^ 232ms*
>> 1422581555.950466 DEBUG: [Forwarder] onIncomingData face=259
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
>> 1422581555.950763 DEBUG: [Forwarder] onIncomingData
>> matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
>> 1422581555.950998 DEBUG: [Strategy] beforeSatisfyPendingInterest
>> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
>> inFace=259
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
>> 1422581555.951438 DEBUG: [Forwarder] onOutgoingData face=265
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
>> *^ 5ms*
>> 1422581555.956230 DEBUG: [Forwarder] *onIncomingData* face=259
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
>> 1422581555.956496 DEBUG: [Forwarder] onIncomingData
>> matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
>> 1422581555.956724 DEBUG: [Strategy] beforeSatisfyPendingInterest
>> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
>> inFace=259
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
>>
>>  *NFD2 log: **($ cat hub/nfd.log | grep "**/641/data/%00%00?)*
>>
>>  1422581521.773468 DEBUG: [Forwarder] onIncomingInterest face=266
>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
>> 1422581521.773947 DEBUG: [Forwarder] onOutgoingInterest face=264
>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
>> 1422581521.774352 DEBUG: [BestRouteStrategy2]
>> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=
>> *1282205730* from=266 newPitEntry-to=264
>> *^ 522ms (??? where is the retransmission interest?)*
>> 1422581522.296967 DEBUG: [Forwarder] onIncomingData face=264
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
>> 1422581522.297347 DEBUG: [Forwarder] onIncomingData
>> matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
>> 1422581522.297614 DEBUG: [Strategy] beforeSatisfyPendingInterest
>> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
>> inFace=264
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
>> 1422581522.298123 DEBUG: [Forwarder] onOutgoingData face=266
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
>> *^ 5ms (ah, here it is? how?)*
>> 1422581522.303090 DEBUG: [Forwarder] onIncomingInterest face=266
>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
>> 1422581522.303430 DEBUG: [Forwarder] onOutgoingData face=266
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
>>
>>  *NFD3 log: **($ cat producer/nfd.log | grep "**/641/data/%00%00?)*
>>
>>  1422581555.255647 DEBUG: [Forwarder] onIncomingInterest face=266
>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
>> 1422581555.256007 DEBUG: [Forwarder] onOutgoingInterest face=269
>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
>> 1422581555.256334 DEBUG: [BestRouteStrategy2]
>> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=
>> *1282205730* from=266 newPitEntry-to=269
>> *^ 47ms (!!! interest arrival was not late, data generation was not
>> delayed)*
>> 1422581555.303275 DEBUG: [Forwarder] onIncomingData face=269
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
>> 1422581555.303640 DEBUG: [Forwarder] onIncomingData
>> matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
>> 1422581555.303928 DEBUG: [Strategy] beforeSatisfyPendingInterest
>> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
>> inFace=269
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
>> 1422581555.304458 DEBUG: [Forwarder] onOutgoingData face=266
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
>>
>>
>>  The questions here are:
>> 1. How did the retransmission interest arrived on NFD2 ~220ms later than
>> was expected and actually after the first interest was already answered?
>> 2. If the data was generated and answered by NFD3 in timely manner, why
>> did data arrived on NFD2 after 522ms but not after ~50ms?
>>
>>  Some peculiar place of NFD2?s log:
>>  *$ sed -n 38830,38840p hub/nfd.log *
>>
>>  1422581521.916149 DEBUG: [Forwarder] onIncomingData face=264
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/638/data/%00%0A/14/661/22/0
>> 1422581521.916515 DEBUG: [Forwarder] onIncomingData
>> matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/638/data/%00%0A
>> 1422581521.916799 DEBUG: [Strategy] beforeSatisfyPendingInterest
>> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/638/data/%00%0A
>> inFace=264
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/638/data/%00%0A/14/661/22/0
>> 1422581521.917301 DEBUG: [Forwarder] onOutgoingData face=266
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/638/data/%00%0A/14/661/22/0
>> ^ 360ms
>> 1422581522.277620 DEBUG: [Forwarder] onInterestUnsatisfied
>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/499/data/%00%06
>> 1422581522.278080 DEBUG: [Strategy] beforeExpirePendingInterest
>> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/499/data/%00%06
>> 1422581522.278524 DEBUG: [Forwarder] onInterestUnsatisfied
>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/500/data/%00%06
>> 1422581522.278901 DEBUG: [Strategy] beforeExpirePendingInterest
>> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/500/data/%00%06
>> 1422581522.279352 DEBUG: [Forwarder] onInterestUnsatisfied
>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/501/data/%00%05
>> 1422581522.279742 DEBUG: [Strategy] beforeExpirePendingInterest
>> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/501/data/%00%05
>> 1422581522.280119 DEBUG: [Forwarder] onInterestUnsatisfied
>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/501/data/%00%06
>>
>>
>>  I would appreciate any help.
>> Looking forward for the insights of NFD developers,
>>
>>    Thanks,
>>
>>  PS. full logs are attached
>>
>>  --
>> Peter Gusev
>>  Programmer/Analyst @ REMAP, UCLA
>>
>> peter at remap.ucla.edu
>> +1 213 5872748
>> peetonn_ (skype)
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150202/0e4272bd/attachment.html>

From jburke at remap.UCLA.EDU  Mon Feb  2 19:04:25 2015
From: jburke at remap.UCLA.EDU (Burke, Jeff)
Date: Tue, 3 Feb 2015 03:04:25 +0000
Subject: [Nfd-dev] NDN-RTC: NFD processing logs
In-Reply-To: <CAOFH+OaL8Ng6YBtkOB0pYT+CHx4hXwnM3J4S1Dn3rMwauoeLZQ@mail.gmail.com>
References: <82C9DE44-8E98-413B-8B62-2BB3FA7F9FEE@remap.ucla.edu>
	<FF26AA9A-F092-469B-9B5E-6F3F10CF64CB@remap.ucla.edu>
	<CAOFH+Ob_u4Up50zUq0vTD_cfphWDznCGnFYLp6vyEqW2Bk0TTQ@mail.gmail.com>
	<2F36281B-7C01-4A7A-A12C-17A224A9ABFB@remap.ucla.edu>,
	<CAOFH+OaL8Ng6YBtkOB0pYT+CHx4hXwnM3J4S1Dn3rMwauoeLZQ@mail.gmail.com>
Message-ID: <020480B79F5DB249B89F4856EB5270EA986507A8@EM1A.ad.ucla.edu>

Junxiao,
Thanks for considering this.
These are gigabit nics doing nothing else of significance, with ndnrtc traffic in the hundreds of kilobits/sec. I don't see how local congestion in the hundreds of ms (of all packets) would result?
Jeff

-----Original Message-----
From: Junxiao Shi [shijunxiao at email.arizona.edu]
Received: Monday, 02 Feb 2015, 11:33AM
To: Gusev, Peter [peter at remap.ucla.edu]
CC: {nfd-dev at lists.cs.ucla.edu} [nfd-dev at lists.cs.ucla.edu]
Subject: Re: [Nfd-dev] NDN-RTC: NFD processing logs

Hi Peter

This statement means:
Both CONSUMER-HUB and HUB-PRODUCER links are using the same physical NIC of HUB router.
Thus, a congestion on HUB-PRODUCER can cause an underlying congestion on this physical NIC, and therefore cause a delay on CONSUMER-HUB link.

To eliminate this factor, use two physical NICs on the HUB, so that CONSUMER-HUB and HUB-PRODUCER links won't affect each other.

Yours, Junxiao

On Mon, Feb 2, 2015 at 12:24 PM, Gusev, Peter <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>> wrote:
Hi Junxiao,

Thanks for your  analysis!
You?re right, there?s a clock skew (even though all three machines are NTP-synchronized to the time1.ucla.edu<http://time1.ucla.edu>).


  *   HUB log reveals that face 266 (toward CONSUMER) and face 264 (toward PRODUCER) are both UDP and have same local IP address.
The delay of Interest 2 from CONSUMER to HUB might be caused by the congestion between HUB and PRODUCER, because part of CONSUMER-HUB logical link shares same IP-layer link.

I didn?t quite get this statement - do you mean that consumer and producer run on the same machine? In the scenario I run, there were three machines (consumer 128.97.152.44, hub 131.179.141.51 and producer 131.179.141.33) connected using 1Gbit switches (LAN). Do you think this could be a congestion problem still?
I?ll run new tests now eliminating one network segment by connecting consumer to the 131.179.141.xx subnet.

Thanks,

--
Peter Gusev
Programmer/Analyst @ REMAP, UCLA

peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>
+1 213 5872748<tel:%2B1%20213%205872748>
peetonn_ (skype)

On Feb 1, 2015, at 9:32 PM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:

Hi Peter

There's a clock skew among three machines.
I picked one of the earliest Interests as a sample:
CONSUMER
1422581537.761808 DEBUG: [Forwarder] onOutgoingInterest face=259 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/key/5/data/%00%00

HUB
1422581504.112268 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/key/5/data/%00%00
1422581504.112966 DEBUG: [Forwarder] onOutgoingInterest face=264 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/key/5/data/%00%00

PRODUCER
1422581537.499525 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/key/5/data/%00%00

Assuming 2ms link delay: clock on HUB is ~33651ms behind of CONSUMER; clock on PRODUCER is ~266ms behind of CONSUMER.


After compensating for the clock skew, the log snippet below says (in terms of CONSUMER clock, milliseconds):
CONSUMER
55424 send Interest 1
55718 send Interest 2
55950 receive Data 1
55956 receive Data 2

HUB
55425 receive and send Interest 1
55948 receive and send Data 1
55954 receive Interest 2, send Data 2 from ContentStore

PRODUCER
55522 receive Interest 1
55570 send Data 1

Observations:

  *   The link between HUB and PRODUCER is congested.
Evidence: Interest 1 is received 97ms after it's sent. Data 1 is received 378ms after it's sent.
  *   Interest 2 from CONSUMER to HUB is delayed.
  *   HUB log reveals that face 266 (toward CONSUMER) and face 264 (toward PRODUCER) are both UDP and have same local IP address.
The delay of Interest 2 from CONSUMER to HUB might be caused by the congestion between HUB and PRODUCER, because part of CONSUMER-HUB logical link shares same IP-layer link.

Yours, Junxiao

On Thu, Jan 29, 2015 at 7:56 PM, Gusev, Peter <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>> wrote:
Hi all,

I?m doing tests and explorations on the reasons, why does NdnCon experience rebufferings (i.e. interruptions in video stream which lead to algorithm restart).
I would appreciate any help/suggestions/advices in debugging/analyzing NFD logs and NFD itself.

More specifically, I?d like to hear your comments on the following case.
With the same configuration as before ([Consumer] <?> [NFD1] <==Ethernet_link==> [NFD2] <==Ethernet_link==> [NFD3] <?> [Producer]) consumer experienced interruption after getting frame 640. So I tracked down frame?s 641 interests and data in NFD logs:

NFD1 log: ($ cat consumer/nfd.log | grep "/641/data/%00%00?)

1422581555.423600 DEBUG: [Forwarder] onIncomingInterest face=265 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581555.423943 DEBUG: [Forwarder] onOutgoingInterest face=259 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581555.424205 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=1282205730 from=265 newPitEntry-to=259
^ 294ms (retransmission, confirmed by consumer log)
1422581555.718095 DEBUG: [Forwarder] onIncomingInterest face=265 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581555.718589 DEBUG: [Forwarder] onOutgoingInterest face=259 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581555.718929 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=589980969 from=265 retransmit-retry-to=259
^ 232ms
1422581555.950466 DEBUG: [Forwarder] onIncomingData face=259 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
1422581555.950763 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581555.950998 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00 inFace=259 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
1422581555.951438 DEBUG: [Forwarder] onOutgoingData face=265 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
^ 5ms
1422581555.956230 DEBUG: [Forwarder] onIncomingData face=259 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
1422581555.956496 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581555.956724 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00 inFace=259 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0

NFD2 log: ($ cat hub/nfd.log | grep "/641/data/%00%00?)

1422581521.773468 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581521.773947 DEBUG: [Forwarder] onOutgoingInterest face=264 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581521.774352 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=1282205730 from=266 newPitEntry-to=264
^ 522ms (??? where is the retransmission interest?)
1422581522.296967 DEBUG: [Forwarder] onIncomingData face=264 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
1422581522.297347 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581522.297614 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00 inFace=264 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
1422581522.298123 DEBUG: [Forwarder] onOutgoingData face=266 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
^ 5ms (ah, here it is? how?)
1422581522.303090 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581522.303430 DEBUG: [Forwarder] onOutgoingData face=266 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0

NFD3 log: ($ cat producer/nfd.log | grep "/641/data/%00%00?)

1422581555.255647 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581555.256007 DEBUG: [Forwarder] onOutgoingInterest face=269 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581555.256334 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=1282205730 from=266 newPitEntry-to=269
^ 47ms (!!! interest arrival was not late, data generation was not delayed)
1422581555.303275 DEBUG: [Forwarder] onIncomingData face=269 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
1422581555.303640 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581555.303928 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00 inFace=269 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
1422581555.304458 DEBUG: [Forwarder] onOutgoingData face=266 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0


The questions here are:
1. How did the retransmission interest arrived on NFD2 ~220ms later than was expected and actually after the first interest was already answered?
2. If the data was generated and answered by NFD3 in timely manner, why did data arrived on NFD2 after 522ms but not after ~50ms?

Some peculiar place of NFD2?s log:
$ sed -n 38830,38840p hub/nfd.log

1422581521.916149 DEBUG: [Forwarder] onIncomingData face=264 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/638/data/%00%0A/14/661/22/0
1422581521.916515 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/638/data/%00%0A
1422581521.916799 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/638/data/%00%0A inFace=264 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/638/data/%00%0A/14/661/22/0
1422581521.917301 DEBUG: [Forwarder] onOutgoingData face=266 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/638/data/%00%0A/14/661/22/0
^ 360ms
1422581522.277620 DEBUG: [Forwarder] onInterestUnsatisfied interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/499/data/%00%06
1422581522.278080 DEBUG: [Strategy] beforeExpirePendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/499/data/%00%06
1422581522.278524 DEBUG: [Forwarder] onInterestUnsatisfied interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/500/data/%00%06
1422581522.278901 DEBUG: [Strategy] beforeExpirePendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/500/data/%00%06
1422581522.279352 DEBUG: [Forwarder] onInterestUnsatisfied interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/501/data/%00%05
1422581522.279742 DEBUG: [Strategy] beforeExpirePendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/501/data/%00%05
1422581522.280119 DEBUG: [Forwarder] onInterestUnsatisfied interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/501/data/%00%06


I would appreciate any help.
Looking forward for the insights of NFD developers,

Thanks,

PS. full logs are attached

--
Peter Gusev
Programmer/Analyst @ REMAP, UCLA

peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>
+1 213 5872748<tel:%2B1%20213%205872748>
peetonn_ (skype)



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

From peter at remap.UCLA.EDU  Tue Feb  3 11:56:29 2015
From: peter at remap.UCLA.EDU (Gusev, Peter)
Date: Tue, 3 Feb 2015 19:56:29 +0000
Subject: [Nfd-dev] NDN-RTC: NFD processing logs
In-Reply-To: <020480B79F5DB249B89F4856EB5270EA986507A8@EM1A.ad.ucla.edu>
References: <82C9DE44-8E98-413B-8B62-2BB3FA7F9FEE@remap.ucla.edu>
	<FF26AA9A-F092-469B-9B5E-6F3F10CF64CB@remap.ucla.edu>
	<CAOFH+Ob_u4Up50zUq0vTD_cfphWDznCGnFYLp6vyEqW2Bk0TTQ@mail.gmail.com>
	<2F36281B-7C01-4A7A-A12C-17A224A9ABFB@remap.ucla.edu> <,
	<CAOFH+OaL8Ng6YBtkOB0pYT+CHx4hXwnM3J4S1Dn3rMwauoeLZQ@mail.gmail.com>
	<>> <020480B79F5DB249B89F4856EB5270EA986507A8@EM1A.ad.ucla.edu>
Message-ID: <DAC3DFD9-64AF-48F6-BCA2-FB4D8DE09791@remap.ucla.edu>

Hi Junxiao,

I run tests with all three (consumer, producer and hub) connected to the same 1Gbit switch. For the app configuration I tested - bitrate is ~150-200kbit/s, interest rate is about 50-60.

And discovered these cases:

Case #1

NFD1 (consumer):
1422920300.410412 DEBUG: [Forwarder] onIncomingInterest face=261 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920300.410804 DEBUG: [Forwarder] onOutgoingInterest face=259 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920300.411138 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=2128078661 from=261 newPitEntry-to=259
^ 0 sec, 440 msec // retransmission
1422920300.851526 DEBUG: [Forwarder] onIncomingInterest face=261 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920300.851843 DEBUG: [Forwarder] onOutgoingInterest face=259 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920300.852127 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=2749769734 from=261 retransmit-retry-to=259
^ 0 sec, 302 msec // data
1422920301.155108 DEBUG: [Forwarder] onIncomingData face=259 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
1422920301.155452 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920301.155680 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00 inFace=259 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
1422920301.156152 DEBUG: [Forwarder] onOutgoingData face=261 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0

NFD2 (hub):
1422920250.169018 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920250.169560 DEBUG: [Forwarder] onOutgoingInterest face=264 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920250.169959 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=2128078661 from=266 newPitEntry-to=264
^ 0 sec, 736.911 msec // retransmission
1422920250.906870 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920250.907384 DEBUG: [Forwarder] onOutgoingInterest face=264 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920250.907801 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=2749769734 from=266 retransmit-retry-to=264
^ 0 sec, 2.541 msec // data
1422920250.910342 DEBUG: [Forwarder] onIncomingData face=264 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
1422920250.910812 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920250.911125 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00 inFace=264 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
1422920250.911706 DEBUG: [Forwarder] onOutgoingData face=266 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
1422920250.922749 DEBUG: [Forwarder] onIncomingData face=264 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
1422920250.923068 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920250.923315 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00 inFace=264 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0

NFD3 (producer):
1422920296.818710 DEBUG: [Forwarder] onIncomingInterest face=268 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920296.819102 DEBUG: [Forwarder] onOutgoingInterest face=265 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920296.819408 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=2128078661 from=268 newPitEntry-to=265
^ 0 sec, 551.408 msec // data
1422920297.370816 DEBUG: [Forwarder] onIncomingData face=265 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
1422920297.371248 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920297.371547 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00 inFace=265 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
1422920297.372106 DEBUG: [Forwarder] onOutgoingData face=268 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
^ 0 sec, 184.298 msec // retransmission
1422920297.556404 DEBUG: [Forwarder] onIncomingInterest face=268 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920297.557030 DEBUG: [Forwarder] onOutgoingData face=268 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0

Case #2

NFD1 (consumer):
1422919936.433502 DEBUG: [Forwarder] onIncomingInterest face=261 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00
1422919936.434221 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=3853552983 from=261 newPitEntry-to=259
^ 0 sec, 402.119 msec
1422919936.836340 DEBUG: [Forwarder] onIncomingData face=259 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0
1422919936.836649 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00
1422919936.836871 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00 inFace=259 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0
1422919936.837279 DEBUG: [Forwarder] onOutgoingData face=261 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0


NFD2 (hub):
1422919886.178188 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00
1422919886.179368 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=3791853569 from=266 newPitEntry-to=264
^ 0 sec, 89.772 msec
1422919886.269140 DEBUG: [Forwarder] onIncomingData face=264 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00/1/4252/150/0
1422919886.269671 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00
1422919886.270079 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00 inFace=264 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00/1/4252/150/0
1422919886.270718 DEBUG: [Forwarder] onOutgoingData face=266 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00/1/4252/150/0


NFD3 (producer):
1422919932.865989 DEBUG: [Forwarder] onIncomingInterest face=268 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00
1422919932.866855 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=3853552983 from=268 newPitEntry-to=265
^ 0 sec, 90.492 msec
1422919932.957347 DEBUG: [Forwarder] onIncomingData face=265 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0
1422919932.958010 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00
1422919932.958342 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00 inFace=265 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0
1422919932.958955 DEBUG: [Forwarder] onOutgoingData face=268 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0


Can these be cases of congestions on such wideband setup?

Thanks,

--
Peter Gusev
Programmer/Analyst @ REMAP, UCLA

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

On Feb 2, 2015, at 7:04 PM, Burke, Jeff <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>> wrote:

Junxiao,
Thanks for considering this.
These are gigabit nics doing nothing else of significance, with ndnrtc traffic in the hundreds of kilobits/sec. I don't see how local congestion in the hundreds of ms (of all packets) would result?
Jeff

-----Original Message-----
From: Junxiao Shi [shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>]
Received: Monday, 02 Feb 2015, 11:33AM
To: Gusev, Peter [peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>]
CC: {nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>} [nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>]
Subject: Re: [Nfd-dev] NDN-RTC: NFD processing logs

Hi Peter

This statement means:
Both CONSUMER-HUB and HUB-PRODUCER links are using the same physical NIC of HUB router.
Thus, a congestion on HUB-PRODUCER can cause an underlying congestion on this physical NIC, and therefore cause a delay on CONSUMER-HUB link.

To eliminate this factor, use two physical NICs on the HUB, so that CONSUMER-HUB and HUB-PRODUCER links won't affect each other.

Yours, Junxiao

On Mon, Feb 2, 2015 at 12:24 PM, Gusev, Peter <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>> wrote:
Hi Junxiao,

Thanks for your  analysis!
You?re right, there?s a clock skew (even though all three machines are NTP-synchronized to the time1.ucla.edu<http://time1.ucla.edu/>).


  *   HUB log reveals that face 266 (toward CONSUMER) and face 264 (toward PRODUCER) are both UDP and have same local IP address.
The delay of Interest 2 from CONSUMER to HUB might be caused by the congestion between HUB and PRODUCER, because part of CONSUMER-HUB logical link shares same IP-layer link.

I didn?t quite get this statement - do you mean that consumer and producer run on the same machine? In the scenario I run, there were three machines (consumer 128.97.152.44, hub 131.179.141.51 and producer 131.179.141.33) connected using 1Gbit switches (LAN). Do you think this could be a congestion problem still?
I?ll run new tests now eliminating one network segment by connecting consumer to the 131.179.141.xx subnet.

Thanks,

--
Peter Gusev
Programmer/Analyst @ REMAP, UCLA

peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>
+1 213 5872748<tel:%2B1%20213%205872748>
peetonn_ (skype)

On Feb 1, 2015, at 9:32 PM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:

Hi Peter

There's a clock skew among three machines.
I picked one of the earliest Interests as a sample:
CONSUMER
1422581537.761808 DEBUG: [Forwarder] onOutgoingInterest face=259 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/key/5/data/%00%00

HUB
1422581504.112268 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/key/5/data/%00%00
1422581504.112966 DEBUG: [Forwarder] onOutgoingInterest face=264 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/key/5/data/%00%00

PRODUCER
1422581537.499525 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/key/5/data/%00%00

Assuming 2ms link delay: clock on HUB is ~33651ms behind of CONSUMER; clock on PRODUCER is ~266ms behind of CONSUMER.


After compensating for the clock skew, the log snippet below says (in terms of CONSUMER clock, milliseconds):
CONSUMER
55424 send Interest 1
55718 send Interest 2
55950 receive Data 1
55956 receive Data 2

HUB
55425 receive and send Interest 1
55948 receive and send Data 1
55954 receive Interest 2, send Data 2 from ContentStore

PRODUCER
55522 receive Interest 1
55570 send Data 1

Observations:

  *   The link between HUB and PRODUCER is congested.
Evidence: Interest 1 is received 97ms after it's sent. Data 1 is received 378ms after it's sent.
  *   Interest 2 from CONSUMER to HUB is delayed.
  *   HUB log reveals that face 266 (toward CONSUMER) and face 264 (toward PRODUCER) are both UDP and have same local IP address.
The delay of Interest 2 from CONSUMER to HUB might be caused by the congestion between HUB and PRODUCER, because part of CONSUMER-HUB logical link shares same IP-layer link.

Yours, Junxiao

On Thu, Jan 29, 2015 at 7:56 PM, Gusev, Peter <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>> wrote:
Hi all,

I?m doing tests and explorations on the reasons, why does NdnCon experience rebufferings (i.e. interruptions in video stream which lead to algorithm restart).
I would appreciate any help/suggestions/advices in debugging/analyzing NFD logs and NFD itself.

More specifically, I?d like to hear your comments on the following case.
With the same configuration as before ([Consumer] <?> [NFD1] <==Ethernet_link==> [NFD2] <==Ethernet_link==> [NFD3] <?> [Producer]) consumer experienced interruption after getting frame 640. So I tracked down frame?s 641 interests and data in NFD logs:

NFD1 log: ($ cat consumer/nfd.log | grep "/641/data/%00%00?)

1422581555.423600 DEBUG: [Forwarder] onIncomingInterest face=265 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581555.423943 DEBUG: [Forwarder] onOutgoingInterest face=259 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581555.424205 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=1282205730 from=265 newPitEntry-to=259
^ 294ms (retransmission, confirmed by consumer log)
1422581555.718095 DEBUG: [Forwarder] onIncomingInterest face=265 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581555.718589 DEBUG: [Forwarder] onOutgoingInterest face=259 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581555.718929 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=589980969 from=265 retransmit-retry-to=259
^ 232ms
1422581555.950466 DEBUG: [Forwarder] onIncomingData face=259 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
1422581555.950763 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581555.950998 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00 inFace=259 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
1422581555.951438 DEBUG: [Forwarder] onOutgoingData face=265 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
^ 5ms
1422581555.956230 DEBUG: [Forwarder] onIncomingData face=259 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
1422581555.956496 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581555.956724 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00 inFace=259 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0

NFD2 log: ($ cat hub/nfd.log | grep "/641/data/%00%00?)

1422581521.773468 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581521.773947 DEBUG: [Forwarder] onOutgoingInterest face=264 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581521.774352 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=1282205730 from=266 newPitEntry-to=264
^ 522ms (??? where is the retransmission interest?)
1422581522.296967 DEBUG: [Forwarder] onIncomingData face=264 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
1422581522.297347 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581522.297614 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00 inFace=264 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
1422581522.298123 DEBUG: [Forwarder] onOutgoingData face=266 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
^ 5ms (ah, here it is? how?)
1422581522.303090 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581522.303430 DEBUG: [Forwarder] onOutgoingData face=266 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0

NFD3 log: ($ cat producer/nfd.log | grep "/641/data/%00%00?)

1422581555.255647 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581555.256007 DEBUG: [Forwarder] onOutgoingInterest face=269 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581555.256334 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=1282205730 from=266 newPitEntry-to=269
^ 47ms (!!! interest arrival was not late, data generation was not delayed)
1422581555.303275 DEBUG: [Forwarder] onIncomingData face=269 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
1422581555.303640 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00
1422581555.303928 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00 inFace=269 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0
1422581555.304458 DEBUG: [Forwarder] onOutgoingData face=266 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/641/data/%00%00/5/664/22/0


The questions here are:
1. How did the retransmission interest arrived on NFD2 ~220ms later than was expected and actually after the first interest was already answered?
2. If the data was generated and answered by NFD3 in timely manner, why did data arrived on NFD2 after 522ms but not after ~50ms?

Some peculiar place of NFD2?s log:
$ sed -n 38830,38840p hub/nfd.log

1422581521.916149 DEBUG: [Forwarder] onIncomingData face=264 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/638/data/%00%0A/14/661/22/0
1422581521.916515 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/638/data/%00%0A
1422581521.916799 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/638/data/%00%0A inFace=264 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/638/data/%00%0A/14/661/22/0
1422581521.917301 DEBUG: [Forwarder] onOutgoingData face=266 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/638/data/%00%0A/14/661/22/0
^ 360ms
1422581522.277620 DEBUG: [Forwarder] onInterestUnsatisfied interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/499/data/%00%06
1422581522.278080 DEBUG: [Strategy] beforeExpirePendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/499/data/%00%06
1422581522.278524 DEBUG: [Forwarder] onInterestUnsatisfied interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/500/data/%00%06
1422581522.278901 DEBUG: [Strategy] beforeExpirePendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/500/data/%00%06
1422581522.279352 DEBUG: [Forwarder] onInterestUnsatisfied interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/501/data/%00%05
1422581522.279742 DEBUG: [Strategy] beforeExpirePendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/501/data/%00%05
1422581522.280119 DEBUG: [Forwarder] onInterestUnsatisfied interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/501/data/%00%06


I would appreciate any help.
Looking forward for the insights of NFD developers,

Thanks,

PS. full logs are attached

--
Peter Gusev
Programmer/Analyst @ REMAP, UCLA

peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>
+1 213 5872748<tel:%2B1%20213%205872748>
peetonn_ (skype)




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

From alexander.afanasyev at ucla.edu  Tue Feb  3 16:24:15 2015
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Tue, 3 Feb 2015 16:24:15 -0800
Subject: [Nfd-dev] NFD 0.3.0 and ndn-cxx 0.3.0 released
Message-ID: <5D0E3744-1A85-4C01-B85D-BBD8E5682F7A@ucla.edu>

Dear all,

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

The detailed release notes:
  - for NFD: http://named-data.net/doc/NFD/0.3.0/RELEASE_NOTES.html
  - for ndn-cxx library: http://named-data.net/doc/ndn-cxx/0.3.0/RELEASE_NOTES.html

More details about NFD, tutorials, HOWTOs, a FAQ and other useful resources are
available on official webpages of NFD and ndn-cxx:
  - http://named-data.net/doc/NFD/0.3.0/
  - http://named-data.net/doc/ndn-cxx/0.3.0/

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

* * *
The NFD Team:
  Alex Afanasyev, Junxiao Shi, Beichuan Zhang, Lixia Zhang, Ilya Moiseenko,
  Yingdi Yu, Wentao Shang, 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

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

From shijunxiao at email.arizona.edu  Tue Feb  3 21:50:35 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Tue, 3 Feb 2015 22:50:35 -0700
Subject: [Nfd-dev] NDN-RTC: NFD processing logs
In-Reply-To: <DAC3DFD9-64AF-48F6-BCA2-FB4D8DE09791@remap.ucla.edu>
References: <82C9DE44-8E98-413B-8B62-2BB3FA7F9FEE@remap.ucla.edu>
	<FF26AA9A-F092-469B-9B5E-6F3F10CF64CB@remap.ucla.edu>
	<CAOFH+Ob_u4Up50zUq0vTD_cfphWDznCGnFYLp6vyEqW2Bk0TTQ@mail.gmail.com>
	<2F36281B-7C01-4A7A-A12C-17A224A9ABFB@remap.ucla.edu>
	<020480B79F5DB249B89F4856EB5270EA986507A8@EM1A.ad.ucla.edu>
	<DAC3DFD9-64AF-48F6-BCA2-FB4D8DE09791@remap.ucla.edu>
Message-ID: <CAOFH+OZ8A7MisNk1z=aOdcPaHXd99g83VUvN6+Za=cZA8XOQwg@mail.gmail.com>

Hi Peter

I forgot to ask earlier: what's the MTU of the NICs?
Make sure the MTU is 9000 octets or higher, otherwise IP fragmentation will
severely affect performance.


Congestion is unlikely to happen with 200Kbps traffic on 1000Mbps link.
CPU is also unlikely to be a bottleneck for 60 Interests/s.

Use `tcpdump` to see exactly when the packet is transmitted onto the
network, in order to determine whether the delay is happening on sender
host or receiver host.
Running `tcpdump` on the host itself will affect its performance. If an
impact is evident, you could setup port mirroring on the switch, and run
`tcpdump` on another machine that is connected to the mirrored port.

Yours, Junxiao

On Tue, Feb 3, 2015 at 12:56 PM, Gusev, Peter <peter at remap.ucla.edu> wrote:

>  Hi Junxiao,
>
>  I run tests with all three (consumer, producer and hub) connected to the
> same 1Gbit switch. For the app configuration I tested - bitrate is
> ~150-200kbit/s, interest rate is about 50-60.
>
>  And discovered these cases:
>
>  *Case #1*
>
>  *NFD1 (consumer):*
>  1422920300.410412 DEBUG: [Forwarder] onIncomingInterest face=261
> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
> 1422920300.410804 DEBUG: [Forwarder] onOutgoingInterest face=259
> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
> 1422920300.411138 DEBUG: [BestRouteStrategy2]
> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=*2128078661
> <2128078661>* from=261 newPitEntry-to=259
> ^ 0 sec, *440 msec **// retransmission*
> 1422920300.851526 DEBUG: [Forwarder] onIncomingInterest face=261
> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
> 1422920300.851843 DEBUG: [Forwarder] onOutgoingInterest face=259
> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
> 1422920300.852127 DEBUG: [BestRouteStrategy2]
> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=
> *2749769734* from=261 retransmit-retry-to=259
> ^ 0 sec, *302 msec *// data
> 1422920301.155108 DEBUG: [Forwarder] onIncomingData face=259
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
> 1422920301.155452 DEBUG: [Forwarder] onIncomingData
> matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
> 1422920301.155680 DEBUG: [Strategy] beforeSatisfyPendingInterest
> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
> inFace=259
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
> 1422920301.156152 DEBUG: [Forwarder] onOutgoingData face=261
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
>
>  *NFD2 (hub):*
>  1422920250.169018 DEBUG: [Forwarder] onIncomingInterest face=266
> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
> 1422920250.169560 DEBUG: [Forwarder] onOutgoingInterest face=264
> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
> 1422920250.169959 DEBUG: [BestRouteStrategy2]
> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=*2128078661
> <2128078661>* from=266 newPitEntry-to=264
> ^ 0 sec, *736.911 msec *// retransmission
> 1422920250.906870 DEBUG: [Forwarder] onIncomingInterest face=266
> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
> 1422920250.907384 DEBUG: [Forwarder] onOutgoingInterest face=264
> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
> 1422920250.907801 DEBUG: [BestRouteStrategy2]
> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=
> *2749769734* from=266 retransmit-retry-to=264
> ^ 0 sec, *2.541 msec **// data*
> 1422920250.910342 DEBUG: [Forwarder] onIncomingData face=264
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
> 1422920250.910812 DEBUG: [Forwarder] onIncomingData
> matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
> 1422920250.911125 DEBUG: [Strategy] beforeSatisfyPendingInterest
> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
> inFace=264
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
> 1422920250.911706 DEBUG: [Forwarder] onOutgoingData face=266
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
> 1422920250.922749 DEBUG: [Forwarder] *onIncomingData* face=264
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
> 1422920250.923068 DEBUG: [Forwarder] onIncomingData
> matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
> 1422920250.923315 DEBUG: [Strategy] beforeSatisfyPendingInterest
> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
> inFace=264
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
>
>  NFD3 (producer):
>  1422920296.818710 DEBUG: [Forwarder] onIncomingInterest face=268
> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
> 1422920296.819102 DEBUG: [Forwarder] onOutgoingInterest face=265
> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
> 1422920296.819408 DEBUG: [BestRouteStrategy2]
> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=*2128078661
> <2128078661>* from=268 newPitEntry-to=265
> ^ 0 sec, *551.408 msec **// data*
> 1422920297.370816 DEBUG: [Forwarder] onIncomingData face=265
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
> 1422920297.371248 DEBUG: [Forwarder] onIncomingData
> matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
> 1422920297.371547 DEBUG: [Strategy] beforeSatisfyPendingInterest
> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
> inFace=265
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
> 1422920297.372106 DEBUG: [Forwarder] onOutgoingData face=268
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
> ^ 0 sec, 184.298 msec *// retransmission*
> 1422920297.556404 DEBUG: [Forwarder] onIncomingInterest face=268
> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
> 1422920297.557030 DEBUG: [Forwarder] onOutgoingData face=268
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
>
>  *Case #2*
>
>  *NFD1 (consumer):*
>  1422919936.433502 DEBUG: [Forwarder] onIncomingInterest face=261
> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00
> 1422919936.434221 DEBUG: [BestRouteStrategy2]
> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=
> 3853552983 from=261 newPitEntry-to=259
> ^ 0 sec, *402.119 msec*
> 1422919936.836340 DEBUG: [Forwarder] onIncomingData face=259
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0
> 1422919936.836649 DEBUG: [Forwarder] onIncomingData
> matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00
> 1422919936.836871 DEBUG: [Strategy] beforeSatisfyPendingInterest
> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00
> inFace=259
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0
> 1422919936.837279 DEBUG: [Forwarder] onOutgoingData face=261
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0
>
>
>  *NFD2 (hub):*
>  1422919886.178188 DEBUG: [Forwarder] onIncomingInterest face=266
> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00
> 1422919886.179368 DEBUG: [BestRouteStrategy2]
> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=3791853569
> from=266 newPitEntry-to=264
> ^ 0 sec, *89.772 msec*
> 1422919886.269140 DEBUG: [Forwarder] onIncomingData face=264
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00/1/4252/150/0
> 1422919886.269671 DEBUG: [Forwarder] onIncomingData
> matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00
> 1422919886.270079 DEBUG: [Strategy] beforeSatisfyPendingInterest
> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00
> inFace=264
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00/1/4252/150/0
> 1422919886.270718 DEBUG: [Forwarder] onOutgoingData face=266
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00/1/4252/150/0
>
>
>  *NFD3 (producer):*
>  1422919932.865989 DEBUG: [Forwarder] onIncomingInterest face=268
> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00
> 1422919932.866855 DEBUG: [BestRouteStrategy2]
> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=
> 3853552983 from=268 newPitEntry-to=265
> ^ 0 sec, *90.492 msec*
> 1422919932.957347 DEBUG: [Forwarder] onIncomingData face=265
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0
> 1422919932.958010 DEBUG: [Forwarder] onIncomingData
> matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00
> 1422919932.958342 DEBUG: [Strategy] beforeSatisfyPendingInterest
> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00
> inFace=265
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0
> 1422919932.958955 DEBUG: [Forwarder] onOutgoingData face=268
> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0
>
>
>  Can these be cases of congestions on such wideband setup?
>
>    Thanks,
>
>  --
> Peter Gusev
>  Programmer/Analyst @ REMAP, UCLA
>
> peter at remap.ucla.edu
> +1 213 5872748
> peetonn_ (skype)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150203/e6b11aa4/attachment.html>

From chaim.rieger at gmail.com  Tue Feb  3 21:55:32 2015
From: chaim.rieger at gmail.com (Chaim Rieger)
Date: Tue, 03 Feb 2015 21:55:32 -0800
Subject: [Nfd-dev] NFD 0.3.0 and ndn-cxx 0.3.0 released
In-Reply-To: <5D0E3744-1A85-4C01-B85D-BBD8E5682F7A@ucla.edu>
References: <5D0E3744-1A85-4C01-B85D-BBD8E5682F7A@ucla.edu>
Message-ID: <54D1B454.1080007@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2/3/2015 4:24 PM, Alex Afanasyev wrote:
> Dear all,
> 
> We are pleased to announce release of version 0.3.0 of Named Data 
> Networking Forwarding Daemon (NFD) and ndn-cxx library.
> 
Successfully installed on Ubuntu 14.04 and ODroid XU3

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJU0bRUAAoJEDAlxYoZHOEqmdUQAJt2kb73sloEYIDAPHy8wfEb
nX2qshse/PgQAWadUVxcc8+7CIl10Zc4kkiwf4sl5x9+Z+7KKxkAbVkeX8cvJ9iQ
O7WKXgQJCIvKzds44M1RNB3lv0HfmvBvvZ6mV47FwSOxr8ngK05VJOEdTirCfBlg
U8ND53uKvTDYiOpNaPiO9aqBPwN4Jwi7DQ8ro6RW89lc8hUHdYyGI6Q9xVemowAq
NoWF/Mn5OFaNYEQnSftcW2VJNaiHLpnZmSt2OlJL6TKopdFJyRjeAG11TQnP3wVT
iXF2EXLB3HZTV8yTVQe8uVuH3QQtNtpGbENmNc9D8S/WnY13fAxalyjG/9JY/xGv
W4q43jox7wMF1yMBT2Hx8Hp68NS/IScjziJMD+qvDh2H8F7wsO3PdLlP7ihveRJU
pSCsrxXtmO4mtKLm/0+n7FYHMm5j/5OVecQYEGF3F0qKGezux8EuU90SyNRNmzty
4v0Vs6Sv8PhVdX2U4RV2ABtEAXJBxsBlADMMXFHUzJa6+kLA4cGHQb9TUDgLevvj
A0+VVqT1MM3+twGP703DbqpllKAnW+NTgDrHwA19TR6gCKIbxodVlrMD6GKqJYA3
kCWFlL5/0K1N8a/puzcsP5WTaY5p60qMaqIEeuc6idx5QCSFZT+6/0/T6wSV8o26
GQQZ6RBa2Z3pA+dspsI9
=m3oP
-----END PGP SIGNATURE-----


From chaim.rieger at gmail.com  Tue Feb  3 21:55:32 2015
From: chaim.rieger at gmail.com (Chaim Rieger)
Date: Tue, 03 Feb 2015 21:55:32 -0800
Subject: [Nfd-dev] NFD 0.3.0 and ndn-cxx 0.3.0 released
In-Reply-To: <5D0E3744-1A85-4C01-B85D-BBD8E5682F7A@ucla.edu>
References: <5D0E3744-1A85-4C01-B85D-BBD8E5682F7A@ucla.edu>
Message-ID: <54D1B454.7080001@gmail.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2/3/2015 4:24 PM, Alex Afanasyev wrote:

Successfully installed on Ubuntu 14.04 and ODroid XU3

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBAgAGBQJU0bRQAAoJEDAlxYoZHOEq6ekP/0UyOv0Pbz9vxls3Mkojq0os
8uQc467RXJCAnTSRUQhl+ieOWh6Zq+LQmEdVVjCHSxfk3Wu42j8s/3G9mNTsn8I3
UkyWv7BmicJlonAgnUCGz6YkOOareSuTgXierjE4LQHEfhlb90AIfP8XIxVjwFc0
jQWUkOO1TBWQnN9rGVukplsXYtWnMpxd3f2saU5EYGDIwWd+tOT5fb5v005Ls37U
hZtmRtXpUXpgESeRyNHIk7AewE4BLR8xiJyYZTJCA/wbuyxkSXtqBaaTYlG2BeU4
8ivdVKklA9fav+WRBBnjaAnf/tGA8K2PqSyHkpmMlQPB4QNNxwOOJ9A/8y7ViskM
cbKOgibOF9UcqUsVhE3BsKTtVLh0CAiVbEjRQ+ruVv8zdISV23Ci46AdUvE2TaPx
qCNfGgvQ3Rih+BqD/LYWnPkQxRz2/4XZ4GFdiI721LO3NqXD+GrB/5yPqfLyt22M
jRfnttbXaqB85r6TN+h6GLE8jUo1Eck8Tal6EvdTHe8+r5dcO3qgmO0CWWN1vX7Z
1rUeQ/isi6HNMr8pVyV9Jmt7NQ9Jkc0Ho7sTuejSa5NQQkaB+RU5/1/Uikx6uLpB
0P4hv8HdJQ6fuZAnXijVgV5O9gmRKO+UeCQHYfRkAkXfo47vshj2sMr/22BxSrtP
mf3pqex5z4DSK27uhAbP
=AePm
-----END PGP SIGNATURE-----


From jburke at remap.UCLA.EDU  Tue Feb  3 22:01:46 2015
From: jburke at remap.UCLA.EDU (Burke, Jeff)
Date: Wed, 4 Feb 2015 06:01:46 +0000
Subject: [Nfd-dev] NDN-RTC: NFD processing logs
In-Reply-To: <CAOFH+OZ8A7MisNk1z=aOdcPaHXd99g83VUvN6+Za=cZA8XOQwg@mail.gmail.com>
Message-ID: <D0F6F48F.1B3622%jburke@remap.ucla.edu>

Junxiao,

The application is intended to work over the current internet with low risk of IP fragmentation, so we are designing the packet sizes for MTUs of 1500 octets.

Peter, can you run NTP in a peer-to-peer configuration to lower the clock offset between the vious machines and make it easier to troubleshoot just based on the logging?  I can give you a configuration tomorrow.

Junxiao, in addition to tcpdump, is there anything that logs at a lower layer in NFD which we could use to see when interest/data bits first come in over the wire?

We will bring the whole setup to the ndn retreat...

Jeff


From: Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>
Date: Tue, 3 Feb 2015 22:50:35 -0700
To: "Gusev, Peter" <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>>
Cc: Jeff Burke <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>>, "nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>" <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: Re: [Nfd-dev] NDN-RTC: NFD processing logs

Hi Peter

I forgot to ask earlier: what's the MTU of the NICs?
Make sure the MTU is 9000 octets or higher, otherwise IP fragmentation will severely affect performance.


Congestion is unlikely to happen with 200Kbps traffic on 1000Mbps link.
CPU is also unlikely to be a bottleneck for 60 Interests/s.

Use `tcpdump` to see exactly when the packet is transmitted onto the network, in order to determine whether the delay is happening on sender host or receiver host.
Running `tcpdump` on the host itself will affect its performance. If an impact is evident, you could setup port mirroring on the switch, and run `tcpdump` on another machine that is connected to the mirrored port.

Yours, Junxiao

On Tue, Feb 3, 2015 at 12:56 PM, Gusev, Peter <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>> wrote:
Hi Junxiao,

I run tests with all three (consumer, producer and hub) connected to the same 1Gbit switch. For the app configuration I tested - bitrate is ~150-200kbit/s, interest rate is about 50-60.

And discovered these cases:

Case #1

NFD1 (consumer):
1422920300.410412DEBUG: [Forwarder] onIncomingInterest face=261 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920300.410804 DEBUG: [Forwarder] onOutgoingInterest face=259 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920300.411138 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=2128078661<tel:2128078661> from=261 newPitEntry-to=259
^ 0 sec, 440 msec // retransmission
1422920300.851526 DEBUG: [Forwarder] onIncomingInterest face=261 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920300.851843 DEBUG: [Forwarder] onOutgoingInterest face=259 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920300.852127 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=2749769734 from=261 retransmit-retry-to=259
^ 0 sec, 302 msec // data
1422920301.155108 DEBUG: [Forwarder] onIncomingData face=259 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
1422920301.155452 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920301.155680 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00 inFace=259 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
1422920301.156152 DEBUG: [Forwarder] onOutgoingData face=261 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0

NFD2 (hub):
1422920250.169018DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920250.169560 DEBUG: [Forwarder] onOutgoingInterest face=264 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920250.169959 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=2128078661<tel:2128078661> from=266 newPitEntry-to=264
^ 0 sec, 736.911 msec // retransmission
1422920250.906870 DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920250.907384 DEBUG: [Forwarder] onOutgoingInterest face=264 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920250.907801 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=2749769734 from=266 retransmit-retry-to=264
^ 0 sec, 2.541 msec // data
1422920250.910342 DEBUG: [Forwarder] onIncomingData face=264 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
1422920250.910812 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920250.911125 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00 inFace=264 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
1422920250.911706 DEBUG: [Forwarder] onOutgoingData face=266 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
1422920250.922749 DEBUG: [Forwarder] onIncomingData face=264 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
1422920250.923068 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920250.923315 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00 inFace=264 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0

NFD3 (producer):
1422920296.818710 DEBUG: [Forwarder] onIncomingInterest face=268 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920296.819102 DEBUG: [Forwarder] onOutgoingInterest face=265 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920296.819408 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=2128078661<tel:2128078661> from=268 newPitEntry-to=265
^ 0 sec, 551.408 msec // data
1422920297.370816 DEBUG: [Forwarder] onIncomingData face=265 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
1422920297.371248 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920297.371547 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00 inFace=265 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
1422920297.372106 DEBUG: [Forwarder] onOutgoingData face=268 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
^ 0 sec, 184.298 msec// retransmission
1422920297.556404 DEBUG: [Forwarder] onIncomingInterest face=268 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920297.557030 DEBUG: [Forwarder] onOutgoingData face=268 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0

Case #2

NFD1 (consumer):
1422919936.433502DEBUG: [Forwarder] onIncomingInterest face=261 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00
1422919936.434221 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=3853552983<tel:3853552983> from=261 newPitEntry-to=259
^ 0 sec, 402.119 msec
1422919936.836340 DEBUG: [Forwarder] onIncomingData face=259 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0
1422919936.836649 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00
1422919936.836871 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00 inFace=259 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0
1422919936.837279 DEBUG: [Forwarder] onOutgoingData face=261 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0


NFD2 (hub):
1422919886.178188DEBUG: [Forwarder] onIncomingInterest face=266 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00
1422919886.179368 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=3791853569 from=266 newPitEntry-to=264
^ 0 sec, 89.772 msec
1422919886.269140 DEBUG: [Forwarder] onIncomingData face=264 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00/1/4252/150/0
1422919886.269671 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00
1422919886.270079 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00 inFace=264 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00/1/4252/150/0
1422919886.270718 DEBUG: [Forwarder] onOutgoingData face=266 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00/1/4252/150/0


NFD3 (producer):
1422919932.865989DEBUG: [Forwarder] onIncomingInterest face=268 interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00
1422919932.866855 DEBUG: [BestRouteStrategy2] /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=3853552983<tel:3853552983> from=268 newPitEntry-to=265
^ 0 sec, 90.492 msec
1422919932.957347 DEBUG: [Forwarder] onIncomingData face=265 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0
1422919932.958010 DEBUG: [Forwarder] onIncomingData matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00
1422919932.958342 DEBUG: [Strategy] beforeSatisfyPendingInterest pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00 inFace=265 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0
1422919932.958955 DEBUG: [Forwarder] onOutgoingData face=268 data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0


Can these be cases of congestions on such wideband setup?

Thanks,

--
Peter Gusev
Programmer/Analyst @ REMAP, UCLA

peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>
+1 213 5872748<tel:%2B1%20213%205872748>
peetonn_ (skype)

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

From davidepesa at gmail.com  Wed Feb  4 00:14:38 2015
From: davidepesa at gmail.com (Davide Pesavento)
Date: Wed, 04 Feb 2015 08:14:38 +0000
Subject: [Nfd-dev] NDN-RTC: NFD processing logs
References: <CAOFH+OZ8A7MisNk1z=aOdcPaHXd99g83VUvN6+Za=cZA8XOQwg@mail.gmail.com>
	<D0F6F48F.1B3622%jburke@remap.ucla.edu>
Message-ID: <CADfzvvZZK-Qp1oE9hjpnNzzmQgW3U=hevNYKg1MPLhZBCgF-hA@mail.gmail.com>

Hi Jeff,

Regarding your last question, if you enable the TRACE log level in NFD
configuration file you should get additional logging when the face receives
or sends anything over the wire. You should see something like:

TRACE: [UdpFace] [id:42,...] Received X bytes
or
TRACE: [UdpFace] [id:42,...] Sent X bytes

If my memory serves me well, those are respectively the first and last
messages printed by NFD.

Best,
Davide

On Wed, Feb 4, 2015, 7:01 AM Burke, Jeff <jburke at remap.ucla.edu> wrote:

>  Junxiao,
>
>  The application is intended to work over the current internet with low
> risk of IP fragmentation, so we are designing the packet sizes for MTUs of
> 1500 octets.
>
>  Peter, can you run NTP in a peer-to-peer configuration to lower the
> clock offset between the vious machines and make it easier to troubleshoot
> just based on the logging?  I can give you a configuration tomorrow.
>
>  Junxiao, in addition to tcpdump, is there anything that logs at a lower
> layer in NFD which we could use to see when interest/data bits first come
> in over the wire?
>
>  We will bring the whole setup to the ndn retreat...
>
>  Jeff
>
>
>   From: Junxiao Shi <shijunxiao at email.arizona.edu>
> Date: Tue, 3 Feb 2015 22:50:35 -0700
> To: "Gusev, Peter" <peter at remap.ucla.edu>
> Cc: Jeff Burke <jburke at remap.ucla.edu>, "nfd-dev at lists.cs.ucla.edu" <
> nfd-dev at lists.cs.ucla.edu>
>
> Subject: Re: [Nfd-dev] NDN-RTC: NFD processing logs
>
> Hi Peter
>
>  I forgot to ask earlier: what's the MTU of the NICs?
> Make sure the MTU is 9000 octets or higher, otherwise IP fragmentation
> will severely affect performance.
>
>
>  Congestion is unlikely to happen with 200Kbps traffic on 1000Mbps link.
> CPU is also unlikely to be a bottleneck for 60 Interests/s.
>
>  Use `tcpdump` to see exactly when the packet is transmitted onto the
> network, in order to determine whether the delay is happening on sender
> host or receiver host.
> Running `tcpdump` on the host itself will affect its performance. If an
> impact is evident, you could setup port mirroring on the switch, and run
> `tcpdump` on another machine that is connected to the mirrored port.
>
>  Yours, Junxiao
>
> On Tue, Feb 3, 2015 at 12:56 PM, Gusev, Peter <peter at remap.ucla.edu>
> wrote:
>
> Hi Junxiao,
>>
>>  I run tests with all three (consumer, producer and hub) connected to
>> the same 1Gbit switch. For the app configuration I tested - bitrate is
>> ~150-200kbit/s, interest rate is about 50-60.
>>
>>  And discovered these cases:
>>
>>  *Case #1*
>>
>>  *NFD1 (consumer):*
>>
> 1422920300.410412DEBUG: [Forwarder] onIncomingInterest face=261
>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>>
> 1422920300.410804 DEBUG: [Forwarder] onOutgoingInterest face=259
>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>> 1422920300.411138 DEBUG: [BestRouteStrategy2]
>> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=*2128078661
>> <2128078661>* from=261 newPitEntry-to=259
>> ^ 0 sec, *440 msec **// retransmission*
>> 1422920300.851526 DEBUG: [Forwarder] onIncomingInterest face=261
>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>> 1422920300.851843 DEBUG: [Forwarder] onOutgoingInterest face=259
>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>> 1422920300.852127 DEBUG: [BestRouteStrategy2]
>> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=
>> *2749769734* from=261 retransmit-retry-to=259
>> ^ 0 sec, *302 msec *// data
>> 1422920301.155108 DEBUG: [Forwarder] onIncomingData face=259
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
>> 1422920301.155452 DEBUG: [Forwarder] onIncomingData
>> matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>> 1422920301.155680 DEBUG: [Strategy] beforeSatisfyPendingInterest
>> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>> inFace=259
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
>> 1422920301.156152 DEBUG: [Forwarder] onOutgoingData face=261
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
>>
>
>>  *NFD2 (hub):*
>>  1422920250.169018DEBUG: [Forwarder] onIncomingInterest face=266
>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>>
> 1422920250.169560 DEBUG: [Forwarder] onOutgoingInterest face=264
>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>> 1422920250.169959 DEBUG: [BestRouteStrategy2]
>> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=*2128078661
>> <2128078661>* from=266 newPitEntry-to=264
>> ^ 0 sec, *736.911 msec *// retransmission
>> 1422920250.906870 DEBUG: [Forwarder] onIncomingInterest face=266
>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>> 1422920250.907384 DEBUG: [Forwarder] onOutgoingInterest face=264
>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>> 1422920250.907801 DEBUG: [BestRouteStrategy2]
>> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=
>> *2749769734* from=266 retransmit-retry-to=264
>> ^ 0 sec, *2.541 msec **// data*
>> 1422920250.910342 DEBUG: [Forwarder] onIncomingData face=264
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
>> 1422920250.910812 DEBUG: [Forwarder] onIncomingData
>> matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>> 1422920250.911125 DEBUG: [Strategy] beforeSatisfyPendingInterest
>> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>> inFace=264
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
>> 1422920250.911706 DEBUG: [Forwarder] onOutgoingData face=266
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
>> 1422920250.922749 DEBUG: [Forwarder] *onIncomingData* face=264
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
>> 1422920250.923068 DEBUG: [Forwarder] onIncomingData
>> matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>> 1422920250.923315 DEBUG: [Strategy] beforeSatisfyPendingInterest
>> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>> inFace=264
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
>>
>>  NFD3 (producer):
>>
> 1422920296.818710 DEBUG: [Forwarder] onIncomingInterest face=268
>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>> 1422920296.819102 DEBUG: [Forwarder] onOutgoingInterest face=265
>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>> 1422920296.819408 DEBUG: [BestRouteStrategy2]
>> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=*2128078661
>> <2128078661>* from=268 newPitEntry-to=265
>> ^ 0 sec, *551.408 msec **// data*
>> 1422920297.370816 DEBUG: [Forwarder] onIncomingData face=265
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
>> 1422920297.371248 DEBUG: [Forwarder] onIncomingData
>> matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>> 1422920297.371547 DEBUG: [Strategy] beforeSatisfyPendingInterest
>> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>> inFace=265
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
>> 1422920297.372106 DEBUG: [Forwarder] onOutgoingData face=268
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
>>
> ^ 0 sec, 184.298 msec*// retransmission*
>>
> 1422920297.556404 DEBUG: [Forwarder] onIncomingInterest face=268
>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>> 1422920297.557030 DEBUG: [Forwarder] onOutgoingData face=268
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
>>
>>  *Case #2*
>>
>>  *NFD1 (consumer):*
>>  1422919936.433502DEBUG: [Forwarder] onIncomingInterest face=261
>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00
>>
> 1422919936.434221 DEBUG: [BestRouteStrategy2]
>> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=
>> 3853552983 from=261 newPitEntry-to=259
>> ^ 0 sec, *402.119 msec*
>> 1422919936.836340 DEBUG: [Forwarder] onIncomingData face=259
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0
>> 1422919936.836649 DEBUG: [Forwarder] onIncomingData
>> matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00
>> 1422919936.836871 DEBUG: [Strategy] beforeSatisfyPendingInterest
>> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00
>> inFace=259
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0
>> 1422919936.837279 DEBUG: [Forwarder] onOutgoingData face=261
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0
>>
>
>>
>>  *NFD2 (hub):*
>>  1422919886.178188DEBUG: [Forwarder] onIncomingInterest face=266
>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00
>>
> 1422919886.179368 DEBUG: [BestRouteStrategy2]
>> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=3791853569
>> from=266 newPitEntry-to=264
>> ^ 0 sec, *89.772 msec*
>> 1422919886.269140 DEBUG: [Forwarder] onIncomingData face=264
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00/1/4252/150/0
>> 1422919886.269671 DEBUG: [Forwarder] onIncomingData
>> matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00
>> 1422919886.270079 DEBUG: [Strategy] beforeSatisfyPendingInterest
>> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00
>> inFace=264
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00/1/4252/150/0
>> 1422919886.270718 DEBUG: [Forwarder] onOutgoingData face=266
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00/1/4252/150/0
>>
>
>>
>>  *NFD3 (producer):*
>>  1422919932.865989DEBUG: [Forwarder] onIncomingInterest face=268
>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00
>>
> 1422919932.866855 DEBUG: [BestRouteStrategy2]
>> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=
>> 3853552983 from=268 newPitEntry-to=265
>> ^ 0 sec, *90.492 msec*
>> 1422919932.957347 DEBUG: [Forwarder] onIncomingData face=265
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0
>> 1422919932.958010 DEBUG: [Forwarder] onIncomingData
>> matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00
>> 1422919932.958342 DEBUG: [Strategy] beforeSatisfyPendingInterest
>> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00
>> inFace=265
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0
>> 1422919932.958955 DEBUG: [Forwarder] onOutgoingData face=268
>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0
>>
>
>>
>>  Can these be cases of congestions on such wideband setup?
>>
>>    Thanks,
>>
>>  --
>> Peter Gusev
>>  Programmer/Analyst @ REMAP, UCLA
>>
>> peter at remap.ucla.edu
>> +1 213 5872748
>> peetonn_ (skype)
>>
> _______________________________________________
> 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/20150204/02cb79f2/attachment.html>

From luca.muscariello at orange.com  Thu Feb  5 02:06:36 2015
From: luca.muscariello at orange.com (MUSCARIELLO Luca IMT/OLN)
Date: Thu, 5 Feb 2015 11:06:36 +0100
Subject: [Nfd-dev] lurch 0.1.0 for ndn and related tools
Message-ID: <54D340AC.1000702@orange.com>

Dear all,

We are please to announce the first release of some tools that might be 
useful to
people doing experimental research with NDN.
We have successfully used this tool to run large NDN experiments in a 
large grid
(www.grid5000.fr) but this is also useful to test smaller experiments in 
a local
cluster of servers.

The release and related documentation can be found on the following website:
http://systemx.enst.fr/lurch

Lurch is an NDN experimental test orchestrator including
- virtual IP topology configuration  and management;
- NDN network configuration and management;
- workload configuration and management;
- test log retrieval.

Lurch is available in two versions:
1)  for unmodified NFD and ndn-cxx packages version 0.2.0, requiring  
the installation of
"ndn-virtual-repo" and "ndn-icp-download" as additional packages.

2)  lurch-custom-0.1.0 works with a modified version of  NFD and ndn-cxx 
packages,
NDN-0.2.0-custom, available here 
http://systemx.enst.fr/archives/NDN-0.2.0-custom.tgz
and provides:
         - LRU cache replacement policy;
         - interest control rate at the client based on optimized 
multipath and adaptive
           remote AQM as described in [1]
         - congestion aware forwarding strategy as described in [1]

- The virtual repo is inspired by the delphi implementation for CCNx 
0.x.x  by WashU
and is available here: http://systemx.enst.fr/archives/ndn-virtual-repo.tgz

- The Interest control protocol is an implementation for NDN of the 
protocol described in [1]
and is available here: http://systemx.enst.fr/archives/ndn-icp-download.tgz


Luca Muscariello
Massimo Gallo


[1] Carofiglio, et al. "Optimal multipath congestion control and request 
forwarding in Information-Centric Networks," IEEE ICNP 2013 
http://dx.doi.org/10.1109/ICNP.2013.6733576



-- 
Orange Labs Networks
Luca Muscariello - IMT/NMP/TRM
38 - 40, rue du General Leclerc
92794 Issy Les Moulineaux Cedex 9 - France
Tel : +33 (0)1 45 29 60 37
http://perso.rd.francetelecom.fr/muscariello
http://systemx.enst.fr/

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

From davide.pesavento at lip6.fr  Thu Feb  5 22:22:27 2015
From: davide.pesavento at lip6.fr (Davide Pesavento)
Date: Thu, 5 Feb 2015 22:22:27 -0800
Subject: [Nfd-dev] NDN-RTC: NFD processing logs
In-Reply-To: <CADfzvvZZK-Qp1oE9hjpnNzzmQgW3U=hevNYKg1MPLhZBCgF-hA@mail.gmail.com>
References: <CAOFH+OZ8A7MisNk1z=aOdcPaHXd99g83VUvN6+Za=cZA8XOQwg@mail.gmail.com>
	<D0F6F48F.1B3622%jburke@remap.ucla.edu>
	<CADfzvvZZK-Qp1oE9hjpnNzzmQgW3U=hevNYKg1MPLhZBCgF-hA@mail.gmail.com>
Message-ID: <CADfzvva3KdGqx+4oKRQvShiZ0+DQfp6PQqa0-0-qaSRWi+o5hg@mail.gmail.com>

Peter,

I just checked the code. DatagramFace does not contain a logger
instance, therefore the name of the component you need to enable is
"UdpFace", at the TRACE level. Sorry for the confusion.

To avoid this kind of problems in the future, you can additionally
enable "LoggerFactory" at the DEBUG level. (We should change that to a
warning by the way)

Best,
Davide

On Wed, Feb 4, 2015 at 12:14 AM, Davide Pesavento <davidepesa at gmail.com> wrote:
> Hi Jeff,
>
> Regarding your last question, if you enable the TRACE log level in NFD
> configuration file you should get additional logging when the face receives
> or sends anything over the wire. You should see something like:
>
> TRACE: [UdpFace] [id:42,...] Received X bytes
> or
> TRACE: [UdpFace] [id:42,...] Sent X bytes
>
> If my memory serves me well, those are respectively the first and last
> messages printed by NFD.
>
> Best,
> Davide
>
>
> On Wed, Feb 4, 2015, 7:01 AM Burke, Jeff <jburke at remap.ucla.edu> wrote:
>>
>> Junxiao,
>>
>> The application is intended to work over the current internet with low
>> risk of IP fragmentation, so we are designing the packet sizes for MTUs of
>> 1500 octets.
>>
>> Peter, can you run NTP in a peer-to-peer configuration to lower the clock
>> offset between the vious machines and make it easier to troubleshoot just
>> based on the logging?  I can give you a configuration tomorrow.
>>
>> Junxiao, in addition to tcpdump, is there anything that logs at a lower
>> layer in NFD which we could use to see when interest/data bits first come in
>> over the wire?
>>
>> We will bring the whole setup to the ndn retreat...
>>
>> Jeff
>>
>>
>> From: Junxiao Shi <shijunxiao at email.arizona.edu>
>> Date: Tue, 3 Feb 2015 22:50:35 -0700
>> To: "Gusev, Peter" <peter at remap.ucla.edu>
>> Cc: Jeff Burke <jburke at remap.ucla.edu>, "nfd-dev at lists.cs.ucla.edu"
>> <nfd-dev at lists.cs.ucla.edu>
>>
>> Subject: Re: [Nfd-dev] NDN-RTC: NFD processing logs
>>
>> Hi Peter
>>
>> I forgot to ask earlier: what's the MTU of the NICs?
>> Make sure the MTU is 9000 octets or higher, otherwise IP fragmentation
>> will severely affect performance.
>>
>>
>> Congestion is unlikely to happen with 200Kbps traffic on 1000Mbps link.
>> CPU is also unlikely to be a bottleneck for 60 Interests/s.
>>
>> Use `tcpdump` to see exactly when the packet is transmitted onto the
>> network, in order to determine whether the delay is happening on sender host
>> or receiver host.
>> Running `tcpdump` on the host itself will affect its performance. If an
>> impact is evident, you could setup port mirroring on the switch, and run
>> `tcpdump` on another machine that is connected to the mirrored port.
>>
>> Yours, Junxiao
>>
>> On Tue, Feb 3, 2015 at 12:56 PM, Gusev, Peter <peter at remap.ucla.edu>
>> wrote:
>>>
>>> Hi Junxiao,
>>>
>>> I run tests with all three (consumer, producer and hub) connected to the
>>> same 1Gbit switch. For the app configuration I tested - bitrate is
>>> ~150-200kbit/s, interest rate is about 50-60.
>>>
>>> And discovered these cases:
>>>
>>> Case #1
>>>
>>> NFD1 (consumer):
>>>
>>> 1422920300.410412DEBUG: [Forwarder] onIncomingInterest face=261
>>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>>>
>>> 1422920300.410804 DEBUG: [Forwarder] onOutgoingInterest face=259
>>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>>> 1422920300.411138 DEBUG: [BestRouteStrategy2]
>>> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=2128078661
>>> from=261 newPitEntry-to=259
>>> ^ 0 sec, 440 msec // retransmission
>>> 1422920300.851526 DEBUG: [Forwarder] onIncomingInterest face=261
>>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>>> 1422920300.851843 DEBUG: [Forwarder] onOutgoingInterest face=259
>>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>>> 1422920300.852127 DEBUG: [BestRouteStrategy2]
>>> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=2749769734
>>> from=261 retransmit-retry-to=259
>>> ^ 0 sec, 302 msec // data
>>> 1422920301.155108 DEBUG: [Forwarder] onIncomingData face=259
>>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
>>> 1422920301.155452 DEBUG: [Forwarder] onIncomingData
>>> matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>>> 1422920301.155680 DEBUG: [Strategy] beforeSatisfyPendingInterest
>>> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>>> inFace=259
>>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
>>> 1422920301.156152 DEBUG: [Forwarder] onOutgoingData face=261
>>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
>>>
>>>
>>> NFD2 (hub):
>>> 1422920250.169018DEBUG: [Forwarder] onIncomingInterest face=266
>>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>>>
>>> 1422920250.169560 DEBUG: [Forwarder] onOutgoingInterest face=264
>>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>>> 1422920250.169959 DEBUG: [BestRouteStrategy2]
>>> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=2128078661
>>> from=266 newPitEntry-to=264
>>> ^ 0 sec, 736.911 msec // retransmission
>>> 1422920250.906870 DEBUG: [Forwarder] onIncomingInterest face=266
>>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>>> 1422920250.907384 DEBUG: [Forwarder] onOutgoingInterest face=264
>>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>>> 1422920250.907801 DEBUG: [BestRouteStrategy2]
>>> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=2749769734
>>> from=266 retransmit-retry-to=264
>>> ^ 0 sec, 2.541 msec // data
>>> 1422920250.910342 DEBUG: [Forwarder] onIncomingData face=264
>>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
>>> 1422920250.910812 DEBUG: [Forwarder] onIncomingData
>>> matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>>> 1422920250.911125 DEBUG: [Strategy] beforeSatisfyPendingInterest
>>> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>>> inFace=264
>>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
>>> 1422920250.911706 DEBUG: [Forwarder] onOutgoingData face=266
>>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
>>> 1422920250.922749 DEBUG: [Forwarder] onIncomingData face=264
>>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
>>> 1422920250.923068 DEBUG: [Forwarder] onIncomingData
>>> matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>>> 1422920250.923315 DEBUG: [Strategy] beforeSatisfyPendingInterest
>>> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>>> inFace=264
>>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
>>>
>>> NFD3 (producer):
>>>
>>> 1422920296.818710 DEBUG: [Forwarder] onIncomingInterest face=268
>>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>>> 1422920296.819102 DEBUG: [Forwarder] onOutgoingInterest face=265
>>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>>> 1422920296.819408 DEBUG: [BestRouteStrategy2]
>>> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=2128078661
>>> from=268 newPitEntry-to=265
>>> ^ 0 sec, 551.408 msec // data
>>> 1422920297.370816 DEBUG: [Forwarder] onIncomingData face=265
>>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
>>> 1422920297.371248 DEBUG: [Forwarder] onIncomingData
>>> matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>>> 1422920297.371547 DEBUG: [Strategy] beforeSatisfyPendingInterest
>>> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>>> inFace=265
>>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
>>> 1422920297.372106 DEBUG: [Forwarder] onOutgoingData face=268
>>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
>>>
>>> ^ 0 sec, 184.298 msec// retransmission
>>>
>>> 1422920297.556404 DEBUG: [Forwarder] onIncomingInterest face=268
>>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>>> 1422920297.557030 DEBUG: [Forwarder] onOutgoingData face=268
>>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
>>>
>>> Case #2
>>>
>>> NFD1 (consumer):
>>> 1422919936.433502DEBUG: [Forwarder] onIncomingInterest face=261
>>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00
>>>
>>> 1422919936.434221 DEBUG: [BestRouteStrategy2]
>>> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=3853552983
>>> from=261 newPitEntry-to=259
>>> ^ 0 sec, 402.119 msec
>>> 1422919936.836340 DEBUG: [Forwarder] onIncomingData face=259
>>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0
>>> 1422919936.836649 DEBUG: [Forwarder] onIncomingData
>>> matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00
>>> 1422919936.836871 DEBUG: [Strategy] beforeSatisfyPendingInterest
>>> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00
>>> inFace=259
>>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0
>>> 1422919936.837279 DEBUG: [Forwarder] onOutgoingData face=261
>>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0
>>>
>>>
>>>
>>> NFD2 (hub):
>>> 1422919886.178188DEBUG: [Forwarder] onIncomingInterest face=266
>>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00
>>>
>>> 1422919886.179368 DEBUG: [BestRouteStrategy2]
>>> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=3791853569
>>> from=266 newPitEntry-to=264
>>> ^ 0 sec, 89.772 msec
>>> 1422919886.269140 DEBUG: [Forwarder] onIncomingData face=264
>>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00/1/4252/150/0
>>> 1422919886.269671 DEBUG: [Forwarder] onIncomingData
>>> matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00
>>> 1422919886.270079 DEBUG: [Strategy] beforeSatisfyPendingInterest
>>> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00
>>> inFace=264
>>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00/1/4252/150/0
>>> 1422919886.270718 DEBUG: [Forwarder] onOutgoingData face=266
>>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00/1/4252/150/0
>>>
>>>
>>>
>>> NFD3 (producer):
>>> 1422919932.865989DEBUG: [Forwarder] onIncomingInterest face=268
>>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00
>>>
>>> 1422919932.866855 DEBUG: [BestRouteStrategy2]
>>> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=3853552983
>>> from=268 newPitEntry-to=265
>>> ^ 0 sec, 90.492 msec
>>> 1422919932.957347 DEBUG: [Forwarder] onIncomingData face=265
>>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0
>>> 1422919932.958010 DEBUG: [Forwarder] onIncomingData
>>> matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00
>>> 1422919932.958342 DEBUG: [Strategy] beforeSatisfyPendingInterest
>>> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00
>>> inFace=265
>>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0
>>> 1422919932.958955 DEBUG: [Forwarder] onOutgoingData face=268
>>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0
>>>
>>>
>>>
>>> Can these be cases of congestions on such wideband setup?
>>>
>>> Thanks,
>>>
>>> --
>>> Peter Gusev
>>> Programmer/Analyst @ REMAP, UCLA
>>>
>>> peter at remap.ucla.edu
>>> +1 213 5872748
>>> peetonn_ (skype)
>>
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev


From peter at remap.ucla.edu  Fri Feb  6 08:03:17 2015
From: peter at remap.ucla.edu (Gusev, Peter)
Date: Fri, 6 Feb 2015 16:03:17 +0000
Subject: [Nfd-dev] NDN-RTC: NFD processing logs
In-Reply-To: <CADfzvva3KdGqx+4oKRQvShiZ0+DQfp6PQqa0-0-qaSRWi+o5hg@mail.gmail.com>
References: <CAOFH+OZ8A7MisNk1z=aOdcPaHXd99g83VUvN6+Za=cZA8XOQwg@mail.gmail.com>
	<D0F6F48F.1B3622%jburke@remap.ucla.edu>
	<CADfzvvZZK-Qp1oE9hjpnNzzmQgW3U=hevNYKg1MPLhZBCgF-hA@mail.gmail.com>
	<CADfzvva3KdGqx+4oKRQvShiZ0+DQfp6PQqa0-0-qaSRWi+o5hg@mail.gmail.com>
Message-ID: <E716A2CA-D2FA-487F-A4FF-494D5910C2BB@remap.ucla.edu>

Ok, thanks Davide!
I?ll try this out

Thanks, 

-- 
Peter Gusev
Programmer/Analyst @ REMAP, UCLA

peter at remap.ucla.edu
+1 213 5872748
peetonn_ (skype)

> On Feb 5, 2015, at 10:22 PM, Davide Pesavento <davide.pesavento at lip6.fr> wrote:
> 
> Peter,
> 
> I just checked the code. DatagramFace does not contain a logger
> instance, therefore the name of the component you need to enable is
> "UdpFace", at the TRACE level. Sorry for the confusion.
> 
> To avoid this kind of problems in the future, you can additionally
> enable "LoggerFactory" at the DEBUG level. (We should change that to a
> warning by the way)
> 
> Best,
> Davide
> 
> On Wed, Feb 4, 2015 at 12:14 AM, Davide Pesavento <davidepesa at gmail.com> wrote:
>> Hi Jeff,
>> 
>> Regarding your last question, if you enable the TRACE log level in NFD
>> configuration file you should get additional logging when the face receives
>> or sends anything over the wire. You should see something like:
>> 
>> TRACE: [UdpFace] [id:42,...] Received X bytes
>> or
>> TRACE: [UdpFace] [id:42,...] Sent X bytes
>> 
>> If my memory serves me well, those are respectively the first and last
>> messages printed by NFD.
>> 
>> Best,
>> Davide
>> 
>> 
>> On Wed, Feb 4, 2015, 7:01 AM Burke, Jeff <jburke at remap.ucla.edu> wrote:
>>> 
>>> Junxiao,
>>> 
>>> The application is intended to work over the current internet with low
>>> risk of IP fragmentation, so we are designing the packet sizes for MTUs of
>>> 1500 octets.
>>> 
>>> Peter, can you run NTP in a peer-to-peer configuration to lower the clock
>>> offset between the vious machines and make it easier to troubleshoot just
>>> based on the logging?  I can give you a configuration tomorrow.
>>> 
>>> Junxiao, in addition to tcpdump, is there anything that logs at a lower
>>> layer in NFD which we could use to see when interest/data bits first come in
>>> over the wire?
>>> 
>>> We will bring the whole setup to the ndn retreat...
>>> 
>>> Jeff
>>> 
>>> 
>>> From: Junxiao Shi <shijunxiao at email.arizona.edu>
>>> Date: Tue, 3 Feb 2015 22:50:35 -0700
>>> To: "Gusev, Peter" <peter at remap.ucla.edu>
>>> Cc: Jeff Burke <jburke at remap.ucla.edu>, "nfd-dev at lists.cs.ucla.edu"
>>> <nfd-dev at lists.cs.ucla.edu>
>>> 
>>> Subject: Re: [Nfd-dev] NDN-RTC: NFD processing logs
>>> 
>>> Hi Peter
>>> 
>>> I forgot to ask earlier: what's the MTU of the NICs?
>>> Make sure the MTU is 9000 octets or higher, otherwise IP fragmentation
>>> will severely affect performance.
>>> 
>>> 
>>> Congestion is unlikely to happen with 200Kbps traffic on 1000Mbps link.
>>> CPU is also unlikely to be a bottleneck for 60 Interests/s.
>>> 
>>> Use `tcpdump` to see exactly when the packet is transmitted onto the
>>> network, in order to determine whether the delay is happening on sender host
>>> or receiver host.
>>> Running `tcpdump` on the host itself will affect its performance. If an
>>> impact is evident, you could setup port mirroring on the switch, and run
>>> `tcpdump` on another machine that is connected to the mirrored port.
>>> 
>>> Yours, Junxiao
>>> 
>>> On Tue, Feb 3, 2015 at 12:56 PM, Gusev, Peter <peter at remap.ucla.edu>
>>> wrote:
>>>> 
>>>> Hi Junxiao,
>>>> 
>>>> I run tests with all three (consumer, producer and hub) connected to the
>>>> same 1Gbit switch. For the app configuration I tested - bitrate is
>>>> ~150-200kbit/s, interest rate is about 50-60.
>>>> 
>>>> And discovered these cases:
>>>> 
>>>> Case #1
>>>> 
>>>> NFD1 (consumer):
>>>> 
>>>> 1422920300.410412DEBUG: [Forwarder] onIncomingInterest face=261
>>>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>>>> 
>>>> 1422920300.410804 DEBUG: [Forwarder] onOutgoingInterest face=259
>>>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>>>> 1422920300.411138 DEBUG: [BestRouteStrategy2]
>>>> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=2128078661
>>>> from=261 newPitEntry-to=259
>>>> ^ 0 sec, 440 msec // retransmission
>>>> 1422920300.851526 DEBUG: [Forwarder] onIncomingInterest face=261
>>>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>>>> 1422920300.851843 DEBUG: [Forwarder] onOutgoingInterest face=259
>>>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>>>> 1422920300.852127 DEBUG: [BestRouteStrategy2]
>>>> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=2749769734
>>>> from=261 retransmit-retry-to=259
>>>> ^ 0 sec, 302 msec // data
>>>> 1422920301.155108 DEBUG: [Forwarder] onIncomingData face=259
>>>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
>>>> 1422920301.155452 DEBUG: [Forwarder] onIncomingData
>>>> matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>>>> 1422920301.155680 DEBUG: [Strategy] beforeSatisfyPendingInterest
>>>> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>>>> inFace=259
>>>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
>>>> 1422920301.156152 DEBUG: [Forwarder] onOutgoingData face=261
>>>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
>>>> 
>>>> 
>>>> NFD2 (hub):
>>>> 1422920250.169018DEBUG: [Forwarder] onIncomingInterest face=266
>>>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>>>> 
>>>> 1422920250.169560 DEBUG: [Forwarder] onOutgoingInterest face=264
>>>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>>>> 1422920250.169959 DEBUG: [BestRouteStrategy2]
>>>> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=2128078661
>>>> from=266 newPitEntry-to=264
>>>> ^ 0 sec, 736.911 msec // retransmission
>>>> 1422920250.906870 DEBUG: [Forwarder] onIncomingInterest face=266
>>>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>>>> 1422920250.907384 DEBUG: [Forwarder] onOutgoingInterest face=264
>>>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>>>> 1422920250.907801 DEBUG: [BestRouteStrategy2]
>>>> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=2749769734
>>>> from=266 retransmit-retry-to=264
>>>> ^ 0 sec, 2.541 msec // data
>>>> 1422920250.910342 DEBUG: [Forwarder] onIncomingData face=264
>>>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
>>>> 1422920250.910812 DEBUG: [Forwarder] onIncomingData
>>>> matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>>>> 1422920250.911125 DEBUG: [Strategy] beforeSatisfyPendingInterest
>>>> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>>>> inFace=264
>>>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
>>>> 1422920250.911706 DEBUG: [Forwarder] onOutgoingData face=266
>>>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
>>>> 1422920250.922749 DEBUG: [Forwarder] onIncomingData face=264
>>>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
>>>> 1422920250.923068 DEBUG: [Forwarder] onIncomingData
>>>> matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>>>> 1422920250.923315 DEBUG: [Strategy] beforeSatisfyPendingInterest
>>>> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>>>> inFace=264
>>>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
>>>> 
>>>> NFD3 (producer):
>>>> 
>>>> 1422920296.818710 DEBUG: [Forwarder] onIncomingInterest face=268
>>>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>>>> 1422920296.819102 DEBUG: [Forwarder] onOutgoingInterest face=265
>>>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>>>> 1422920296.819408 DEBUG: [BestRouteStrategy2]
>>>> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=2128078661
>>>> from=268 newPitEntry-to=265
>>>> ^ 0 sec, 551.408 msec // data
>>>> 1422920297.370816 DEBUG: [Forwarder] onIncomingData face=265
>>>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
>>>> 1422920297.371248 DEBUG: [Forwarder] onIncomingData
>>>> matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>>>> 1422920297.371547 DEBUG: [Strategy] beforeSatisfyPendingInterest
>>>> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>>>> inFace=265
>>>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
>>>> 1422920297.372106 DEBUG: [Forwarder] onOutgoingData face=268
>>>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
>>>> 
>>>> ^ 0 sec, 184.298 msec// retransmission
>>>> 
>>>> 1422920297.556404 DEBUG: [Forwarder] onIncomingInterest face=268
>>>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
>>>> 1422920297.557030 DEBUG: [Forwarder] onOutgoingData face=268
>>>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
>>>> 
>>>> Case #2
>>>> 
>>>> NFD1 (consumer):
>>>> 1422919936.433502DEBUG: [Forwarder] onIncomingInterest face=261
>>>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00
>>>> 
>>>> 1422919936.434221 DEBUG: [BestRouteStrategy2]
>>>> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=3853552983
>>>> from=261 newPitEntry-to=259
>>>> ^ 0 sec, 402.119 msec
>>>> 1422919936.836340 DEBUG: [Forwarder] onIncomingData face=259
>>>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0
>>>> 1422919936.836649 DEBUG: [Forwarder] onIncomingData
>>>> matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00
>>>> 1422919936.836871 DEBUG: [Strategy] beforeSatisfyPendingInterest
>>>> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00
>>>> inFace=259
>>>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0
>>>> 1422919936.837279 DEBUG: [Forwarder] onOutgoingData face=261
>>>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0
>>>> 
>>>> 
>>>> 
>>>> NFD2 (hub):
>>>> 1422919886.178188DEBUG: [Forwarder] onIncomingInterest face=266
>>>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00
>>>> 
>>>> 1422919886.179368 DEBUG: [BestRouteStrategy2]
>>>> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=3791853569
>>>> from=266 newPitEntry-to=264
>>>> ^ 0 sec, 89.772 msec
>>>> 1422919886.269140 DEBUG: [Forwarder] onIncomingData face=264
>>>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00/1/4252/150/0
>>>> 1422919886.269671 DEBUG: [Forwarder] onIncomingData
>>>> matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00
>>>> 1422919886.270079 DEBUG: [Strategy] beforeSatisfyPendingInterest
>>>> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00
>>>> inFace=264
>>>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00/1/4252/150/0
>>>> 1422919886.270718 DEBUG: [Forwarder] onOutgoingData face=266
>>>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00/1/4252/150/0
>>>> 
>>>> 
>>>> 
>>>> NFD3 (producer):
>>>> 1422919932.865989DEBUG: [Forwarder] onIncomingInterest face=268
>>>> interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00
>>>> 
>>>> 1422919932.866855 DEBUG: [BestRouteStrategy2]
>>>> /ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=3853552983
>>>> from=268 newPitEntry-to=265
>>>> ^ 0 sec, 90.492 msec
>>>> 1422919932.957347 DEBUG: [Forwarder] onIncomingData face=265
>>>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0
>>>> 1422919932.958010 DEBUG: [Forwarder] onIncomingData
>>>> matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00
>>>> 1422919932.958342 DEBUG: [Strategy] beforeSatisfyPendingInterest
>>>> pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00
>>>> inFace=265
>>>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0
>>>> 1422919932.958955 DEBUG: [Forwarder] onOutgoingData face=268
>>>> data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0
>>>> 
>>>> 
>>>> 
>>>> Can these be cases of congestions on such wideband setup?
>>>> 
>>>> Thanks,
>>>> 
>>>> --
>>>> Peter Gusev
>>>> Programmer/Analyst @ REMAP, UCLA
>>>> 
>>>> peter at remap.ucla.edu
>>>> +1 213 5872748
>>>> peetonn_ (skype)
>>> 
>>> _______________________________________________
>>> Nfd-dev mailing list
>>> Nfd-dev at lists.cs.ucla.edu
>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev




From peter at remap.UCLA.EDU  Fri Feb  6 15:14:28 2015
From: peter at remap.UCLA.EDU (Gusev, Peter)
Date: Fri, 6 Feb 2015 23:14:28 +0000
Subject: [Nfd-dev] NDN-RTC: NFD processing logs
In-Reply-To: <E716A2CA-D2FA-487F-A4FF-494D5910C2BB@remap.ucla.edu>
References: <CAOFH+OZ8A7MisNk1z=aOdcPaHXd99g83VUvN6+Za=cZA8XOQwg@mail.gmail.com>
	<D0F6F48F.1B3622%jburke@remap.ucla.edu>
	<CADfzvvZZK-Qp1oE9hjpnNzzmQgW3U=hevNYKg1MPLhZBCgF-hA@mail.gmail.com>
	<CADfzvva3KdGqx+4oKRQvShiZ0+DQfp6PQqa0-0-qaSRWi+o5hg@mail.gmail.com>
	<E716A2CA-D2FA-487F-A4FF-494D5910C2BB@remap.ucla.edu>
Message-ID: <D697BEB1-D27B-4829-A8B3-61C609BD0ACF@remap.ucla.edu>

Hi guys,

So I?ve run setup today and gathered logs.
I?ve setup NFDs with the following settings
...
 default_level NONE
 Forwarder DEBUG
 UdpFace TRACE
?

And then I run tcpdump on each machine like this:
$ sudo tcpdump -w ~/dump.pcap -i en4 udp port 6363

Here is the summary on ?problematic? packets:
https://docs.google.com/document/d/11JAPHI6J4jD6mibMRuWd1EvzP-NY_F2osM2vDF2VaGM/edit?usp=sharing

All the log files and tcpdumps you can find here:
https://www.dropbox.com/s/1d277xbhqs97o66/logs.zip?dl=0

Thanks for all the help!

Thanks,

--
Peter Gusev
Programmer/Analyst @ REMAP, UCLA

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

On Feb 6, 2015, at 8:03 AM, Gusev, Peter <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>> wrote:

Ok, thanks Davide!
I?ll try this out

Thanks,

--
Peter Gusev
Programmer/Analyst @ REMAP, UCLA

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

On Feb 5, 2015, at 10:22 PM, Davide Pesavento <davide.pesavento at lip6.fr> wrote:

Peter,

I just checked the code. DatagramFace does not contain a logger
instance, therefore the name of the component you need to enable is
"UdpFace", at the TRACE level. Sorry for the confusion.

To avoid this kind of problems in the future, you can additionally
enable "LoggerFactory" at the DEBUG level. (We should change that to a
warning by the way)

Best,
Davide

On Wed, Feb 4, 2015 at 12:14 AM, Davide Pesavento <davidepesa at gmail.com> wrote:
Hi Jeff,

Regarding your last question, if you enable the TRACE log level in NFD
configuration file you should get additional logging when the face receives
or sends anything over the wire. You should see something like:

TRACE: [UdpFace] [id:42,...] Received X bytes
or
TRACE: [UdpFace] [id:42,...] Sent X bytes

If my memory serves me well, those are respectively the first and last
messages printed by NFD.

Best,
Davide


On Wed, Feb 4, 2015, 7:01 AM Burke, Jeff <jburke at remap.ucla.edu> wrote:

Junxiao,

The application is intended to work over the current internet with low
risk of IP fragmentation, so we are designing the packet sizes for MTUs of
1500 octets.

Peter, can you run NTP in a peer-to-peer configuration to lower the clock
offset between the vious machines and make it easier to troubleshoot just
based on the logging?  I can give you a configuration tomorrow.

Junxiao, in addition to tcpdump, is there anything that logs at a lower
layer in NFD which we could use to see when interest/data bits first come in
over the wire?

We will bring the whole setup to the ndn retreat...

Jeff


From: Junxiao Shi <shijunxiao at email.arizona.edu>
Date: Tue, 3 Feb 2015 22:50:35 -0700
To: "Gusev, Peter" <peter at remap.ucla.edu>
Cc: Jeff Burke <jburke at remap.ucla.edu>, "nfd-dev at lists.cs.ucla.edu"
<nfd-dev at lists.cs.ucla.edu>

Subject: Re: [Nfd-dev] NDN-RTC: NFD processing logs

Hi Peter

I forgot to ask earlier: what's the MTU of the NICs?
Make sure the MTU is 9000 octets or higher, otherwise IP fragmentation
will severely affect performance.


Congestion is unlikely to happen with 200Kbps traffic on 1000Mbps link.
CPU is also unlikely to be a bottleneck for 60 Interests/s.

Use `tcpdump` to see exactly when the packet is transmitted onto the
network, in order to determine whether the delay is happening on sender host
or receiver host.
Running `tcpdump` on the host itself will affect its performance. If an
impact is evident, you could setup port mirroring on the switch, and run
`tcpdump` on another machine that is connected to the mirrored port.

Yours, Junxiao

On Tue, Feb 3, 2015 at 12:56 PM, Gusev, Peter <peter at remap.ucla.edu>
wrote:

Hi Junxiao,

I run tests with all three (consumer, producer and hub) connected to the
same 1Gbit switch. For the app configuration I tested - bitrate is
~150-200kbit/s, interest rate is about 50-60.

And discovered these cases:

Case #1

NFD1 (consumer):

1422920300.410412DEBUG: [Forwarder] onIncomingInterest face=261
interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00

1422920300.410804 DEBUG: [Forwarder] onOutgoingInterest face=259
interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920300.411138 DEBUG: [BestRouteStrategy2]
/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=2128078661
from=261 newPitEntry-to=259
^ 0 sec, 440 msec // retransmission
1422920300.851526 DEBUG: [Forwarder] onIncomingInterest face=261
interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920300.851843 DEBUG: [Forwarder] onOutgoingInterest face=259
interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920300.852127 DEBUG: [BestRouteStrategy2]
/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=2749769734
from=261 retransmit-retry-to=259
^ 0 sec, 302 msec // data
1422920301.155108 DEBUG: [Forwarder] onIncomingData face=259
data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
1422920301.155452 DEBUG: [Forwarder] onIncomingData
matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920301.155680 DEBUG: [Strategy] beforeSatisfyPendingInterest
pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
inFace=259
data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
1422920301.156152 DEBUG: [Forwarder] onOutgoingData face=261
data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0


NFD2 (hub):
1422920250.169018DEBUG: [Forwarder] onIncomingInterest face=266
interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00

1422920250.169560 DEBUG: [Forwarder] onOutgoingInterest face=264
interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920250.169959 DEBUG: [BestRouteStrategy2]
/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=2128078661
from=266 newPitEntry-to=264
^ 0 sec, 736.911 msec // retransmission
1422920250.906870 DEBUG: [Forwarder] onIncomingInterest face=266
interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920250.907384 DEBUG: [Forwarder] onOutgoingInterest face=264
interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920250.907801 DEBUG: [BestRouteStrategy2]
/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=2749769734
from=266 retransmit-retry-to=264
^ 0 sec, 2.541 msec // data
1422920250.910342 DEBUG: [Forwarder] onIncomingData face=264
data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
1422920250.910812 DEBUG: [Forwarder] onIncomingData
matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920250.911125 DEBUG: [Strategy] beforeSatisfyPendingInterest
pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
inFace=264
data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
1422920250.911706 DEBUG: [Forwarder] onOutgoingData face=266
data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
1422920250.922749 DEBUG: [Forwarder] onIncomingData face=264
data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
1422920250.923068 DEBUG: [Forwarder] onIncomingData
matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920250.923315 DEBUG: [Strategy] beforeSatisfyPendingInterest
pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
inFace=264
data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0

NFD3 (producer):

1422920296.818710 DEBUG: [Forwarder] onIncomingInterest face=268
interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920296.819102 DEBUG: [Forwarder] onOutgoingInterest face=265
interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920296.819408 DEBUG: [BestRouteStrategy2]
/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=2128078661
from=268 newPitEntry-to=265
^ 0 sec, 551.408 msec // data
1422920297.370816 DEBUG: [Forwarder] onIncomingData face=265
data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
1422920297.371248 DEBUG: [Forwarder] onIncomingData
matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920297.371547 DEBUG: [Strategy] beforeSatisfyPendingInterest
pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
inFace=265
data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
1422920297.372106 DEBUG: [Forwarder] onOutgoingData face=268
data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0

^ 0 sec, 184.298 msec// retransmission

1422920297.556404 DEBUG: [Forwarder] onIncomingInterest face=268
interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920297.557030 DEBUG: [Forwarder] onOutgoingData face=268
data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0

Case #2

NFD1 (consumer):
1422919936.433502DEBUG: [Forwarder] onIncomingInterest face=261
interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00

1422919936.434221 DEBUG: [BestRouteStrategy2]
/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=3853552983
from=261 newPitEntry-to=259
^ 0 sec, 402.119 msec
1422919936.836340 DEBUG: [Forwarder] onIncomingData face=259
data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0
1422919936.836649 DEBUG: [Forwarder] onIncomingData
matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00
1422919936.836871 DEBUG: [Strategy] beforeSatisfyPendingInterest
pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00
inFace=259
data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0
1422919936.837279 DEBUG: [Forwarder] onOutgoingData face=261
data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0



NFD2 (hub):
1422919886.178188DEBUG: [Forwarder] onIncomingInterest face=266
interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00

1422919886.179368 DEBUG: [BestRouteStrategy2]
/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=3791853569
from=266 newPitEntry-to=264
^ 0 sec, 89.772 msec
1422919886.269140 DEBUG: [Forwarder] onIncomingData face=264
data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00/1/4252/150/0
1422919886.269671 DEBUG: [Forwarder] onIncomingData
matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00
1422919886.270079 DEBUG: [Strategy] beforeSatisfyPendingInterest
pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00
inFace=264
data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00/1/4252/150/0
1422919886.270718 DEBUG: [Forwarder] onOutgoingData face=266
data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00/1/4252/150/0



NFD3 (producer):
1422919932.865989DEBUG: [Forwarder] onIncomingInterest face=268
interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00

1422919932.866855 DEBUG: [BestRouteStrategy2]
/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=3853552983
from=268 newPitEntry-to=265
^ 0 sec, 90.492 msec
1422919932.957347 DEBUG: [Forwarder] onIncomingData face=265
data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0
1422919932.958010 DEBUG: [Forwarder] onIncomingData
matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00
1422919932.958342 DEBUG: [Strategy] beforeSatisfyPendingInterest
pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00
inFace=265
data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0
1422919932.958955 DEBUG: [Forwarder] onOutgoingData face=268
data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0



Can these be cases of congestions on such wideband setup?

Thanks,

--
Peter Gusev
Programmer/Analyst @ REMAP, UCLA

peter at remap.ucla.edu
+1 213 5872748
peetonn_ (skype)

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


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

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

From jdd at wustl.edu  Sat Feb  7 07:50:30 2015
From: jdd at wustl.edu (Dehart, John)
Date: Sat, 7 Feb 2015 15:50:30 +0000
Subject: [Nfd-dev] NDN-RTC: NFD processing logs
In-Reply-To: <D697BEB1-D27B-4829-A8B3-61C609BD0ACF@remap.ucla.edu>
References: <CAOFH+OZ8A7MisNk1z=aOdcPaHXd99g83VUvN6+Za=cZA8XOQwg@mail.gmail.com>
	<D0F6F48F.1B3622%jburke@remap.ucla.edu>
	<CADfzvvZZK-Qp1oE9hjpnNzzmQgW3U=hevNYKg1MPLhZBCgF-hA@mail.gmail.com>
	<CADfzvva3KdGqx+4oKRQvShiZ0+DQfp6PQqa0-0-qaSRWi+o5hg@mail.gmail.com>
	<E716A2CA-D2FA-487F-A4FF-494D5910C2BB@remap.ucla.edu>
	<D697BEB1-D27B-4829-A8B3-61C609BD0ACF@remap.ucla.edu>
Message-ID: <C4278617-D697-4A9A-B460-D698306C0208@wustl.edu>


Peter,

Hmm. The first thing I looked at is the start times of each troublesome Interest. Here are the times from
the onIncomingInterest at NFD1:

1423253848.858280

1423253940.375219

1423253970.817990

1423254001.344271

1423254031.836504

1423254062.336132

1423254123.211452

1423254153.709799

1423254184.230811

1423254214.784790

Notice anything? Except for the first one they are nicely spaced at roughly 30 second intervals.
There is one that is a 60 second interval. Could something be happening on one of the systems
every 30 seconds that is causing a disruption? Any chance you could grab system logs for
the three machines? I?m not that familiar with MacOS system logging so I don?t know what to look
for there...

I?ll dig more, hopefully later today.

John



On Feb 6, 2015, at 5:14 PM, Gusev, Peter <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>> wrote:

Hi guys,

So I?ve run setup today and gathered logs.
I?ve setup NFDs with the following settings
...
 default_level NONE
 Forwarder DEBUG
 UdpFace TRACE
?

And then I run tcpdump on each machine like this:
$ sudo tcpdump -w ~/dump.pcap -i en4 udp port 6363

Here is the summary on ?problematic? packets:
https://docs.google.com/document/d/11JAPHI6J4jD6mibMRuWd1EvzP-NY_F2osM2vDF2VaGM/edit?usp=sharing

All the log files and tcpdumps you can find here:
https://www.dropbox.com/s/1d277xbhqs97o66/logs.zip?dl=0

Thanks for all the help!

Thanks,

--
Peter Gusev
Programmer/Analyst @ REMAP, UCLA

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

On Feb 6, 2015, at 8:03 AM, Gusev, Peter <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>> wrote:

Ok, thanks Davide!
I?ll try this out

Thanks,

--
Peter Gusev
Programmer/Analyst @ REMAP, UCLA

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

On Feb 5, 2015, at 10:22 PM, Davide Pesavento <davide.pesavento at lip6.fr<mailto:davide.pesavento at lip6.fr>> wrote:

Peter,

I just checked the code. DatagramFace does not contain a logger
instance, therefore the name of the component you need to enable is
"UdpFace", at the TRACE level. Sorry for the confusion.

To avoid this kind of problems in the future, you can additionally
enable "LoggerFactory" at the DEBUG level. (We should change that to a
warning by the way)

Best,
Davide

On Wed, Feb 4, 2015 at 12:14 AM, Davide Pesavento <davidepesa at gmail.com<mailto:davidepesa at gmail.com>> wrote:
Hi Jeff,

Regarding your last question, if you enable the TRACE log level in NFD
configuration file you should get additional logging when the face receives
or sends anything over the wire. You should see something like:

TRACE: [UdpFace] [id:42,...] Received X bytes
or
TRACE: [UdpFace] [id:42,...] Sent X bytes

If my memory serves me well, those are respectively the first and last
messages printed by NFD.

Best,
Davide


On Wed, Feb 4, 2015, 7:01 AM Burke, Jeff <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>> wrote:

Junxiao,

The application is intended to work over the current internet with low
risk of IP fragmentation, so we are designing the packet sizes for MTUs of
1500 octets.

Peter, can you run NTP in a peer-to-peer configuration to lower the clock
offset between the vious machines and make it easier to troubleshoot just
based on the logging?  I can give you a configuration tomorrow.

Junxiao, in addition to tcpdump, is there anything that logs at a lower
layer in NFD which we could use to see when interest/data bits first come in
over the wire?

We will bring the whole setup to the ndn retreat...

Jeff


From: Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>
Date: Tue, 3 Feb 2015 22:50:35 -0700
To: "Gusev, Peter" <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>>
Cc: Jeff Burke <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>>, "nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>"
<nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>

Subject: Re: [Nfd-dev] NDN-RTC: NFD processing logs

Hi Peter

I forgot to ask earlier: what's the MTU of the NICs?
Make sure the MTU is 9000 octets or higher, otherwise IP fragmentation
will severely affect performance.


Congestion is unlikely to happen with 200Kbps traffic on 1000Mbps link.
CPU is also unlikely to be a bottleneck for 60 Interests/s.

Use `tcpdump` to see exactly when the packet is transmitted onto the
network, in order to determine whether the delay is happening on sender host
or receiver host.
Running `tcpdump` on the host itself will affect its performance. If an
impact is evident, you could setup port mirroring on the switch, and run
`tcpdump` on another machine that is connected to the mirrored port.

Yours, Junxiao

On Tue, Feb 3, 2015 at 12:56 PM, Gusev, Peter <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>>
wrote:

Hi Junxiao,

I run tests with all three (consumer, producer and hub) connected to the
same 1Gbit switch. For the app configuration I tested - bitrate is
~150-200kbit/s, interest rate is about 50-60.

And discovered these cases:

Case #1

NFD1 (consumer):

1422920300.410412DEBUG: [Forwarder] onIncomingInterest face=261
interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00

1422920300.410804 DEBUG: [Forwarder] onOutgoingInterest face=259
interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920300.411138 DEBUG: [BestRouteStrategy2]
/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=2128078661
from=261 newPitEntry-to=259
^ 0 sec, 440 msec // retransmission
1422920300.851526 DEBUG: [Forwarder] onIncomingInterest face=261
interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920300.851843 DEBUG: [Forwarder] onOutgoingInterest face=259
interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920300.852127 DEBUG: [BestRouteStrategy2]
/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=2749769734
from=261 retransmit-retry-to=259
^ 0 sec, 302 msec // data
1422920301.155108 DEBUG: [Forwarder] onIncomingData face=259
data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
1422920301.155452 DEBUG: [Forwarder] onIncomingData
matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920301.155680 DEBUG: [Strategy] beforeSatisfyPendingInterest
pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
inFace=259
data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
1422920301.156152 DEBUG: [Forwarder] onOutgoingData face=261
data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0


NFD2 (hub):
1422920250.169018DEBUG: [Forwarder] onIncomingInterest face=266
interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00

1422920250.169560 DEBUG: [Forwarder] onOutgoingInterest face=264
interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920250.169959 DEBUG: [BestRouteStrategy2]
/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=2128078661
from=266 newPitEntry-to=264
^ 0 sec, 736.911 msec // retransmission
1422920250.906870 DEBUG: [Forwarder] onIncomingInterest face=266
interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920250.907384 DEBUG: [Forwarder] onOutgoingInterest face=264
interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920250.907801 DEBUG: [BestRouteStrategy2]
/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=2749769734
from=266 retransmit-retry-to=264
^ 0 sec, 2.541 msec // data
1422920250.910342 DEBUG: [Forwarder] onIncomingData face=264
data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
1422920250.910812 DEBUG: [Forwarder] onIncomingData
matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920250.911125 DEBUG: [Strategy] beforeSatisfyPendingInterest
pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
inFace=264
data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
1422920250.911706 DEBUG: [Forwarder] onOutgoingData face=266
data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
1422920250.922749 DEBUG: [Forwarder] onIncomingData face=264
data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
1422920250.923068 DEBUG: [Forwarder] onIncomingData
matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920250.923315 DEBUG: [Strategy] beforeSatisfyPendingInterest
pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
inFace=264
data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0

NFD3 (producer):

1422920296.818710 DEBUG: [Forwarder] onIncomingInterest face=268
interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920296.819102 DEBUG: [Forwarder] onOutgoingInterest face=265
interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920296.819408 DEBUG: [BestRouteStrategy2]
/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=2128078661
from=268 newPitEntry-to=265
^ 0 sec, 551.408 msec // data
1422920297.370816 DEBUG: [Forwarder] onIncomingData face=265
data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
1422920297.371248 DEBUG: [Forwarder] onIncomingData
matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920297.371547 DEBUG: [Strategy] beforeSatisfyPendingInterest
pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
inFace=265
data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0
1422920297.372106 DEBUG: [Forwarder] onOutgoingData face=268
data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0

^ 0 sec, 184.298 msec// retransmission

1422920297.556404 DEBUG: [Forwarder] onIncomingInterest face=268
interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00
1422920297.557030 DEBUG: [Forwarder] onOutgoingData face=268
data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/13851/data/%00%00/3/14365/513/0

Case #2

NFD1 (consumer):
1422919936.433502DEBUG: [Forwarder] onIncomingInterest face=261
interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00

1422919936.434221 DEBUG: [BestRouteStrategy2]
/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=3853552983
from=261 newPitEntry-to=259
^ 0 sec, 402.119 msec
1422919936.836340 DEBUG: [Forwarder] onIncomingData face=259
data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0
1422919936.836649 DEBUG: [Forwarder] onIncomingData
matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00
1422919936.836871 DEBUG: [Strategy] beforeSatisfyPendingInterest
pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00
inFace=259
data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0
1422919936.837279 DEBUG: [Forwarder] onOutgoingData face=261
data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0



NFD2 (hub):
1422919886.178188DEBUG: [Forwarder] onIncomingInterest face=266
interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00

1422919886.179368 DEBUG: [BestRouteStrategy2]
/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=3791853569
from=266 newPitEntry-to=264
^ 0 sec, 89.772 msec
1422919886.269140 DEBUG: [Forwarder] onIncomingData face=264
data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00/1/4252/150/0
1422919886.269671 DEBUG: [Forwarder] onIncomingData
matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00
1422919886.270079 DEBUG: [Strategy] beforeSatisfyPendingInterest
pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00
inFace=264
data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00/1/4252/150/0
1422919886.270718 DEBUG: [Forwarder] onOutgoingData face=266
data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4101/data/%00%00/1/4252/150/0



NFD3 (producer):
1422919932.865989DEBUG: [Forwarder] onIncomingInterest face=268
interest=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00

1422919932.866855 DEBUG: [BestRouteStrategy2]
/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=5000&ndn.Nonce=3853552983
from=268 newPitEntry-to=265
^ 0 sec, 90.492 msec
1422919932.957347 DEBUG: [Forwarder] onIncomingData face=265
data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0
1422919932.958010 DEBUG: [Forwarder] onIncomingData
matching=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00
1422919932.958342 DEBUG: [Strategy] beforeSatisfyPendingInterest
pitEntry=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00
inFace=265
data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0
1422919932.958955 DEBUG: [Forwarder] onOutgoingData face=268
data=/ndn/edu/ucla/remap/ndnrtc/user/remap/streams/top_cam/low/delta/4102/data/%00%00/1/4253/150/0



Can these be cases of congestions on such wideband setup?

Thanks,

--
Peter Gusev
Programmer/Analyst @ REMAP, UCLA

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

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


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

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

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

From davide.pesavento at lip6.fr  Sat Feb  7 11:35:57 2015
From: davide.pesavento at lip6.fr (Davide Pesavento)
Date: Sat, 7 Feb 2015 11:35:57 -0800
Subject: [Nfd-dev] [Ndn-interest] lurch 0.1.0 for ndn and related tools
In-Reply-To: <54D340AC.1000702@orange.com>
References: <54D340AC.1000702@orange.com>
Message-ID: <CADfzvvbsj8M+qfcu2BaM5uKXZEw8HHmOVuSJjgt5qoXiKe3n5A@mail.gmail.com>

On Thu, Feb 5, 2015 at 2:06 AM, MUSCARIELLO Luca IMT/OLN
<luca.muscariello at orange.com> wrote:
> 2)  lurch-custom-0.1.0 works with a modified version of  NFD and ndn-cxx
> packages,
> NDN-0.2.0-custom, available here
> http://systemx.enst.fr/archives/NDN-0.2.0-custom.tgz
> and provides:
>         - LRU cache replacement policy;
>         - interest control rate at the client based on optimized multipath
> and adaptive
>           remote AQM as described in [1]
>         - congestion aware forwarding strategy as described in [1]
>

Dear Luca and Massimo,

Have you considered contributing your modifications to the NFD code to
the upstream named-data project? They seem to be valuable additions
and could benefit the whole community.

Best regards,
Davide Pesavento


From luca.muscariello at orange.com  Sat Feb  7 11:46:26 2015
From: luca.muscariello at orange.com (luca.muscariello at orange.com)
Date: Sat, 7 Feb 2015 19:46:26 +0000
Subject: [Nfd-dev] [Ndn-interest] lurch 0.1.0 for ndn and related tools
In-Reply-To: <CADfzvvbsj8M+qfcu2BaM5uKXZEw8HHmOVuSJjgt5qoXiKe3n5A@mail.gmail.com>
References: <54D340AC.1000702@orange.com>,
	<CADfzvvbsj8M+qfcu2BaM5uKXZEw8HHmOVuSJjgt5qoXiKe3n5A@mail.gmail.com>
Message-ID: <19136_1423338387_54D66B93_19136_3006_1_fou5c56966dh5226lh0r0c5r.1423338379924@email.android.com>

Hi

I discussed about that with Giovanni who told me the same a few weeks ago.

We could have a meeting in Paris and discuss about that together in detail.

Luca


-------- Message d'origine --------
De : Davide Pesavento
Date :2015/02/07 20:37 (GMT+01:00)
? : MUSCARIELLO Luca IMT/OLN , Massimo GALLO
Cc : nfd-dev at lists.cs.ucla.edu
Objet : Re: [Ndn-interest] lurch 0.1.0 for ndn and related tools

On Thu, Feb 5, 2015 at 2:06 AM, MUSCARIELLO Luca IMT/OLN
<luca.muscariello at orange.com> wrote:
> 2)  lurch-custom-0.1.0 works with a modified version of  NFD and ndn-cxx
> packages,
> NDN-0.2.0-custom, available here
> http://systemx.enst.fr/archives/NDN-0.2.0-custom.tgz
> and provides:
>         - LRU cache replacement policy;
>         - interest control rate at the client based on optimized multipath
> and adaptive
>           remote AQM as described in [1]
>         - congestion aware forwarding strategy as described in [1]
>

Dear Luca and Massimo,

Have you considered contributing your modifications to the NFD code to
the upstream named-data project? They seem to be valuable additions
and could benefit the whole community.

Best regards,
Davide Pesavento

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

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

From davide.pesavento at lip6.fr  Sat Feb  7 13:41:20 2015
From: davide.pesavento at lip6.fr (Davide Pesavento)
Date: Sat, 7 Feb 2015 13:41:20 -0800
Subject: [Nfd-dev] [Ndn-interest] lurch 0.1.0 for ndn and related tools
In-Reply-To: <19136_1423338387_54D66B93_19136_3006_1_fou5c56966dh5226lh0r0c5r.1423338379924@email.android.com>
References: <54D340AC.1000702@orange.com>
	<CADfzvvbsj8M+qfcu2BaM5uKXZEw8HHmOVuSJjgt5qoXiKe3n5A@mail.gmail.com>
	<19136_1423338387_54D66B93_19136_3006_1_fou5c56966dh5226lh0r0c5r.1423338379924@email.android.com>
Message-ID: <CADfzvvbUcheNGAjxdVn2Gv4paU8J7vhKqWwPkOEzxD3QNPbT1w@mail.gmail.com>

Great. Let's meet in Paris (LINCS?) in the next few weeks then.

Thanks,
Davide

On Sat, Feb 7, 2015 at 11:46 AM,  <luca.muscariello at orange.com> wrote:
> Hi
>
> I discussed about that with Giovanni who told me the same a few weeks ago.
>
> We could have a meeting in Paris and discuss about that together in detail.
>
> Luca
>
>
> -------- Message d'origine --------
> De : Davide Pesavento
> Date :2015/02/07 20:37 (GMT+01:00)
> ? : MUSCARIELLO Luca IMT/OLN , Massimo GALLO
> Cc : nfd-dev at lists.cs.ucla.edu
> Objet : Re: [Ndn-interest] lurch 0.1.0 for ndn and related tools
>
> On Thu, Feb 5, 2015 at 2:06 AM, MUSCARIELLO Luca IMT/OLN
> <luca.muscariello at orange.com> wrote:
>> 2)  lurch-custom-0.1.0 works with a modified version of  NFD and ndn-cxx
>> packages,
>> NDN-0.2.0-custom, available here
>> http://systemx.enst.fr/archives/NDN-0.2.0-custom.tgz
>> and provides:
>>         - LRU cache replacement policy;
>>         - interest control rate at the client based on optimized multipath
>> and adaptive
>>           remote AQM as described in [1]
>>         - congestion aware forwarding strategy as described in [1]
>>
>
> Dear Luca and Massimo,
>
> Have you considered contributing your modifications to the NFD code to
> the upstream named-data project? They seem to be valuable additions
> and could benefit the whole community.
>
> Best regards,
> Davide Pesavento
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
> ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou
> falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and
> delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been
> modified, changed or falsified.
> Thank you.



From shijunxiao at email.arizona.edu  Sun Feb  8 10:13:40 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Sun, 8 Feb 2015 11:13:40 -0700
Subject: [Nfd-dev] NDN-RTC: NFD processing logs
In-Reply-To: <D697BEB1-D27B-4829-A8B3-61C609BD0ACF@remap.ucla.edu>
References: <CAOFH+OZ8A7MisNk1z=aOdcPaHXd99g83VUvN6+Za=cZA8XOQwg@mail.gmail.com>
	<D0F6F48F.1B3622%jburke@remap.ucla.edu>
	<CADfzvvZZK-Qp1oE9hjpnNzzmQgW3U=hevNYKg1MPLhZBCgF-hA@mail.gmail.com>
	<CADfzvva3KdGqx+4oKRQvShiZ0+DQfp6PQqa0-0-qaSRWi+o5hg@mail.gmail.com>
	<E716A2CA-D2FA-487F-A4FF-494D5910C2BB@remap.ucla.edu>
	<D697BEB1-D27B-4829-A8B3-61C609BD0ACF@remap.ucla.edu>
Message-ID: <CAOFH+OY-8ByEQb_RiBmfpsgGVo2vyt3OpGD8MJ-W-VePQ5g1CA@mail.gmail.com>

Hi Peter

On Feb 05 we identified a few possible places that can cause delay:

   - network
   - kernel
   - C++ memory allocator
   - Boost.Asio
   - UdpFace or its base class DatagramFace

The logs you gathered appear to be complete according to what we requested.
@Davide, can you gain some insights from the logs?


Regarding the 30-second interval pattern discovered by John: the only
30-second interval I know of in NFD is UDP face idle_timeout, when this
option is unset in nfd.conf.
Every 30 seconds, UdpChannel will enumerate all its faces, and close all
faces that haven't received anything. There's no evidence that any face is
created, because FaceIds are consistent throughout the logs. However this
scheduled event will take some CPU time, but I don't believe it can cause a
delay of more than 5ms.
To rule out this possibility, adjust face_system.udp.idle_timeout option in
nfd.conf (to "50"), and test again.


>From an earlier log snippet, I notice that the NFD version you are running
is older than September 2014.
Please use git-HEAD version for any bug reports.


As you told me on Feb 05, you will create a traffic simulator that can have
same traffic pattern as NdnCon that can run on headless Ubuntu servers.
I'll be able to test on controlled environment when that tool becomes
available.

Yours, Junxiao

On Fri, Feb 6, 2015 at 4:14 PM, Gusev, Peter <peter at remap.ucla.edu> wrote:

>  Hi guys,
>
>  So I?ve run setup today and gathered logs.
> I?ve setup NFDs with the following settings
> *...*
>
>
>
> * default_level NONE  Forwarder DEBUG  UdpFace TRACE ?*
>
>  And then I run tcpdump on each machine like this:
> *$ sudo tcpdump -w ~/dump.pcap -i en4 udp port 6363*
>
>  Here is the summary on ?problematic? packets:
>
> https://docs.google.com/document/d/11JAPHI6J4jD6mibMRuWd1EvzP-NY_F2osM2vDF2VaGM/edit?usp=sharing
>
>  All the log files and tcpdumps you can find here:
> https://www.dropbox.com/s/1d277xbhqs97o66/logs.zip?dl=0
>
>  Thanks for all the help!
>
> Thanks,
>
> --
> Peter Gusev
> Programmer/Analyst @ REMAP, UCLA
>
> peter at remap.ucla.edu
> +1 213 5872748
> peetonn_ (skype)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150208/0849c53f/attachment.html>

From jburke at remap.ucla.edu  Sun Feb  8 10:33:44 2015
From: jburke at remap.ucla.edu (Burke, Jeff)
Date: Sun, 8 Feb 2015 18:33:44 +0000
Subject: [Nfd-dev] NDN-RTC: NFD processing logs
In-Reply-To: <CAOFH+OY-8ByEQb_RiBmfpsgGVo2vyt3OpGD8MJ-W-VePQ5g1CA@mail.gmail.com>
Message-ID: <D0FCE98C.1B57AA%jburke@remap.ucla.edu>

Junxiao & all,

I want to strongly advocate for debugging the actual, running system that we have now, rather than waiting for new code and using  another setup that may or may not exhibit the same problem.

Would it be possible to work with the system in situ with remote access rather than waiting on the ubuntu headless build? (Alternatively, I would rather host you at UCLA for a week, or fedex you our Mac test machines, than write new application that just attempts to replicate the problem.

What Peter was referring to is an Ubuntu port of ndnrtc that will generate the same type of traffic, not a simulator. We need this for testbed deployment.  However, this work is not done yet, and we are trying to move quickly to real world use, and I really don't think we should make this dependent on further app development work.

Thank you,
Jeff

Hi Peter

On Feb 05 we identified a few possible places that can cause delay:

  *   network
  *   kernel
  *   C++ memory allocator
  *   Boost.Asio
  *   UdpFace or its base class DatagramFace

The logs you gathered appear to be complete according to what we requested.
@Davide, can you gain some insights from the logs?


Regarding the 30-second interval pattern discovered by John: the only 30-second interval I know of in NFD is UDP face idle_timeout, when this option is unset in nfd.conf.
Every 30 seconds, UdpChannel will enumerate all its faces, and close all faces that haven't received anything. There's no evidence that any face is created, because FaceIds are consistent throughout the logs. However this scheduled event will take some CPU time, but I don't believe it can cause a delay of more than 5ms.
To rule out this possibility, adjust face_system.udp.idle_timeout option in nfd.conf (to "50"), and test again.


>From an earlier log snippet, I notice that the NFD version you are running is older than September 2014.
Please use git-HEAD version for any bug reports.


As you told me on Feb 05, you will create a traffic simulator that can have same traffic pattern as NdnCon that can run on headless Ubuntu servers.
I'll be able to test on controlled environment when that tool becomes available.

Yours, Junxiao

On Fri, Feb 6, 2015 at 4:14 PM, Gusev, Peter <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>> wrote:
Hi guys,

So I?ve run setup today and gathered logs.
I?ve setup NFDs with the following settings
...
 default_level NONE
 Forwarder DEBUG
 UdpFace TRACE
?

And then I run tcpdump on each machine like this:
$ sudo tcpdump -w ~/dump.pcap -i en4 udp port 6363

Here is the summary on ?problematic? packets:
https://docs.google.com/document/d/11JAPHI6J4jD6mibMRuWd1EvzP-NY_F2osM2vDF2VaGM/edit?usp=sharing

All the log files and tcpdumps you can find here:
https://www.dropbox.com/s/1d277xbhqs97o66/logs.zip?dl=0

Thanks for all the help!

Thanks,

--
Peter Gusev
Programmer/Analyst @ REMAP, UCLA

peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>
+1 213 5872748<tel:%2B1%20213%205872748>
peetonn_ (skype)

_______________________________________________ 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/20150208/ac76bb32/attachment.html>

From shijunxiao at email.arizona.edu  Sun Feb  8 10:42:25 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Sun, 8 Feb 2015 11:42:25 -0700
Subject: [Nfd-dev] NDN-RTC: NFD processing logs
In-Reply-To: <D0FCE98C.1B57AA%jburke@remap.ucla.edu>
References: <CAOFH+OY-8ByEQb_RiBmfpsgGVo2vyt3OpGD8MJ-W-VePQ5g1CA@mail.gmail.com>
	<D0FCE98C.1B57AA%jburke@remap.ucla.edu>
Message-ID: <CAOFH+OaCaUGkVGEdvn2fRkDB9No5PepTUE+gZrBnJQLgyTR1xA@mail.gmail.com>

Hi Jeff

In any case the delay isn't in forwarding pipelines or strategy according
to logs.
@Davide is expert on faces and related libraries, and he agreed to
determine whether the problem is in UdpFace or a lower layer.

Debugging this problem doesn't depend on new Ubuntu port.
However, upgrading NFD to latest git-HEAD version is necessary for bug
reports, because this problem may have been fixed already and it's wasting
time trying to debug an older version.
After upgrading NFD and confirming it still exists, please officially file
the bug on NFD Redmine site.

Yours, Junxiao

On Sun, Feb 8, 2015 at 11:33 AM, Burke, Jeff <jburke at remap.ucla.edu> wrote:

>  Junxiao & all,
>
>  I want to strongly advocate for debugging the actual, running system
> that we have now, rather than waiting for new code and using  another setup
> that may or may not exhibit the same problem.
>
>  Would it be possible to work with the system *in situ *with remote access
>  rather than waiting on the ubuntu headless build? (Alternatively, I
> would rather host you at UCLA for a week, or fedex you our Mac test
> machines, than write new application that just attempts to replicate the
> problem.
>
>  What Peter was referring to is an Ubuntu port of ndnrtc that will
> generate the same type of traffic, not a simulator. We need this for
> testbed deployment.  However, this work is not done yet, and we are trying
> to move quickly to real world use, and I really don't think we should make
> this dependent on further app development work.
>
>  Thank you,
> Jeff
>
>   Hi Peter
>
>  On Feb 05 we identified a few possible places that can cause delay:
>
>    - network
>    - kernel
>    - C++ memory allocator
>    - Boost.Asio
>    - UdpFace or its base class DatagramFace
>
>  The logs you gathered appear to be complete according to what we
> requested.
>  @Davide, can you gain some insights from the logs?
>
>
>  Regarding the 30-second interval pattern discovered by John: the only
> 30-second interval I know of in NFD is UDP face idle_timeout, when this
> option is unset in nfd.conf.
>  Every 30 seconds, UdpChannel will enumerate all its faces, and close all
> faces that haven't received anything. There's no evidence that any face is
> created, because FaceIds are consistent throughout the logs. However this
> scheduled event will take some CPU time, but I don't believe it can cause a
> delay of more than 5ms.
> To rule out this possibility, adjust face_system.udp.idle_timeout option
> in nfd.conf (to "50"), and test again.
>
>
>  From an earlier log snippet, I notice that the NFD version you are
> running is older than September 2014.
> Please use git-HEAD version for any bug reports.
>
>
>  As you told me on Feb 05, you will create a traffic simulator that can
> have same traffic pattern as NdnCon that can run on headless Ubuntu servers.
> I'll be able to test on controlled environment when that tool becomes
> available.
>
>  Yours, Junxiao
>
> On Fri, Feb 6, 2015 at 4:14 PM, Gusev, Peter <peter at remap.ucla.edu> wrote:
>
>> Hi guys,
>>
>>  So I?ve run setup today and gathered logs.
>> I?ve setup NFDs with the following settings
>> *...*
>>
>>
>>
>> * default_level NONE  Forwarder DEBUG  UdpFace TRACE ?*
>>
>>  And then I run tcpdump on each machine like this:
>> *$ sudo tcpdump -w ~/dump.pcap -i en4 udp port 6363*
>>
>>  Here is the summary on ?problematic? packets:
>>
>> https://docs.google.com/document/d/11JAPHI6J4jD6mibMRuWd1EvzP-NY_F2osM2vDF2VaGM/edit?usp=sharing
>>
>>  All the log files and tcpdumps you can find here:
>> https://www.dropbox.com/s/1d277xbhqs97o66/logs.zip?dl=0
>>
>>  Thanks for all the help!
>>
>> Thanks,
>>
>> --
>> Peter Gusev
>> Programmer/Analyst @ REMAP, UCLA
>>
>> peter at remap.ucla.edu
>> +1 213 5872748
>> peetonn_ (skype)
>>
>
>   _______________________________________________ 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/20150208/e04ee77d/attachment.html>

From jburke at remap.ucla.edu  Sun Feb  8 10:53:14 2015
From: jburke at remap.ucla.edu (Burke, Jeff)
Date: Sun, 8 Feb 2015 18:53:14 +0000
Subject: [Nfd-dev] NDN-RTC: NFD processing logs
In-Reply-To: <CAOFH+OaCaUGkVGEdvn2fRkDB9No5PepTUE+gZrBnJQLgyTR1xA@mail.gmail.com>
Message-ID: <D0FCEE6F.1B57D4%jburke@remap.ucla.edu>


Hi Junxiao,

I don't agree ? unless the NFD team is aware of a change in the codebase that would potentially fix this problem, and you can selectively apply only those changes as a patch, to see if they fix the problem, simply upgrading provides no information on the root cause.  Thus, we may eliminate the symptom without understanding where it comes from or knowing when it might come back.

Given our goal of having this system work "well enough" to use in real meetings, etc. and to do large-scale demos with WUSTL, simply eliminating the symptom is insufficient.

Simplest way to find the root cause is to debug in the current, deployed system.

A hybrid approach is to substitute an NFD 0.3 forwarder (on a different, identical box) as the hub and see if fixes the problem. This might inform which commits to apply/roll back in the testing process.   But, somehow, we should try methodically to find out why this occurs.

We can provide additional hardware configure per the above, if you'd like.  But we need the NFD team to engage with debugging the current running code on the hub.  This will be more productive and more likely to get to the root cause than having us make further changes to the setup.

Thanks,
Jeff

From: Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>
Date: Sun, 8 Feb 2015 11:42:25 -0700
To: Jeff Burke <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>>
Cc: "Gusev, Peter" <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>>, "nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>" <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: Re: [Nfd-dev] NDN-RTC: NFD processing logs

Hi Jeff

In any case the delay isn't in forwarding pipelines or strategy according to logs.
@Davide is expert on faces and related libraries, and he agreed to determine whether the problem is in UdpFace or a lower layer.

Debugging this problem doesn't depend on new Ubuntu port.
However, upgrading NFD to latest git-HEAD version is necessary for bug reports, because this problem may have been fixed already and it's wasting time trying to debug an older version.
After upgrading NFD and confirming it still exists, please officially file the bug on NFD Redmine site.

Yours, Junxiao

On Sun, Feb 8, 2015 at 11:33 AM, Burke, Jeff <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>> wrote:
Junxiao & all,

I want to strongly advocate for debugging the actual, running system that we have now, rather than waiting for new code and using  another setup that may or may not exhibit the same problem.

Would it be possible to work with the system in situ with remote access rather than waiting on the ubuntu headless build? (Alternatively, I would rather host you at UCLA for a week, or fedex you our Mac test machines, than write new application that just attempts to replicate the problem.

What Peter was referring to is an Ubuntu port of ndnrtc that will generate the same type of traffic, not a simulator. We need this for testbed deployment.  However, this work is not done yet, and we are trying to move quickly to real world use, and I really don't think we should make this dependent on further app development work.

Thank you,
Jeff

Hi Peter

On Feb 05 we identified a few possible places that can cause delay:

  *   network
  *   kernel
  *   C++ memory allocator
  *   Boost.Asio
  *   UdpFace or its base class DatagramFace

The logs you gathered appear to be complete according to what we requested.
@Davide, can you gain some insights from the logs?


Regarding the 30-second interval pattern discovered by John: the only 30-second interval I know of in NFD is UDP face idle_timeout, when this option is unset in nfd.conf.
Every 30 seconds, UdpChannel will enumerate all its faces, and close all faces that haven't received anything. There's no evidence that any face is created, because FaceIds are consistent throughout the logs. However this scheduled event will take some CPU time, but I don't believe it can cause a delay of more than 5ms.
To rule out this possibility, adjust face_system.udp.idle_timeout option in nfd.conf (to "50"), and test again.


>From an earlier log snippet, I notice that the NFD version you are running is older than September 2014.
Please use git-HEAD version for any bug reports.


As you told me on Feb 05, you will create a traffic simulator that can have same traffic pattern as NdnCon that can run on headless Ubuntu servers.
I'll be able to test on controlled environment when that tool becomes available.

Yours, Junxiao

On Fri, Feb 6, 2015 at 4:14 PM, Gusev, Peter <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>> wrote:
Hi guys,

So I?ve run setup today and gathered logs.
I?ve setup NFDs with the following settings
...
 default_level NONE
 Forwarder DEBUG
 UdpFace TRACE
?

And then I run tcpdump on each machine like this:
$ sudo tcpdump -w ~/dump.pcap -i en4 udp port 6363

Here is the summary on ?problematic? packets:
https://docs.google.com/document/d/11JAPHI6J4jD6mibMRuWd1EvzP-NY_F2osM2vDF2VaGM/edit?usp=sharing

All the log files and tcpdumps you can find here:
https://www.dropbox.com/s/1d277xbhqs97o66/logs.zip?dl=0

Thanks for all the help!

Thanks,

--
Peter Gusev
Programmer/Analyst @ REMAP, UCLA

peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>
+1 213 5872748<tel:%2B1%20213%205872748>
peetonn_ (skype)

_______________________________________________ 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/20150208/4da1ab4f/attachment.html>

From jburke at remap.UCLA.EDU  Sun Feb  8 11:09:32 2015
From: jburke at remap.UCLA.EDU (Burke, Jeff)
Date: Sun, 8 Feb 2015 19:09:32 +0000
Subject: [Nfd-dev] NDN-RTC: NFD processing logs
In-Reply-To: <D0FCEE6F.1B57D4%jburke@remap.ucla.edu>
Message-ID: <D0FCF457.1B57FE%jburke@remap.ucla.edu>

I have opened Bug #2492 for this.
http://redmine.named-data.net/issues/2492

J.

From: Jeff Burke <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>>
Date: Sun, 8 Feb 2015 18:53:14 +0000
To: Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>
Cc: "nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>" <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: Re: [Nfd-dev] NDN-RTC: NFD processing logs


Hi Junxiao,

I don't agree ? unless the NFD team is aware of a change in the codebase that would potentially fix this problem, and you can selectively apply only those changes as a patch, to see if they fix the problem, simply upgrading provides no information on the root cause.  Thus, we may eliminate the symptom without understanding where it comes from or knowing when it might come back.

Given our goal of having this system work "well enough" to use in real meetings, etc. and to do large-scale demos with WUSTL, simply eliminating the symptom is insufficient.

Simplest way to find the root cause is to debug in the current, deployed system.

A hybrid approach is to substitute an NFD 0.3 forwarder (on a different, identical box) as the hub and see if fixes the problem. This might inform which commits to apply/roll back in the testing process.   But, somehow, we should try methodically to find out why this occurs.

We can provide additional hardware configure per the above, if you'd like.  But we need the NFD team to engage with debugging the current running code on the hub.  This will be more productive and more likely to get to the root cause than having us make further changes to the setup.

Thanks,
Jeff

From: Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>
Date: Sun, 8 Feb 2015 11:42:25 -0700
To: Jeff Burke <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>>
Cc: "Gusev, Peter" <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>>, "nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>" <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: Re: [Nfd-dev] NDN-RTC: NFD processing logs

Hi Jeff

In any case the delay isn't in forwarding pipelines or strategy according to logs.
@Davide is expert on faces and related libraries, and he agreed to determine whether the problem is in UdpFace or a lower layer.

Debugging this problem doesn't depend on new Ubuntu port.
However, upgrading NFD to latest git-HEAD version is necessary for bug reports, because this problem may have been fixed already and it's wasting time trying to debug an older version.
After upgrading NFD and confirming it still exists, please officially file the bug on NFD Redmine site.

Yours, Junxiao

On Sun, Feb 8, 2015 at 11:33 AM, Burke, Jeff <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>> wrote:
Junxiao & all,

I want to strongly advocate for debugging the actual, running system that we have now, rather than waiting for new code and using  another setup that may or may not exhibit the same problem.

Would it be possible to work with the system in situ with remote access rather than waiting on the ubuntu headless build? (Alternatively, I would rather host you at UCLA for a week, or fedex you our Mac test machines, than write new application that just attempts to replicate the problem.

What Peter was referring to is an Ubuntu port of ndnrtc that will generate the same type of traffic, not a simulator. We need this for testbed deployment.  However, this work is not done yet, and we are trying to move quickly to real world use, and I really don't think we should make this dependent on further app development work.

Thank you,
Jeff

Hi Peter

On Feb 05 we identified a few possible places that can cause delay:

  *   network
  *   kernel
  *   C++ memory allocator
  *   Boost.Asio
  *   UdpFace or its base class DatagramFace

The logs you gathered appear to be complete according to what we requested.
@Davide, can you gain some insights from the logs?


Regarding the 30-second interval pattern discovered by John: the only 30-second interval I know of in NFD is UDP face idle_timeout, when this option is unset in nfd.conf.
Every 30 seconds, UdpChannel will enumerate all its faces, and close all faces that haven't received anything. There's no evidence that any face is created, because FaceIds are consistent throughout the logs. However this scheduled event will take some CPU time, but I don't believe it can cause a delay of more than 5ms.
To rule out this possibility, adjust face_system.udp.idle_timeout option in nfd.conf (to "50"), and test again.


>From an earlier log snippet, I notice that the NFD version you are running is older than September 2014.
Please use git-HEAD version for any bug reports.


As you told me on Feb 05, you will create a traffic simulator that can have same traffic pattern as NdnCon that can run on headless Ubuntu servers.
I'll be able to test on controlled environment when that tool becomes available.

Yours, Junxiao

On Fri, Feb 6, 2015 at 4:14 PM, Gusev, Peter <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>> wrote:
Hi guys,

So I?ve run setup today and gathered logs.
I?ve setup NFDs with the following settings
...
 default_level NONE
 Forwarder DEBUG
 UdpFace TRACE
?

And then I run tcpdump on each machine like this:
$ sudo tcpdump -w ~/dump.pcap -i en4 udp port 6363

Here is the summary on ?problematic? packets:
https://docs.google.com/document/d/11JAPHI6J4jD6mibMRuWd1EvzP-NY_F2osM2vDF2VaGM/edit?usp=sharing

All the log files and tcpdumps you can find here:
https://www.dropbox.com/s/1d277xbhqs97o66/logs.zip?dl=0

Thanks for all the help!

Thanks,

--
Peter Gusev
Programmer/Analyst @ REMAP, UCLA

peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>
+1 213 5872748<tel:%2B1%20213%205872748>
peetonn_ (skype)

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

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

From davide.pesavento at lip6.fr  Sun Feb  8 11:15:00 2015
From: davide.pesavento at lip6.fr (Davide Pesavento)
Date: Sun, 8 Feb 2015 11:15:00 -0800
Subject: [Nfd-dev] NDN-RTC: NFD processing logs
In-Reply-To: <D0FCF457.1B57FE%jburke@remap.ucla.edu>
References: <D0FCEE6F.1B57D4%jburke@remap.ucla.edu>
	<D0FCF457.1B57FE%jburke@remap.ucla.edu>
Message-ID: <CADfzvvZ7nEqwgPt7Qrn-mvx7TJvbpDB=f9fcSx1rHRVcBEnEAw@mail.gmail.com>

Guys,

I guess I should've written a summary of the live debugging session I
had with Peter after the retreat. Sorry about that.

I'll post our findings in the ticket that Jeff just opened.

Thanks,
Davide

On Sun, Feb 8, 2015 at 11:09 AM, Burke, Jeff <jburke at remap.ucla.edu> wrote:
> I have opened Bug #2492 for this.
> http://redmine.named-data.net/issues/2492
>
> J.
>
> From: Jeff Burke <jburke at remap.ucla.edu>
> Date: Sun, 8 Feb 2015 18:53:14 +0000
> To: Junxiao Shi <shijunxiao at email.arizona.edu>
> Cc: "nfd-dev at lists.cs.ucla.edu" <nfd-dev at lists.cs.ucla.edu>
>
> Subject: Re: [Nfd-dev] NDN-RTC: NFD processing logs
>
>
> Hi Junxiao,
>
> I don't agree ? unless the NFD team is aware of a change in the codebase
> that would potentially fix this problem, and you can selectively apply only
> those changes as a patch, to see if they fix the problem, simply upgrading
> provides no information on the root cause.  Thus, we may eliminate the
> symptom without understanding where it comes from or knowing when it might
> come back.
>
> Given our goal of having this system work "well enough" to use in real
> meetings, etc. and to do large-scale demos with WUSTL, simply eliminating
> the symptom is insufficient.
>
> Simplest way to find the root cause is to debug in the current, deployed
> system.
>
> A hybrid approach is to substitute an NFD 0.3 forwarder (on a different,
> identical box) as the hub and see if fixes the problem. This might inform
> which commits to apply/roll back in the testing process.   But, somehow, we
> should try methodically to find out why this occurs.
>
> We can provide additional hardware configure per the above, if you'd like.
> But we need the NFD team to engage with debugging the current running code
> on the hub.  This will be more productive and more likely to get to the root
> cause than having us make further changes to the setup.
>
> Thanks,
> Jeff
>
> From: Junxiao Shi <shijunxiao at email.arizona.edu>
> Date: Sun, 8 Feb 2015 11:42:25 -0700
> To: Jeff Burke <jburke at remap.ucla.edu>
> Cc: "Gusev, Peter" <peter at remap.ucla.edu>, "nfd-dev at lists.cs.ucla.edu"
> <nfd-dev at lists.cs.ucla.edu>
> Subject: Re: [Nfd-dev] NDN-RTC: NFD processing logs
>
> Hi Jeff
>
> In any case the delay isn't in forwarding pipelines or strategy according to
> logs.
> @Davide is expert on faces and related libraries, and he agreed to determine
> whether the problem is in UdpFace or a lower layer.
>
> Debugging this problem doesn't depend on new Ubuntu port.
> However, upgrading NFD to latest git-HEAD version is necessary for bug
> reports, because this problem may have been fixed already and it's wasting
> time trying to debug an older version.
> After upgrading NFD and confirming it still exists, please officially file
> the bug on NFD Redmine site.
>
> Yours, Junxiao
>
> On Sun, Feb 8, 2015 at 11:33 AM, Burke, Jeff <jburke at remap.ucla.edu> wrote:
>>
>> Junxiao & all,
>>
>> I want to strongly advocate for debugging the actual, running system that
>> we have now, rather than waiting for new code and using  another setup that
>> may or may not exhibit the same problem.
>>
>> Would it be possible to work with the system in situ with remote access
>> rather than waiting on the ubuntu headless build? (Alternatively, I would
>> rather host you at UCLA for a week, or fedex you our Mac test machines, than
>> write new application that just attempts to replicate the problem.
>>
>> What Peter was referring to is an Ubuntu port of ndnrtc that will generate
>> the same type of traffic, not a simulator. We need this for testbed
>> deployment.  However, this work is not done yet, and we are trying to move
>> quickly to real world use, and I really don't think we should make this
>> dependent on further app development work.
>>
>> Thank you,
>> Jeff
>>
>> Hi Peter
>>
>> On Feb 05 we identified a few possible places that can cause delay:
>>
>> network
>> kernel
>> C++ memory allocator
>> Boost.Asio
>> UdpFace or its base class DatagramFace
>>
>> The logs you gathered appear to be complete according to what we
>> requested.
>> @Davide, can you gain some insights from the logs?
>>
>>
>> Regarding the 30-second interval pattern discovered by John: the only
>> 30-second interval I know of in NFD is UDP face idle_timeout, when this
>> option is unset in nfd.conf.
>> Every 30 seconds, UdpChannel will enumerate all its faces, and close all
>> faces that haven't received anything. There's no evidence that any face is
>> created, because FaceIds are consistent throughout the logs. However this
>> scheduled event will take some CPU time, but I don't believe it can cause a
>> delay of more than 5ms.
>> To rule out this possibility, adjust face_system.udp.idle_timeout option
>> in nfd.conf (to "50"), and test again.
>>
>>
>> From an earlier log snippet, I notice that the NFD version you are running
>> is older than September 2014.
>> Please use git-HEAD version for any bug reports.
>>
>>
>> As you told me on Feb 05, you will create a traffic simulator that can
>> have same traffic pattern as NdnCon that can run on headless Ubuntu servers.
>> I'll be able to test on controlled environment when that tool becomes
>> available.
>>
>> Yours, Junxiao
>>
>> On Fri, Feb 6, 2015 at 4:14 PM, Gusev, Peter <peter at remap.ucla.edu> wrote:
>>>
>>> Hi guys,
>>>
>>> So I?ve run setup today and gathered logs.
>>> I?ve setup NFDs with the following settings
>>> ...
>>>  default_level NONE
>>>  Forwarder DEBUG
>>>  UdpFace TRACE
>>> ?
>>>
>>> And then I run tcpdump on each machine like this:
>>> $ sudo tcpdump -w ~/dump.pcap -i en4 udp port 6363
>>>
>>> Here is the summary on ?problematic? packets:
>>>
>>> https://docs.google.com/document/d/11JAPHI6J4jD6mibMRuWd1EvzP-NY_F2osM2vDF2VaGM/edit?usp=sharing
>>>
>>> All the log files and tcpdumps you can find here:
>>> https://www.dropbox.com/s/1d277xbhqs97o66/logs.zip?dl=0
>>>
>>> Thanks for all the help!
>>>
>>> Thanks,
>>>
>>> --
>>> Peter Gusev
>>> Programmer/Analyst @ REMAP, UCLA
>>>
>>> peter at remap.ucla.edu
>>> +1 213 5872748
>>> peetonn_ (skype)
>>
>>
>> _______________________________________________ Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.eduhttp://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>
> _______________________________________________ Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>



From shijunxiao at email.arizona.edu  Sun Feb  8 11:16:42 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Sun, 8 Feb 2015 12:16:42 -0700
Subject: [Nfd-dev] NDN-RTC: NFD processing logs
In-Reply-To: <D0FCEE6F.1B57D4%jburke@remap.ucla.edu>
References: <CAOFH+OaCaUGkVGEdvn2fRkDB9No5PepTUE+gZrBnJQLgyTR1xA@mail.gmail.com>
	<D0FCEE6F.1B57D4%jburke@remap.ucla.edu>
Message-ID: <CAOFH+OYg0A3ijZRchWNrF9or_FFpJSgNpVm_ea4Q1ffwLabTXw@mail.gmail.com>

Hi Jeff

Upgrading to git-HEAD does not prevent you from finding out the root cause
the problem.

Please use the following procedure to find out the root cause:

   1. take a note of commit hash of the current NFD
   2. upgrade to git-HEAD
   3. test whether the problem exists; if yes, abort these steps, and we
   should use git-HEAD for further debugging
   4. downgrade one commit
   5. test whether the problem re-appear; if yes, abort these steps, and we
   have concluded the next commit contains the fix for the problem
   6. if current commit is after the commit in note-1, go to step 4


Yours, Junxiao

On Sun, Feb 8, 2015 at 11:53 AM, Burke, Jeff <jburke at remap.ucla.edu> wrote:

>
>  Hi Junxiao,
>
>  I don't agree ? unless the NFD team is aware of a change in the codebase
> that would potentially fix this problem, and you can selectively apply *only
> those changes* as a patch*, *to see if they fix the problem, simply
> upgrading provides no information on the root cause.  Thus, we may
> eliminate the symptom without understanding where it comes from or knowing
> when it might come back.
>
>  Given our goal of having this system work "well enough" to use in real
> meetings, etc. and to do large-scale demos with WUSTL, simply eliminating
> the symptom is insufficient.
>
>  Simplest way to find the root cause is to debug in the current, deployed
> system.
>
>  A hybrid approach is to substitute an NFD 0.3 forwarder (on a different,
> identical box) as the hub and see if fixes the problem. This might inform
> which commits to apply/roll back in the testing process.   But, somehow, we
> should try methodically to find out *why *this occurs.
>
>  We can provide additional hardware configure per the above, if you'd
> like.  But we need the NFD team to engage with debugging the current
> running code on the hub.  This will be more productive and more likely to
> get to the root cause than having us make further changes to the setup.
>
>  Thanks,
> Jeff
>
>   From: Junxiao Shi <shijunxiao at email.arizona.edu>
> Date: Sun, 8 Feb 2015 11:42:25 -0700
> To: Jeff Burke <jburke at remap.ucla.edu>
> Cc: "Gusev, Peter" <peter at remap.ucla.edu>, "nfd-dev at lists.cs.ucla.edu" <
> nfd-dev at lists.cs.ucla.edu>
> Subject: Re: [Nfd-dev] NDN-RTC: NFD processing logs
>
>  Hi Jeff
>
>  In any case the delay isn't in forwarding pipelines or strategy
> according to logs.
> @Davide is expert on faces and related libraries, and he agreed to
> determine whether the problem is in UdpFace or a lower layer.
>
>  Debugging this problem doesn't depend on new Ubuntu port.
> However, upgrading NFD to latest git-HEAD version is necessary for bug
> reports, because this problem may have been fixed already and it's wasting
> time trying to debug an older version.
> After upgrading NFD and confirming it still exists, please officially file
> the bug on NFD Redmine site.
>
>  Yours, Junxiao
>
> On Sun, Feb 8, 2015 at 11:33 AM, Burke, Jeff <jburke at remap.ucla.edu>
> wrote:
>
>>  Junxiao & all,
>>
>>  I want to strongly advocate for debugging the actual, running system
>> that we have now, rather than waiting for new code and using  another setup
>> that may or may not exhibit the same problem.
>>
>>  Would it be possible to work with the system *in situ *with remote
>> access rather than waiting on the ubuntu headless build? (Alternatively,
>> I would rather host you at UCLA for a week, or fedex you our Mac test
>> machines, than write new application that just attempts to replicate the
>> problem.
>>
>>  What Peter was referring to is an Ubuntu port of ndnrtc that will
>> generate the same type of traffic, not a simulator. We need this for
>> testbed deployment.  However, this work is not done yet, and we are trying
>> to move quickly to real world use, and I really don't think we should make
>> this dependent on further app development work.
>>
>>  Thank you,
>> Jeff
>>
>>    Hi Peter
>>
>>  On Feb 05 we identified a few possible places that can cause delay:
>>
>>    - network
>>    - kernel
>>    - C++ memory allocator
>>    - Boost.Asio
>>    - UdpFace or its base class DatagramFace
>>
>>  The logs you gathered appear to be complete according to what we
>> requested.
>>  @Davide, can you gain some insights from the logs?
>>
>>
>>  Regarding the 30-second interval pattern discovered by John: the only
>> 30-second interval I know of in NFD is UDP face idle_timeout, when this
>> option is unset in nfd.conf.
>>  Every 30 seconds, UdpChannel will enumerate all its faces, and close
>> all faces that haven't received anything. There's no evidence that any face
>> is created, because FaceIds are consistent throughout the logs. However
>> this scheduled event will take some CPU time, but I don't believe it can
>> cause a delay of more than 5ms.
>> To rule out this possibility, adjust face_system.udp.idle_timeout option
>> in nfd.conf (to "50"), and test again.
>>
>>
>>  From an earlier log snippet, I notice that the NFD version you are
>> running is older than September 2014.
>> Please use git-HEAD version for any bug reports.
>>
>>
>>  As you told me on Feb 05, you will create a traffic simulator that can
>> have same traffic pattern as NdnCon that can run on headless Ubuntu servers.
>> I'll be able to test on controlled environment when that tool becomes
>> available.
>>
>>  Yours, Junxiao
>>
>> On Fri, Feb 6, 2015 at 4:14 PM, Gusev, Peter <peter at remap.ucla.edu>
>> wrote:
>>
>>> Hi guys,
>>>
>>>  So I?ve run setup today and gathered logs.
>>> I?ve setup NFDs with the following settings
>>> *...*
>>>
>>>
>>>
>>> * default_level NONE  Forwarder DEBUG  UdpFace TRACE ?*
>>>
>>>  And then I run tcpdump on each machine like this:
>>> *$ sudo tcpdump -w ~/dump.pcap -i en4 udp port 6363*
>>>
>>>  Here is the summary on ?problematic? packets:
>>>
>>> https://docs.google.com/document/d/11JAPHI6J4jD6mibMRuWd1EvzP-NY_F2osM2vDF2VaGM/edit?usp=sharing
>>>
>>>  All the log files and tcpdumps you can find here:
>>> https://www.dropbox.com/s/1d277xbhqs97o66/logs.zip?dl=0
>>>
>>>  Thanks for all the help!
>>>
>>> Thanks,
>>>
>>> --
>>> Peter Gusev
>>> Programmer/Analyst @ REMAP, UCLA
>>>
>>> peter at remap.ucla.edu
>>> +1 213 5872748
>>> peetonn_ (skype)
>>>
>>
>>    _______________________________________________ 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/20150208/5b40bd36/attachment.html>

From jdd at wustl.edu  Sun Feb  8 11:22:52 2015
From: jdd at wustl.edu (Dehart, John)
Date: Sun, 8 Feb 2015 19:22:52 +0000
Subject: [Nfd-dev] NDN-RTC: NFD processing logs
In-Reply-To: <D0FCEE6F.1B57D4%jburke@remap.ucla.edu>
References: <D0FCEE6F.1B57D4%jburke@remap.ucla.edu>
Message-ID: <D530A6BC-7FEA-44EF-AC23-035AAE852A12@wustl.edu>


Jeff and Peter,

Another thing you might try is to have your consumer and producer remain on their
current devices with their current NFD installation but have them use REMAP as their hub.
REMAP is still currently running an NFD  version of 0.2.0 but will soon be upgraded to
the 0.3.0 release.

Is it possible to have the consumer and producer laptops on the same subnet as REMAP
to try to come as close as possible to your current configuration?

If we can repeat the problem with installed Testbed nodes it might make it easier
for others to replicate the problem at their sites.

I?ll hold off on upgrades of Testbed nodes while we discuss our options.

John

On Feb 8, 2015, at 12:53 PM, Burke, Jeff <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>> wrote:


Hi Junxiao,

I don't agree ? unless the NFD team is aware of a change in the codebase that would potentially fix this problem, and you can selectively apply only those changes as a patch, to see if they fix the problem, simply upgrading provides no information on the root cause.  Thus, we may eliminate the symptom without understanding where it comes from or knowing when it might come back.

Given our goal of having this system work "well enough" to use in real meetings, etc. and to do large-scale demos with WUSTL, simply eliminating the symptom is insufficient.

Simplest way to find the root cause is to debug in the current, deployed system.

A hybrid approach is to substitute an NFD 0.3 forwarder (on a different, identical box) as the hub and see if fixes the problem. This might inform which commits to apply/roll back in the testing process.   But, somehow, we should try methodically to find out why this occurs.

We can provide additional hardware configure per the above, if you'd like.  But we need the NFD team to engage with debugging the current running code on the hub.  This will be more productive and more likely to get to the root cause than having us make further changes to the setup.

Thanks,
Jeff

From: Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>
Date: Sun, 8 Feb 2015 11:42:25 -0700
To: Jeff Burke <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>>
Cc: "Gusev, Peter" <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>>, "nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>" <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: Re: [Nfd-dev] NDN-RTC: NFD processing logs

Hi Jeff

In any case the delay isn't in forwarding pipelines or strategy according to logs.
@Davide is expert on faces and related libraries, and he agreed to determine whether the problem is in UdpFace or a lower layer.

Debugging this problem doesn't depend on new Ubuntu port.
However, upgrading NFD to latest git-HEAD version is necessary for bug reports, because this problem may have been fixed already and it's wasting time trying to debug an older version.
After upgrading NFD and confirming it still exists, please officially file the bug on NFD Redmine site.

Yours, Junxiao

On Sun, Feb 8, 2015 at 11:33 AM, Burke, Jeff <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>> wrote:
Junxiao & all,

I want to strongly advocate for debugging the actual, running system that we have now, rather than waiting for new code and using  another setup that may or may not exhibit the same problem.

Would it be possible to work with the system in situ with remote access rather than waiting on the ubuntu headless build? (Alternatively, I would rather host you at UCLA for a week, or fedex you our Mac test machines, than write new application that just attempts to replicate the problem.

What Peter was referring to is an Ubuntu port of ndnrtc that will generate the same type of traffic, not a simulator. We need this for testbed deployment.  However, this work is not done yet, and we are trying to move quickly to real world use, and I really don't think we should make this dependent on further app development work.

Thank you,
Jeff

Hi Peter

On Feb 05 we identified a few possible places that can cause delay:

  *   network
  *   kernel
  *   C++ memory allocator
  *   Boost.Asio
  *   UdpFace or its base class DatagramFace

The logs you gathered appear to be complete according to what we requested.
@Davide, can you gain some insights from the logs?


Regarding the 30-second interval pattern discovered by John: the only 30-second interval I know of in NFD is UDP face idle_timeout, when this option is unset in nfd.conf.
Every 30 seconds, UdpChannel will enumerate all its faces, and close all faces that haven't received anything. There's no evidence that any face is created, because FaceIds are consistent throughout the logs. However this scheduled event will take some CPU time, but I don't believe it can cause a delay of more than 5ms.
To rule out this possibility, adjust face_system.udp.idle_timeout option in nfd.conf (to "50"), and test again.


>From an earlier log snippet, I notice that the NFD version you are running is older than September 2014.
Please use git-HEAD version for any bug reports.


As you told me on Feb 05, you will create a traffic simulator that can have same traffic pattern as NdnCon that can run on headless Ubuntu servers.
I'll be able to test on controlled environment when that tool becomes available.

Yours, Junxiao

On Fri, Feb 6, 2015 at 4:14 PM, Gusev, Peter <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>> wrote:
Hi guys,

So I?ve run setup today and gathered logs.
I?ve setup NFDs with the following settings
...
 default_level NONE
 Forwarder DEBUG
 UdpFace TRACE
?

And then I run tcpdump on each machine like this:
$ sudo tcpdump -w ~/dump.pcap -i en4 udp port 6363

Here is the summary on ?problematic? packets:
https://docs.google.com/document/d/11JAPHI6J4jD6mibMRuWd1EvzP-NY_F2osM2vDF2VaGM/edit?usp=sharing

All the log files and tcpdumps you can find here:
https://www.dropbox.com/s/1d277xbhqs97o66/logs.zip?dl=0

Thanks for all the help!

Thanks,

--
Peter Gusev
Programmer/Analyst @ REMAP, UCLA

peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>
+1 213 5872748<tel:%2B1%20213%205872748>
peetonn_ (skype)

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

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

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

From jburke at remap.UCLA.EDU  Sun Feb  8 11:24:19 2015
From: jburke at remap.UCLA.EDU (Burke, Jeff)
Date: Sun, 8 Feb 2015 19:24:19 +0000
Subject: [Nfd-dev] NDN-RTC: NFD processing logs
In-Reply-To: <CAOFH+OYg0A3ijZRchWNrF9or_FFpJSgNpVm_ea4Q1ffwLabTXw@mail.gmail.com>
Message-ID: <D0FCF6D3.1B5814%jburke@remap.ucla.edu>

Junxiao,

Sure, the process you are describing is exactly what I meant.

But you are missing the point - I am asking that the NFD team do this troubleshooting on your code (whatever the recommended process is) directly on the current boxes.

We have addressed every question you have raised about our setup, spent hours trying to show it's not some extremely unlikely problem with an unloaded LAN and CPU, and sat with NFD developers at the retreat to further narrow down ? now  we need your help!

Thanks,
Jeff


From: Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>
Date: Sun, 8 Feb 2015 12:16:42 -0700
To: Jeff Burke <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>>
Cc: "Gusev, Peter" <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>>, "nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>" <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: Re: [Nfd-dev] NDN-RTC: NFD processing logs

Hi Jeff

Upgrading to git-HEAD does not prevent you from finding out the root cause the problem.

Please use the following procedure to find out the root cause:

  1.  take a note of commit hash of the current NFD
  2.  upgrade to git-HEAD
  3.  test whether the problem exists; if yes, abort these steps, and we should use git-HEAD for further debugging
  4.  downgrade one commit
  5.  test whether the problem re-appear; if yes, abort these steps, and we have concluded the next commit contains the fix for the problem
  6.  if current commit is after the commit in note-1, go to step 4

Yours, Junxiao

On Sun, Feb 8, 2015 at 11:53 AM, Burke, Jeff <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>> wrote:

Hi Junxiao,

I don't agree ? unless the NFD team is aware of a change in the codebase that would potentially fix this problem, and you can selectively apply only those changes as a patch, to see if they fix the problem, simply upgrading provides no information on the root cause.  Thus, we may eliminate the symptom without understanding where it comes from or knowing when it might come back.

Given our goal of having this system work "well enough" to use in real meetings, etc. and to do large-scale demos with WUSTL, simply eliminating the symptom is insufficient.

Simplest way to find the root cause is to debug in the current, deployed system.

A hybrid approach is to substitute an NFD 0.3 forwarder (on a different, identical box) as the hub and see if fixes the problem. This might inform which commits to apply/roll back in the testing process.   But, somehow, we should try methodically to find out why this occurs.

We can provide additional hardware configure per the above, if you'd like.  But we need the NFD team to engage with debugging the current running code on the hub.  This will be more productive and more likely to get to the root cause than having us make further changes to the setup.

Thanks,
Jeff

From: Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>
Date: Sun, 8 Feb 2015 11:42:25 -0700
To: Jeff Burke <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>>
Cc: "Gusev, Peter" <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>>, "nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>" <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: Re: [Nfd-dev] NDN-RTC: NFD processing logs

Hi Jeff

In any case the delay isn't in forwarding pipelines or strategy according to logs.
@Davide is expert on faces and related libraries, and he agreed to determine whether the problem is in UdpFace or a lower layer.

Debugging this problem doesn't depend on new Ubuntu port.
However, upgrading NFD to latest git-HEAD version is necessary for bug reports, because this problem may have been fixed already and it's wasting time trying to debug an older version.
After upgrading NFD and confirming it still exists, please officially file the bug on NFD Redmine site.

Yours, Junxiao

On Sun, Feb 8, 2015 at 11:33 AM, Burke, Jeff <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>> wrote:
Junxiao & all,

I want to strongly advocate for debugging the actual, running system that we have now, rather than waiting for new code and using  another setup that may or may not exhibit the same problem.

Would it be possible to work with the system in situ with remote access rather than waiting on the ubuntu headless build? (Alternatively, I would rather host you at UCLA for a week, or fedex you our Mac test machines, than write new application that just attempts to replicate the problem.

What Peter was referring to is an Ubuntu port of ndnrtc that will generate the same type of traffic, not a simulator. We need this for testbed deployment.  However, this work is not done yet, and we are trying to move quickly to real world use, and I really don't think we should make this dependent on further app development work.

Thank you,
Jeff

Hi Peter

On Feb 05 we identified a few possible places that can cause delay:

  *   network
  *   kernel
  *   C++ memory allocator
  *   Boost.Asio
  *   UdpFace or its base class DatagramFace

The logs you gathered appear to be complete according to what we requested.
@Davide, can you gain some insights from the logs?


Regarding the 30-second interval pattern discovered by John: the only 30-second interval I know of in NFD is UDP face idle_timeout, when this option is unset in nfd.conf.
Every 30 seconds, UdpChannel will enumerate all its faces, and close all faces that haven't received anything. There's no evidence that any face is created, because FaceIds are consistent throughout the logs. However this scheduled event will take some CPU time, but I don't believe it can cause a delay of more than 5ms.
To rule out this possibility, adjust face_system.udp.idle_timeout option in nfd.conf (to "50"), and test again.


>From an earlier log snippet, I notice that the NFD version you are running is older than September 2014.
Please use git-HEAD version for any bug reports.


As you told me on Feb 05, you will create a traffic simulator that can have same traffic pattern as NdnCon that can run on headless Ubuntu servers.
I'll be able to test on controlled environment when that tool becomes available.

Yours, Junxiao

On Fri, Feb 6, 2015 at 4:14 PM, Gusev, Peter <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>> wrote:
Hi guys,

So I?ve run setup today and gathered logs.
I?ve setup NFDs with the following settings
...
 default_level NONE
 Forwarder DEBUG
 UdpFace TRACE
?

And then I run tcpdump on each machine like this:
$ sudo tcpdump -w ~/dump.pcap -i en4 udp port 6363

Here is the summary on ?problematic? packets:
https://docs.google.com/document/d/11JAPHI6J4jD6mibMRuWd1EvzP-NY_F2osM2vDF2VaGM/edit?usp=sharing

All the log files and tcpdumps you can find here:
https://www.dropbox.com/s/1d277xbhqs97o66/logs.zip?dl=0

Thanks for all the help!

Thanks,

--
Peter Gusev
Programmer/Analyst @ REMAP, UCLA

peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>
+1 213 5872748<tel:%2B1%20213%205872748>
peetonn_ (skype)

_______________________________________________ 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/20150208/ce84aaad/attachment.html>

From jburke at remap.UCLA.EDU  Sun Feb  8 11:26:24 2015
From: jburke at remap.UCLA.EDU (Burke, Jeff)
Date: Sun, 8 Feb 2015 19:26:24 +0000
Subject: [Nfd-dev] NDN-RTC: NFD processing logs
In-Reply-To: <D530A6BC-7FEA-44EF-AC23-035AAE852A12@wustl.edu>
Message-ID: <D0FCF7D2.1B5829%jburke@remap.ucla.edu>


Hi John,

Good point. Our hub is not on the same subnet, unfortunately, but we can spin up a 0.3 box if needed.

But I'd really like to invite the NFD folks to directly debug the installation on the problematic hub.

Jeff


From: "Dehart, John" <jdd at wustl.edu<mailto:jdd at wustl.edu>>
Date: Sun, 8 Feb 2015 19:22:52 +0000
To: Jeff Burke <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>>, "peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>" <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>>
Cc: Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>, "nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>" <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: Re: [Nfd-dev] NDN-RTC: NFD processing logs


Jeff and Peter,

Another thing you might try is to have your consumer and producer remain on their
current devices with their current NFD installation but have them use REMAP as their hub.
REMAP is still currently running an NFD  version of 0.2.0 but will soon be upgraded to
the 0.3.0 release.

Is it possible to have the consumer and producer laptops on the same subnet as REMAP
to try to come as close as possible to your current configuration?

If we can repeat the problem with installed Testbed nodes it might make it easier
for others to replicate the problem at their sites.

I?ll hold off on upgrades of Testbed nodes while we discuss our options.

John

On Feb 8, 2015, at 12:53 PM, Burke, Jeff <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>> wrote:


Hi Junxiao,

I don't agree ? unless the NFD team is aware of a change in the codebase that would potentially fix this problem, and you can selectively apply only those changes as a patch, to see if they fix the problem, simply upgrading provides no information on the root cause.  Thus, we may eliminate the symptom without understanding where it comes from or knowing when it might come back.

Given our goal of having this system work "well enough" to use in real meetings, etc. and to do large-scale demos with WUSTL, simply eliminating the symptom is insufficient.

Simplest way to find the root cause is to debug in the current, deployed system.

A hybrid approach is to substitute an NFD 0.3 forwarder (on a different, identical box) as the hub and see if fixes the problem. This might inform which commits to apply/roll back in the testing process.   But, somehow, we should try methodically to find out why this occurs.

We can provide additional hardware configure per the above, if you'd like.  But we need the NFD team to engage with debugging the current running code on the hub.  This will be more productive and more likely to get to the root cause than having us make further changes to the setup.

Thanks,
Jeff

From: Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>
Date: Sun, 8 Feb 2015 11:42:25 -0700
To: Jeff Burke <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>>
Cc: "Gusev, Peter" <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>>, "nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>" <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: Re: [Nfd-dev] NDN-RTC: NFD processing logs

Hi Jeff

In any case the delay isn't in forwarding pipelines or strategy according to logs.
@Davide is expert on faces and related libraries, and he agreed to determine whether the problem is in UdpFace or a lower layer.

Debugging this problem doesn't depend on new Ubuntu port.
However, upgrading NFD to latest git-HEAD version is necessary for bug reports, because this problem may have been fixed already and it's wasting time trying to debug an older version.
After upgrading NFD and confirming it still exists, please officially file the bug on NFD Redmine site.

Yours, Junxiao

On Sun, Feb 8, 2015 at 11:33 AM, Burke, Jeff <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>> wrote:
Junxiao & all,

I want to strongly advocate for debugging the actual, running system that we have now, rather than waiting for new code and using  another setup that may or may not exhibit the same problem.

Would it be possible to work with the system in situ with remote access rather than waiting on the ubuntu headless build? (Alternatively, I would rather host you at UCLA for a week, or fedex you our Mac test machines, than write new application that just attempts to replicate the problem.

What Peter was referring to is an Ubuntu port of ndnrtc that will generate the same type of traffic, not a simulator. We need this for testbed deployment.  However, this work is not done yet, and we are trying to move quickly to real world use, and I really don't think we should make this dependent on further app development work.

Thank you,
Jeff

Hi Peter

On Feb 05 we identified a few possible places that can cause delay:

  *   network
  *   kernel
  *   C++ memory allocator
  *   Boost.Asio
  *   UdpFace or its base class DatagramFace

The logs you gathered appear to be complete according to what we requested.
@Davide, can you gain some insights from the logs?


Regarding the 30-second interval pattern discovered by John: the only 30-second interval I know of in NFD is UDP face idle_timeout, when this option is unset in nfd.conf.
Every 30 seconds, UdpChannel will enumerate all its faces, and close all faces that haven't received anything. There's no evidence that any face is created, because FaceIds are consistent throughout the logs. However this scheduled event will take some CPU time, but I don't believe it can cause a delay of more than 5ms.
To rule out this possibility, adjust face_system.udp.idle_timeout option in nfd.conf (to "50"), and test again.


>From an earlier log snippet, I notice that the NFD version you are running is older than September 2014.
Please use git-HEAD version for any bug reports.


As you told me on Feb 05, you will create a traffic simulator that can have same traffic pattern as NdnCon that can run on headless Ubuntu servers.
I'll be able to test on controlled environment when that tool becomes available.

Yours, Junxiao

On Fri, Feb 6, 2015 at 4:14 PM, Gusev, Peter <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>> wrote:
Hi guys,

So I?ve run setup today and gathered logs.
I?ve setup NFDs with the following settings
...
 default_level NONE
 Forwarder DEBUG
 UdpFace TRACE
?

And then I run tcpdump on each machine like this:
$ sudo tcpdump -w ~/dump.pcap -i en4 udp port 6363

Here is the summary on ?problematic? packets:
https://docs.google.com/document/d/11JAPHI6J4jD6mibMRuWd1EvzP-NY_F2osM2vDF2VaGM/edit?usp=sharing

All the log files and tcpdumps you can find here:
https://www.dropbox.com/s/1d277xbhqs97o66/logs.zip?dl=0

Thanks for all the help!

Thanks,

--
Peter Gusev
Programmer/Analyst @ REMAP, UCLA

peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>
+1 213 5872748<tel:%2B1%20213%205872748>
peetonn_ (skype)

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

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

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

From lanwang at memphis.edu  Sun Feb  8 15:32:51 2015
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Sun, 8 Feb 2015 23:32:51 +0000
Subject: [Nfd-dev] NDN-RTC: NFD processing logs
In-Reply-To: <D0FCF7D2.1B5829%jburke@remap.ucla.edu>
References: <D0FCF7D2.1B5829%jburke@remap.ucla.edu>
Message-ID: <16482CED-4BE7-407C-8140-9BB9992613CF@memphis.edu>

Agree with Jeff.  It'll be much easier for Junxiao to figure out what's the problem, since Peter already spent a lot of time debugging this and he's not familiar with the internal working of nfd.

Lan

On Feb 8, 2015, at 1:26 PM, "Burke, Jeff" <jburke at remap.UCLA.EDU<mailto:jburke at remap.UCLA.EDU>>
 wrote:


Hi John,

Good point. Our hub is not on the same subnet, unfortunately, but we can spin up a 0.3 box if needed.

But I'd really like to invite the NFD folks to directly debug the installation on the problematic hub.

Jeff


From: "Dehart, John" <jdd at wustl.edu<mailto:jdd at wustl.edu>>
Date: Sun, 8 Feb 2015 19:22:52 +0000
To: Jeff Burke <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>>, "peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>" <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>>
Cc: Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>, "nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>" <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: Re: [Nfd-dev] NDN-RTC: NFD processing logs


Jeff and Peter,

Another thing you might try is to have your consumer and producer remain on their
current devices with their current NFD installation but have them use REMAP as their hub.
REMAP is still currently running an NFD  version of 0.2.0 but will soon be upgraded to
the 0.3.0 release.

Is it possible to have the consumer and producer laptops on the same subnet as REMAP
to try to come as close as possible to your current configuration?

If we can repeat the problem with installed Testbed nodes it might make it easier
for others to replicate the problem at their sites.

I?ll hold off on upgrades of Testbed nodes while we discuss our options.

John

On Feb 8, 2015, at 12:53 PM, Burke, Jeff <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>> wrote:


Hi Junxiao,

I don't agree ? unless the NFD team is aware of a change in the codebase that would potentially fix this problem, and you can selectively apply only those changes as a patch, to see if they fix the problem, simply upgrading provides no information on the root cause.  Thus, we may eliminate the symptom without understanding where it comes from or knowing when it might come back.

Given our goal of having this system work "well enough" to use in real meetings, etc. and to do large-scale demos with WUSTL, simply eliminating the symptom is insufficient.

Simplest way to find the root cause is to debug in the current, deployed system.

A hybrid approach is to substitute an NFD 0.3 forwarder (on a different, identical box) as the hub and see if fixes the problem. This might inform which commits to apply/roll back in the testing process.   But, somehow, we should try methodically to find out why this occurs.

We can provide additional hardware configure per the above, if you'd like.  But we need the NFD team to engage with debugging the current running code on the hub.  This will be more productive and more likely to get to the root cause than having us make further changes to the setup.

Thanks,
Jeff

From: Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>
Date: Sun, 8 Feb 2015 11:42:25 -0700
To: Jeff Burke <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>>
Cc: "Gusev, Peter" <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>>, "nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>" <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: Re: [Nfd-dev] NDN-RTC: NFD processing logs

Hi Jeff

In any case the delay isn't in forwarding pipelines or strategy according to logs.
@Davide is expert on faces and related libraries, and he agreed to determine whether the problem is in UdpFace or a lower layer.

Debugging this problem doesn't depend on new Ubuntu port.
However, upgrading NFD to latest git-HEAD version is necessary for bug reports, because this problem may have been fixed already and it's wasting time trying to debug an older version.
After upgrading NFD and confirming it still exists, please officially file the bug on NFD Redmine site.

Yours, Junxiao

On Sun, Feb 8, 2015 at 11:33 AM, Burke, Jeff <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>> wrote:
Junxiao & all,

I want to strongly advocate for debugging the actual, running system that we have now, rather than waiting for new code and using  another setup that may or may not exhibit the same problem.

Would it be possible to work with the system in situ with remote access rather than waiting on the ubuntu headless build? (Alternatively, I would rather host you at UCLA for a week, or fedex you our Mac test machines, than write new application that just attempts to replicate the problem.

What Peter was referring to is an Ubuntu port of ndnrtc that will generate the same type of traffic, not a simulator. We need this for testbed deployment.  However, this work is not done yet, and we are trying to move quickly to real world use, and I really don't think we should make this dependent on further app development work.

Thank you,
Jeff

Hi Peter

On Feb 05 we identified a few possible places that can cause delay:

  *   network
  *   kernel
  *   C++ memory allocator
  *   Boost.Asio
  *   UdpFace or its base class DatagramFace

The logs you gathered appear to be complete according to what we requested.
@Davide, can you gain some insights from the logs?


Regarding the 30-second interval pattern discovered by John: the only 30-second interval I know of in NFD is UDP face idle_timeout, when this option is unset in nfd.conf.
Every 30 seconds, UdpChannel will enumerate all its faces, and close all faces that haven't received anything. There's no evidence that any face is created, because FaceIds are consistent throughout the logs. However this scheduled event will take some CPU time, but I don't believe it can cause a delay of more than 5ms.
To rule out this possibility, adjust face_system.udp.idle_timeout option in nfd.conf (to "50"), and test again.


>From an earlier log snippet, I notice that the NFD version you are running is older than September 2014.
Please use git-HEAD version for any bug reports.


As you told me on Feb 05, you will create a traffic simulator that can have same traffic pattern as NdnCon that can run on headless Ubuntu servers.
I'll be able to test on controlled environment when that tool becomes available.

Yours, Junxiao

On Fri, Feb 6, 2015 at 4:14 PM, Gusev, Peter <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>> wrote:
Hi guys,

So I?ve run setup today and gathered logs.
I?ve setup NFDs with the following settings
...
 default_level NONE
 Forwarder DEBUG
 UdpFace TRACE
?

And then I run tcpdump on each machine like this:
$ sudo tcpdump -w ~/dump.pcap -i en4 udp port 6363

Here is the summary on ?problematic? packets:
https://docs.google.com/document/d/11JAPHI6J4jD6mibMRuWd1EvzP-NY_F2osM2vDF2VaGM/edit?usp=sharing

All the log files and tcpdumps you can find here:
https://www.dropbox.com/s/1d277xbhqs97o66/logs.zip?dl=0

Thanks for all the help!

Thanks,

--
Peter Gusev
Programmer/Analyst @ REMAP, UCLA

peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>
+1 213 5872748<tel:%2B1%20213%205872748>
peetonn_ (skype)

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

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

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

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

From josh at caida.org  Tue Feb 10 11:07:14 2015
From: josh at caida.org (Josh Polterock)
Date: Tue, 10 Feb 2015 11:07:14 -0800
Subject: [Nfd-dev] Error installing nfd @0.3.0_0 on Mac OSX 10.9.5
Message-ID: <20150210190714.GV72603@caida.org>

I'm trying to do a completely clean install of NFD using ports. 
The ndn-cxx install completed successfully. The NFD install 
completes but finishes with the following error 

--->  Computing dependencies for nfd
--->  Fetching archive for nfd
--->  Attempting to fetch nfd-0.3.0_0.darwin_13.x86_64.tbz2 from http://packages.macports.org/nfd
--->  Attempting to fetch nfd-0.3.0_0.darwin_13.x86_64.tbz2 from http://nue.de.packages.macports.org/macports/packages/nfd
--->  Attempting to fetch nfd-0.3.0_0.darwin_13.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/nfd
--->  Fetching distfiles for nfd
--->  Attempting to fetch NFD-NFD-0.3.0.tar.gz from http://distfiles.macports.org/nfd
--->  Attempting to fetch NFD-NFD-0.3.0.tar.gz from http://sea.us.distfiles.macports.org/macports/distfiles/nfd
--->  Attempting to fetch NFD-NFD-0.3.0.tar.gz from https://github.com/named-data/NFD/tarball/NFD-0.3.0
--->  Verifying checksums for nfd                                                            
--->  Extracting nfd
--->  Configuring nfd
--->  Building nfd
--->  Staging nfd into destroot
--->  Installing nfd @0.3.0_0
--->  Activating nfd @0.3.0_0


To start NFD and ensure it is started when system boots:

    nfd-start

To stop NFD and disable auto-start when system boots:

    nfd-stop

NFD log files are located in /opt/local/var/log/ndn/

Configuration file is in /opt/local/var/etc/ndn/

Error: org.macports.activate for port nfd returned: command execution
failed
Please see the log file for port nfd for details:
    /opt/local/var/macports/logs/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/main.log
To report a bug, follow the instructions in the guide:
    http://guide.macports.org/#project.tickets
Error: Processing of port nfd failed



From shijunxiao at email.arizona.edu  Tue Feb 10 11:31:06 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Tue, 10 Feb 2015 12:31:06 -0700
Subject: [Nfd-dev] Error installing nfd @0.3.0_0 on Mac OSX 10.9.5
In-Reply-To: <20150210190714.GV72603@caida.org>
References: <20150210190714.GV72603@caida.org>
Message-ID: <54da5c86.658f340a.66c9.067e@mx.google.com>

Hi Josh

Please attach /opt/local/var/macports/logs/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/main.log file so we can see what's happening.


Yours, Junxiao

-----Original Message-----
From: "Josh Polterock" <josh at caida.org>
Sent: ?2/?10/?2015 12:07
To: "nfd-dev at lists.cs.ucla.edu" <nfd-dev at lists.cs.ucla.edu>
Subject: [Nfd-dev] Error installing nfd @0.3.0_0 on Mac OSX 10.9.5

I'm trying to do a completely clean install of NFD using ports. 
The ndn-cxx install completed successfully. The NFD install 
completes but finishes with the following error 

--->  Computing dependencies for nfd
--->  Fetching archive for nfd
--->  Attempting to fetch nfd-0.3.0_0.darwin_13.x86_64.tbz2 from http://packages.macports.org/nfd
--->  Attempting to fetch nfd-0.3.0_0.darwin_13.x86_64.tbz2 from http://nue.de.packages.macports.org/macports/packages/nfd
--->  Attempting to fetch nfd-0.3.0_0.darwin_13.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/nfd
--->  Fetching distfiles for nfd
--->  Attempting to fetch NFD-NFD-0.3.0.tar.gz from http://distfiles.macports.org/nfd
--->  Attempting to fetch NFD-NFD-0.3.0.tar.gz from http://sea.us.distfiles.macports.org/macports/distfiles/nfd
--->  Attempting to fetch NFD-NFD-0.3.0.tar.gz from https://github.com/named-data/NFD/tarball/NFD-0.3.0
--->  Verifying checksums for nfd                                                            
--->  Extracting nfd
--->  Configuring nfd
--->  Building nfd
--->  Staging nfd into destroot
--->  Installing nfd @0.3.0_0
--->  Activating nfd @0.3.0_0


To start NFD and ensure it is started when system boots:

    nfd-start

To stop NFD and disable auto-start when system boots:

    nfd-stop

NFD log files are located in /opt/local/var/log/ndn/

Configuration file is in /opt/local/var/etc/ndn/

Error: org.macports.activate for port nfd returned: command execution
failed
Please see the log file for port nfd for details:
    /opt/local/var/macports/logs/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/main.log
To report a bug, follow the instructions in the guide:
    http://guide.macports.org/#project.tickets
Error: Processing of port nfd failed

_______________________________________________
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/20150210/b8bdf071/attachment.html>

From josh at caida.org  Tue Feb 10 11:41:37 2015
From: josh at caida.org (Josh Polterock)
Date: Tue, 10 Feb 2015 11:41:37 -0800
Subject: [Nfd-dev] Error installing nfd @0.3.0_0 on Mac OSX 10.9.5
In-Reply-To: <54da5c86.658f340a.66c9.067e@mx.google.com>
References: <20150210190714.GV72603@caida.org>
	<54da5c86.658f340a.66c9.067e@mx.google.com>
Message-ID: <20150210194137.GX72603@caida.org>

Please find main.log attached.

Thanks,
Josh

On Tue, Feb 10, 2015 at 12:31:06PM -0700, Junxiao Shi wrote:
> Hi Josh
> 
> Please attach /opt/local/var/macports/logs/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/main.log file so we can see what's happening.
> 
> 
> Yours, Junxiao
> 
> -----Original Message-----
> From: "Josh Polterock" <josh at caida.org>
> Sent: ???2/???10/???2015 12:07
> To: "nfd-dev at lists.cs.ucla.edu" <nfd-dev at lists.cs.ucla.edu>
> Subject: [Nfd-dev] Error installing nfd @0.3.0_0 on Mac OSX 10.9.5
> 
> I'm trying to do a completely clean install of NFD using ports. 
> The ndn-cxx install completed successfully. The NFD install 
> completes but finishes with the following error 
> 
> --->  Computing dependencies for nfd
> --->  Fetching archive for nfd
> --->  Attempting to fetch nfd-0.3.0_0.darwin_13.x86_64.tbz2 from http://packages.macports.org/nfd
> --->  Attempting to fetch nfd-0.3.0_0.darwin_13.x86_64.tbz2 from http://nue.de.packages.macports.org/macports/packages/nfd
> --->  Attempting to fetch nfd-0.3.0_0.darwin_13.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/nfd
> --->  Fetching distfiles for nfd
> --->  Attempting to fetch NFD-NFD-0.3.0.tar.gz from http://distfiles.macports.org/nfd
> --->  Attempting to fetch NFD-NFD-0.3.0.tar.gz from http://sea.us.distfiles.macports.org/macports/distfiles/nfd
> --->  Attempting to fetch NFD-NFD-0.3.0.tar.gz from https://github.com/named-data/NFD/tarball/NFD-0.3.0
> --->  Verifying checksums for nfd                                                            
> --->  Extracting nfd
> --->  Configuring nfd
> --->  Building nfd
> --->  Staging nfd into destroot
> --->  Installing nfd @0.3.0_0
> --->  Activating nfd @0.3.0_0
> 
> 
> To start NFD and ensure it is started when system boots:
> 
>     nfd-start
> 
> To stop NFD and disable auto-start when system boots:
> 
>     nfd-stop
> 
> NFD log files are located in /opt/local/var/log/ndn/
> 
> Configuration file is in /opt/local/var/etc/ndn/
> 
> Error: org.macports.activate for port nfd returned: command execution
> failed
> Please see the log file for port nfd for details:
>     /opt/local/var/macports/logs/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/main.log
> To report a bug, follow the instructions in the guide:
>     http://guide.macports.org/#project.tickets
> Error: Processing of port nfd failed
> 
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
-------------- next part --------------
version:1
:debug:main epoch: in tree: 0 installed: 0
:debug:main pkgconfig 0.28_0 exists in the ports tree
:debug:main pkgconfig 0.28_0  is the latest installed
:debug:main pkgconfig 0.28_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/devel/pkgconfig
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main adding the default universal variant
:debug:main Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/variant_descriptions.conf
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! pkgconfig 0.28_0 >= pkgconfig 0.28_0
:debug:main epoch: in tree: 0 installed: 0
:debug:main libiconv 1.14_0 exists in the ports tree
:debug:main libiconv 1.14_0  is the latest installed
:debug:main libiconv 1.14_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/textproc/libiconv
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/variant_descriptions.conf
:debug:main Sourcing PortGroup muniversal 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/muniversal-1.0.tcl
:debug:main universal variant already exists, so not adding the default one
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! libiconv 1.14_0 >= libiconv 1.14_0
:debug:main epoch: in tree: 0 installed: 0
:debug:main py27-sphinx 1.2.3_0 exists in the ports tree
:debug:main py27-sphinx 1.2.3_0  is the latest installed
:debug:main py27-sphinx 1.2.3_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/python/py-sphinx
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main Re-registering default for build.cmd
:debug:main Re-registering default for destroot.cmd
:debug:main Re-registering default for destroot.destdir
:debug:main Sourcing PortGroup python 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/python-1.0.tcl
:debug:main Sourcing PortGroup select 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/select-1.0.tcl
:debug:main only one arch supported, so not adding the default universal variant
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! py27-sphinx 1.2.3_0 >= py27-sphinx 1.2.3_0
:debug:main epoch: in tree: 0 installed: 0
:debug:main py27-docutils 0.12_0 exists in the ports tree
:debug:main py27-docutils 0.12_0  is the latest installed
:debug:main py27-docutils 0.12_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/python/py-docutils
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main Re-registering default for build.cmd
:debug:main Re-registering default for destroot.cmd
:debug:main Re-registering default for destroot.destdir
:debug:main Sourcing PortGroup python 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/python-1.0.tcl
:debug:main only one arch supported, so not adding the default universal variant
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! py27-docutils 0.12_0 >= py27-docutils 0.12_0
:debug:main epoch: in tree: 0 installed: 0
:debug:main py27-roman 2.0.0_0 exists in the ports tree
:debug:main py27-roman 2.0.0_0  is the latest installed
:debug:main py27-roman 2.0.0_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/python/py-roman
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main Re-registering default for build.cmd
:debug:main Re-registering default for destroot.cmd
:debug:main Re-registering default for destroot.destdir
:debug:main Sourcing PortGroup python 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/python-1.0.tcl
:debug:main only one arch supported, so not adding the default universal variant
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! py27-roman 2.0.0_0 >= py27-roman 2.0.0_0
:debug:main epoch: in tree: 2 installed: 2
:debug:main python27 2.7.9_0 exists in the ports tree
:debug:main python27 2.7.9_0  is the latest installed
:debug:main python27 2.7.9_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/lang/python27
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main Sourcing PortGroup select 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/select-1.0.tcl
:debug:main Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/variant_descriptions.conf
:debug:main universal variant already exists, so not adding the default one
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! python27 2.7.9_0 >= python27 2.7.9_0
:debug:main epoch: in tree: 2 installed: 2
:debug:main gettext 0.19.4_0 exists in the ports tree
:debug:main gettext 0.19.4_0  is the latest installed
:debug:main gettext 0.19.4_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/devel/gettext
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main Sourcing PortGroup compiler_blacklist_versions 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/compiler_blacklist_versions-1.0.tcl
:debug:main Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/variant_descriptions.conf
:debug:main Sourcing PortGroup muniversal 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/muniversal-1.0.tcl
:debug:main compiler clang 600.0.56 not blacklisted because it doesn't match {clang < 211.10.1}
:debug:main universal variant already exists, so not adding the default one
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! gettext 0.19.4_0 >= gettext 0.19.4_0
:debug:main epoch: in tree: 0 installed: 0
:debug:main expat 2.1.0_0 exists in the ports tree
:debug:main expat 2.1.0_0  is the latest installed
:debug:main expat 2.1.0_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/textproc/expat
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main adding the default universal variant
:debug:main Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/variant_descriptions.conf
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! expat 2.1.0_0 >= expat 2.1.0_0
:debug:main epoch: in tree: 0 installed: 0
:debug:main ncurses 5.9_2 exists in the ports tree
:debug:main ncurses 5.9_2  is the latest installed
:debug:main ncurses 5.9_2  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/devel/ncurses
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main adding the default universal variant
:debug:main Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/variant_descriptions.conf
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! ncurses 5.9_2 >= ncurses 5.9_2
:debug:main epoch: in tree: 0 installed: 0
:debug:main zlib 1.2.8_0 exists in the ports tree
:debug:main zlib 1.2.8_0  is the latest installed
:debug:main zlib 1.2.8_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/archivers/zlib
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main Sourcing PortGroup xcodeversion 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/xcodeversion-1.0.tcl
:debug:main adding the default universal variant
:debug:main Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/variant_descriptions.conf
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! zlib 1.2.8_0 >= zlib 1.2.8_0
:debug:main epoch: in tree: 1 installed: 1
:debug:main openssl 1.0.2_0 exists in the ports tree
:debug:main openssl 1.0.2_0  is the latest installed
:debug:main openssl 1.0.2_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/devel/openssl
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/variant_descriptions.conf
:debug:main Sourcing PortGroup muniversal 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/muniversal-1.0.tcl
:debug:main universal variant already exists, so not adding the default one
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! openssl 1.0.2_0 >= openssl 1.0.2_0
:debug:main epoch: in tree: 0 installed: 0
:debug:main sqlite3 3.8.8.2_0 exists in the ports tree
:debug:main sqlite3 3.8.8.2_0  is the latest installed
:debug:main sqlite3 3.8.8.2_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/databases/sqlite3
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main adding the default universal variant
:debug:main Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/variant_descriptions.conf
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! sqlite3 3.8.8.2_0 >= sqlite3 3.8.8.2_0
:debug:main epoch: in tree: 20090923 installed: 20090923
:debug:main libedit 20140620-3.1_0 exists in the ports tree
:debug:main libedit 20140620-3.1_0  is the latest installed
:debug:main libedit 20140620-3.1_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/devel/libedit
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/variant_descriptions.conf
:debug:main Sourcing PortGroup muniversal 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/muniversal-1.0.tcl
:debug:main universal variant already exists, so not adding the default one
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! libedit 20140620-3.1_0 >= libedit 20140620-3.1_0
:debug:main epoch: in tree: 0 installed: 0
:debug:main db48 4.8.30_4 exists in the ports tree
:debug:main db48 4.8.30_4  is the latest installed
:debug:main db48 4.8.30_4  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/databases/db48
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/variant_descriptions.conf
:debug:main Sourcing PortGroup muniversal 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/muniversal-1.0.tcl
:debug:main Sourcing PortGroup select 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/select-1.0.tcl
:debug:main universal variant already exists, so not adding the default one
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! db48 4.8.30_4 >= db48 4.8.30_4
:debug:main epoch: in tree: 0 installed: 0
:debug:main db_select 0.1_2 exists in the ports tree
:debug:main db_select 0.1_2  is the latest installed
:debug:main db_select 0.1_2  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/sysutils/db_select
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main Sourcing PortGroup select 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/select-1.0.tcl
:debug:main universal_variant is false, so not adding the default universal variant
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! db_select 0.1_2 >= db_select 0.1_2
:debug:main epoch: in tree: 0 installed: 0
:debug:main bzip2 1.0.6_0 exists in the ports tree
:debug:main bzip2 1.0.6_0  is the latest installed
:debug:main bzip2 1.0.6_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/archivers/bzip2
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/variant_descriptions.conf
:debug:main universal variant already exists, so not adding the default one
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! bzip2 1.0.6_0 >= bzip2 1.0.6_0
:debug:main epoch: in tree: 0 installed: 0
:debug:main python_select 0.3_4 exists in the ports tree
:debug:main python_select 0.3_4  is the latest installed
:debug:main python_select 0.3_4  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/sysutils/python_select
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main Sourcing PortGroup select 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/select-1.0.tcl
:debug:main universal_variant is false, so not adding the default universal variant
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! python_select 0.3_4 >= python_select 0.3_4
:debug:main epoch: in tree: 0 installed: 0
:debug:main py27-setuptools 12.0.3_0 exists in the ports tree
:debug:main py27-setuptools 12.0.3_0  is the latest installed
:debug:main py27-setuptools 12.0.3_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/python/py-setuptools
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main Re-registering default for build.cmd
:debug:main Re-registering default for destroot.cmd
:debug:main Re-registering default for destroot.destdir
:debug:main Sourcing PortGroup python 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/python-1.0.tcl
:debug:main only one arch supported, so not adding the default universal variant
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! py27-setuptools 12.0.3_0 >= py27-setuptools 12.0.3_0
:debug:main epoch: in tree: 0 installed: 0
:debug:main py27-pygments 2.0.2_0 exists in the ports tree
:debug:main py27-pygments 2.0.2_0  is the latest installed
:debug:main py27-pygments 2.0.2_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/python/py-pygments
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main Re-registering default for build.cmd
:debug:main Re-registering default for destroot.cmd
:debug:main Re-registering default for destroot.destdir
:debug:main Sourcing PortGroup python 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/python-1.0.tcl
:debug:main only one arch supported, so not adding the default universal variant
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! py27-pygments 2.0.2_0 >= py27-pygments 2.0.2_0
:debug:main epoch: in tree: 0 installed: 0
:debug:main py27-jinja2 2.7.3_0 exists in the ports tree
:debug:main py27-jinja2 2.7.3_0  is the latest installed
:debug:main py27-jinja2 2.7.3_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/python/py-jinja2
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main Re-registering default for build.cmd
:debug:main Re-registering default for destroot.cmd
:debug:main Re-registering default for destroot.destdir
:debug:main Sourcing PortGroup python 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/python-1.0.tcl
:debug:main only one arch supported, so not adding the default universal variant
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! py27-jinja2 2.7.3_0 >= py27-jinja2 2.7.3_0
:debug:main epoch: in tree: 0 installed: 0
:debug:main py27-markupsafe 0.23_0 exists in the ports tree
:debug:main py27-markupsafe 0.23_0  is the latest installed
:debug:main py27-markupsafe 0.23_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/python/py-markupsafe
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main Re-registering default for build.cmd
:debug:main Re-registering default for destroot.cmd
:debug:main Re-registering default for destroot.destdir
:debug:main Sourcing PortGroup python 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/python-1.0.tcl
:debug:main adding the default universal variant
:debug:main Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/variant_descriptions.conf
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! py27-markupsafe 0.23_0 >= py27-markupsafe 0.23_0
:debug:main epoch: in tree: 0 installed: 0
:debug:main sphinx_select 0.1_0 exists in the ports tree
:debug:main sphinx_select 0.1_0  is the latest installed
:debug:main sphinx_select 0.1_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/python/sphinx_select
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main Sourcing PortGroup select 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/select-1.0.tcl
:debug:main universal_variant is false, so not adding the default universal variant
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! sphinx_select 0.1_0 >= sphinx_select 0.1_0
:debug:main epoch: in tree: 3 installed: 3
:debug:main ndn-cxx 0.3.0_0 exists in the ports tree
:debug:main ndn-cxx 0.3.0_0  is the latest installed
:debug:main ndn-cxx 0.3.0_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/macports.named-data.net/macports/net/ndn-cxx
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main Sourcing PortGroup github 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/github-1.0.tcl
:debug:main adding the default universal variant
:debug:main Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/variant_descriptions.conf
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! ndn-cxx 0.3.0_0 >= ndn-cxx 0.3.0_0
:debug:main epoch: in tree: 0 installed: 0
:debug:main boost 1.57.0_0 exists in the ports tree
:debug:main boost 1.57.0_0 +no_single+no_static+python27 is the latest installed
:debug:main boost 1.57.0_0 +no_single+no_static+python27 is active
:debug:main Merging existing variants '+no_single+no_static+python27' into variants
:debug:main new fully merged portvariants: no_static + no_single + python27 +
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/devel/boost
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main Sourcing PortGroup compiler_blacklist_versions 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/compiler_blacklist_versions-1.0.tcl
:debug:main Sourcing PortGroup active_variants 1.1 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/active_variants-1.1.tcl
:debug:main Sourcing PortGroup compilers 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/compilers-1.0.tcl
:debug:main Sourcing PortGroup mpi 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/mpi-1.0.tcl
:debug:main compiler clang 600.0.56 not blacklisted because it doesn't match {clang < 421}
:debug:main Unmatched blacklisted compiler: macports-clang-2.9
:debug:main Unmatched blacklisted compiler: *gcc-4.0
:debug:main Unmatched blacklisted compiler: gcc-3.3
:debug:main Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/variant_descriptions.conf
:debug:main universal variant already exists, so not adding the default one
:debug:main Executing variant python27 provides python27
:debug:main Executing variant no_static provides no_static
:debug:main Executing variant no_single provides no_single
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! boost 1.57.0_0 >= boost 1.57.0_0
:debug:main epoch: in tree: 0 installed: 0
:debug:main icu 54.1_0 exists in the ports tree
:debug:main icu 54.1_0  is the latest installed
:debug:main icu 54.1_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/devel/icu
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/variant_descriptions.conf
:debug:main Sourcing PortGroup muniversal 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/muniversal-1.0.tcl
:debug:main universal variant already exists, so not adding the default one
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! icu 54.1_0 >= icu 54.1_0
:debug:main epoch: in tree: 0 installed: 0
:debug:main libcryptopp 5.6.2_0 exists in the ports tree
:debug:main libcryptopp 5.6.2_0  is the latest installed
:debug:main libcryptopp 5.6.2_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/devel/libcryptopp
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/variant_descriptions.conf
:debug:main universal variant already exists, so not adding the default one
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! libcryptopp 5.6.2_0 >= libcryptopp 5.6.2_0
:debug:main epoch: in tree: 0 installed: 0
:debug:main libpcap 1.6.2_0 exists in the ports tree
:debug:main libpcap 1.6.2_0  is the latest installed
:debug:main libpcap 1.6.2_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/net/libpcap
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main adding the default universal variant
:debug:main Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/variant_descriptions.conf
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! libpcap 1.6.2_0 >= libpcap 1.6.2_0
:msg:main --->  Computing dependencies for nfd:info:main .:debug:main nfd has no conflicts
:debug:main Searching for dependency: pkgconfig
:debug:main Found Dependency: receipt exists for pkgconfig
:debug:main Searching for dependency: py27-sphinx
:debug:main Found Dependency: receipt exists for py27-sphinx
:debug:main Searching for dependency: ndn-cxx
:debug:main Found Dependency: receipt exists for ndn-cxx
:debug:main Searching for dependency: libpcap
:debug:main Found Dependency: receipt exists for libpcap
:msg:main 
:debug:main Executing org.macports.main (nfd)
:debug:main changing euid/egid - current euid: 0 - current egid: 0
:debug:main egid changed to: 501
:debug:main euid changed to: 501
:debug:archivefetch archivefetch phase started at Tue Feb 10 10:59:27 PST 2015
:msg:archivefetch --->  Fetching archive for nfd
:debug:archivefetch Executing org.macports.archivefetch (nfd)
:debug:archivefetch euid/egid changed to: 0/0
:debug:archivefetch chowned /opt/local/var/macports/incoming to macports
:debug:archivefetch euid/egid changed to: 501/501
:info:archivefetch --->  nfd-0.3.0_0.darwin_13.x86_64.tbz2 doesn't seem to exist in /opt/local/var/macports/incoming/verified
:msg:archivefetch --->  Attempting to fetch nfd-0.3.0_0.darwin_13.x86_64.tbz2 from http://packages.macports.org/nfd
:debug:archivefetch Fetching archive failed:: The requested URL returned error: 404 Not Found
:msg:archivefetch --->  Attempting to fetch nfd-0.3.0_0.darwin_13.x86_64.tbz2 from http://nue.de.packages.macports.org/macports/packages/nfd
:debug:archivefetch Fetching archive failed:: The requested URL returned error: 404 Not Found
:msg:archivefetch --->  Attempting to fetch nfd-0.3.0_0.darwin_13.x86_64.tbz2 from http://mse.uk.packages.macports.org/sites/packages.macports.org/nfd
:debug:archivefetch Fetching archive failed:: The requested URL returned error: 404 Not Found
:debug:archivefetch Privilege de-escalation not attempted as not running as root.
:debug:fetch fetch phase started at Tue Feb 10 10:59:29 PST 2015
:notice:fetch --->  Fetching distfiles for nfd
:debug:fetch Executing org.macports.fetch (nfd)
:info:fetch --->  NFD-NFD-0.3.0.tar.gz doesn't seem to exist in /opt/local/var/macports/distfiles/nfd
:notice:fetch --->  Attempting to fetch NFD-NFD-0.3.0.tar.gz from http://distfiles.macports.org/nfd
:debug:fetch Fetching distfile failed: The requested URL returned error: 404 Not Found
:notice:fetch --->  Attempting to fetch NFD-NFD-0.3.0.tar.gz from http://sea.us.distfiles.macports.org/macports/distfiles/nfd
:debug:fetch Fetching distfile failed: The requested URL returned error: 404 Not Found
:notice:fetch --->  Attempting to fetch NFD-NFD-0.3.0.tar.gz from https://github.com/named-data/NFD/tarball/NFD-0.3.0
:debug:fetch Privilege de-escalation not attempted as not running as root.
:debug:checksum checksum phase started at Tue Feb 10 10:59:31 PST 2015
:notice:checksum --->  Verifying checksums for nfd
:debug:checksum Executing org.macports.checksum (nfd)
:info:checksum --->  Checksumming NFD-NFD-0.3.0.tar.gz
:debug:checksum Calculated (rmd160) is 1adfd25be1889ff0fa0073fcab1b9f6b82371ba0
:debug:checksum Correct (rmd160) checksum for NFD-NFD-0.3.0.tar.gz
:debug:checksum Calculated (sha256) is 695274851fa3b9c0b17cc2e16ff00259749bae35ef429c5a90400f93b3daf6a0
:debug:checksum Correct (sha256) checksum for NFD-NFD-0.3.0.tar.gz
:debug:checksum Privilege de-escalation not attempted as not running as root.
:debug:extract extract phase started at Tue Feb 10 10:59:31 PST 2015
:notice:extract --->  Extracting nfd
:debug:extract Executing org.macports.extract (nfd)
:info:extract --->  Extracting NFD-NFD-0.3.0.tar.gz
:debug:extract setting option extract.args to '/opt/local/var/macports/distfiles/nfd/NFD-NFD-0.3.0.tar.gz'
:debug:extract Environment: 
CC_PRINT_OPTIONS='YES'
CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/.CC_PRINT_OPTIONS'
CPATH='/opt/local/include'
LIBRARY_PATH='/opt/local/lib'
MACOSX_DEPLOYMENT_TARGET='10.9'
:debug:extract Assembled command: 'cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work" && /usr/bin/gzip -dc '/opt/local/var/macports/distfiles/nfd/NFD-NFD-0.3.0.tar.gz' | /usr/bin/tar -xf -'
:debug:extract Executing command line:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work" && /usr/bin/gzip -dc '/opt/local/var/macports/distfiles/nfd/NFD-NFD-0.3.0.tar.gz' | /usr/bin/tar -xf - 
:debug:extract Executing proc-post-org.macports.extract-extract-0
:debug:extract changing euid/egid - current euid: 0 - current egid: 0
:debug:extract egid changed to: 501
:debug:extract euid changed to: 501
:debug:patch patch phase started at Tue Feb 10 10:59:32 PST 2015
:debug:patch Executing org.macports.patch (nfd)
:debug:patch Privilege de-escalation not attempted as not running as root.
:debug:configure configure phase started at Tue Feb 10 10:59:32 PST 2015
:notice:configure --->  Configuring nfd
:debug:configure Using compiler 'Xcode Clang'
:debug:configure Executing proc-pre-org.macports.configure-configure-0
:info:configure   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
:info:configure                                  Dload  Upload   Total   Spent    Left  Speed
:info:configure 
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100   168    0   168    0     0    429      0 --:--:-- --:--:-- --:--:--   431
:info:configure 
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100  612k    0  612k    0     0   361k      0 --:--:--  0:00:01 --:--:--  670k
:debug:configure Executing org.macports.configure (nfd)
:debug:configure Environment: 
CC='/usr/bin/clang'
CC_PRINT_OPTIONS='YES'
CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/.CC_PRINT_OPTIONS'
CFLAGS='-pipe -Os -arch x86_64'
CPATH='/opt/local/include'
CPPFLAGS='-I/opt/local/include'
CXX='/usr/bin/clang++'
CXXFLAGS='-pipe -Os -std=c++11 -arch x86_64 -stdlib=libc++'
F77FLAGS='-m64'
F90FLAGS='-pipe -Os -m64'
FCFLAGS='-pipe -Os -m64'
FFLAGS='-pipe -Os'
INSTALL='/usr/bin/install -c'
LDFLAGS='-L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64'
LIBRARY_PATH='/opt/local/lib'
MACOSX_DEPLOYMENT_TARGET='10.9'
OBJC='/usr/bin/clang'
OBJCFLAGS='-pipe -Os -arch x86_64'
OBJCXX='/usr/bin/clang++'
OBJCXXFLAGS='-pipe -Os -arch x86_64 -stdlib=libc++'
SPHINX_BUILD='/opt/local/bin/sphinx-build-2.7'
:debug:configure Assembled command: 'cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/NFD-NFD-0.3.0" && ./waf configure --prefix=/opt/local'
:debug:configure Executing command line:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/NFD-NFD-0.3.0" && ./waf configure --prefix=/opt/local 
:info:configure Setting top to                           : /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/NFD-NFD-0.3.0 
:info:configure Setting out to                           : /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/NFD-NFD-0.3.0/build 
:info:configure Checking for 'clang++' (C++ compiler)    : /usr/bin/clang++ 
:info:configure Checking supported CXXFLAGS              : -std=c++11 -Wno-error=unneeded-internal-declaration -Wno-error=deprecated-register -stdlib=libc++ 
:info:configure Checking supported LINKFLAGS             : -stdlib=libc++ 
:info:configure Checking for program 'doxygen'           : /opt/local/bin/doxygen 
:info:configure Checking for program 'tar'               : /usr/bin/tar 
:info:configure Checking for program 'sphinx-build'      : /opt/local/bin/sphinx-build-2.7 
:info:configure Checking for std::is_default_constructible : yes 
:info:configure Checking for std::is_move_constructible    : yes 
:info:configure Checking for override specifier            : yes 
:info:configure Checking for program 'bash'                : /bin/bash 
:info:configure Checking for program 'pkg-config'          : /opt/local/bin/pkg-config 
:info:configure Checking for 'libndn-cxx'                  : yes 
:info:configure Checking for librt library                 : not found 
:info:configure Checking for libresolv library             : yes 
:info:configure Checking if privilege drop/elevation is supported : yes 
:info:configure Checking for header ifaddrs.h                     : yes 
:info:configure Checking boost includes                           : 1.57.0 
:info:configure Checking boost libs                               : ok 
:info:configure Checking for boost linkage                        : ok 
:info:configure Checking if Unix sockets are supported            : yes 
:info:configure Checking for WebSocket includes                   : 0.4.0 
:info:configure Checking if Ethernet face support can be enabled  : yes 
:info:configure Checking for libpcap library                      : yes 
:info:configure Checking for function pcap_set_immediate_mode     : yes 
:info:configure 'configure' finished successfully (5.162s)
:debug:configure Privilege de-escalation not attempted as not running as root.
:debug:build build phase started at Tue Feb 10 10:59:40 PST 2015
:notice:build --->  Building nfd
:debug:build Executing org.macports.build (nfd)
:debug:build Environment: 
CC_PRINT_OPTIONS='YES'
CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/.CC_PRINT_OPTIONS'
CPATH='/opt/local/include'
LIBRARY_PATH='/opt/local/lib'
MACOSX_DEPLOYMENT_TARGET='10.9'
:debug:build Assembled command: 'cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/NFD-NFD-0.3.0" && ./waf build'
:debug:build Executing command line:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/NFD-NFD-0.3.0" && ./waf build 
:info:build Waf: Entering directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/NFD-NFD-0.3.0/build'
:info:build fatal: Not a git repository (or any of the parent directories): .git
:info:build Extension 'sphinxcontrib.doxylink' in not available. Some documentation may not build correctly.
:info:build To install, use 
:info:build   sudo pip install sphinxcontrib-doxylink
:info:build [  1/115] Compiling version.hpp.in
:info:build [  2/115] Compiling common.hpp
:info:build [  3/115] Compiling tools/nfd-start.sh
:info:build [  4/115] Compiling tools/nfd-status-http-server.py
:info:build [  5/115] Compiling tools/nfd-stop.sh
:info:build [  6/115] Compiling nfd.conf.sample.in
:info:build [  7/115] Processing sphinx_build [man]: docs/manpages/ndn-autoconfig-server.rst docs/manpages/ndn-autoconfig.rst docs/manpages/ndn-tlv-peek.rst docs/manpages/ndn-tlv-poke.rst docs/manpages/nfd-autoreg.rst docs/manpages/nfd-status-http-server.rst docs/manpages/nfd-status.rst docs/manpages/nfd.rst docs/manpages/nfdc.rst docs/manpages/nrd.rst docs/conf.py -> build/docs/manpages/nfd.1 build/docs/manpages/nrd.1 build/docs/manpages/ndn-autoconfig-server.1 build/docs/manpages/ndn-autoconfig.1 build/docs/manpages/nfdc.1 build/docs/manpages/ndn-tlv-peek.1 build/docs/manpages/ndn-tlv-poke.1 build/docs/manpages/nfd-autoreg.1 build/docs/manpages/nfd-status-http-server.1 build/docs/manpages/nfd-status.1
:info:build 
:info:build Extension 'sphinxcontrib.doxylink' in not available. Some documentation may not build correctly.
:info:build To install, use 
:info:build   sudo pip install sphinxcontrib-doxylink
:info:build 
:info:build [  8/115] Compiling daemon/table/strategy-info-host.cpp
:info:build [  9/115] Compiling daemon/main.cpp
:info:build [ 10/115] Compiling tools/ndn-autoconfig/guess-from-search-domains.cpp
:info:build [ 11/115] Compiling core/network.cpp
:info:build [ 12/115] Compiling core/city-hash.cpp
:info:build [ 13/115] Compiling daemon/fw/rtt-estimator.cpp
:info:build [ 14/115] Compiling daemon/table/cs.cpp
:info:build [ 15/115] Compiling daemon/table/measurements-accessor.cpp
:info:build [ 16/115] Compiling tools/ndn-autoconfig/base.cpp
:info:build [ 17/115] Compiling tools/ndn-tlv-poke.cpp
:info:build [ 18/115] Compiling daemon/table/name-tree-entry.cpp
:info:build [ 19/115] Compiling daemon/table/name-tree.cpp
:info:build [ 20/115] Compiling daemon/fw/broadcast-strategy.cpp
:info:build [ 21/115] Compiling daemon/table/fib-nexthop.cpp
:info:build [ 22/115] Compiling daemon/mgmt/fib-manager.cpp
:info:build [ 23/115] Compiling daemon/face/udp-channel.cpp
:info:build [ 24/115] Compiling daemon/face/face.cpp
:info:build [ 25/115] Compiling daemon/table/dead-nonce-list.cpp
:info:build [ 26/115] Compiling rib/fib-update.cpp
:info:build [ 27/115] Compiling daemon/fw/retransmission-suppression.cpp
:info:build [ 28/115] Compiling daemon/mgmt/strategy-choice-publisher.cpp
:info:build [ 29/115] Compiling daemon/fw/strategy.cpp
:info:build [ 30/115] Compiling core/scheduler.cpp
:info:build [ 31/115] Compiling tools/ndn-autoconfig/base-dns.cpp
:info:build [ 32/115] Compiling daemon/table/strategy-choice-entry.cpp
:info:build [ 33/115] Compiling daemon/face/unix-stream-face.cpp
:info:build [ 34/115] Compiling daemon/mgmt/internal-face.cpp
:info:build [ 35/115] Compiling daemon/mgmt/face-status-publisher.cpp
:info:build [ 36/115] Compiling rib/rib-manager.cpp
:info:build [ 37/115] Compiling daemon/face/multicast-udp-face.cpp
:info:build [ 38/115] Compiling daemon/face/ethernet-face.cpp
:info:build [ 39/115] Compiling daemon/mgmt/manager-base.cpp
:info:build [ 40/115] Compiling daemon/face/ndnlp-slicer.cpp
:info:build [ 41/115] Compiling daemon/table/measurements-entry.cpp
:info:build [ 42/115] Compiling daemon/fw/ncc-strategy.cpp
:info:build [ 43/115] Compiling core/global-io.cpp
:info:build [ 44/115] Compiling tools/nfd-status.cpp
:info:build [ 45/115] Compiling daemon/mgmt/status-server.cpp
:info:build [ 46/115] Compiling daemon/face/unix-stream-channel.cpp
:info:build [ 47/115] Compiling core/random.cpp
:info:build [ 48/115] Compiling core/config-file.cpp
:info:build [ 49/115] Compiling daemon/fw/face-table.cpp
:info:build [ 50/115] Compiling daemon/table/pit-out-record.cpp
:info:build [ 51/115] Compiling daemon/mgmt/command-validator.cpp
:info:build [ 52/115] Compiling daemon/face/tcp-factory.cpp
:info:build [ 53/115] Compiling core/privilege-helper.cpp
:info:build [ 54/115] Compiling daemon/mgmt/tables-config-section.cpp
:info:build [ 55/115] Compiling daemon/face/tcp-channel.cpp
:info:build [ 56/115] Compiling daemon/face/null-face.cpp
:info:build [ 57/115] Compiling daemon/face/channel.cpp
:info:build [ 58/115] Compiling rib/rib-status-publisher.cpp
:info:build [ 59/115] Compiling daemon/table/cs-entry.cpp
:info:build [ 60/115] Compiling rib/rib-entry.cpp
:info:build [ 61/115] Compiling daemon/face/ethernet-factory.cpp
:info:build [ 62/115] Compiling daemon/face/udp-factory.cpp
:info:build [ 63/115] Compiling rib/main.cpp
:info:build [ 64/115] Compiling daemon/fw/access-strategy.cpp
:info:build [ 65/115] Compiling core/network-interface.cpp
:info:build [ 66/115] Compiling daemon/table/pit.cpp
:info:build [ 67/115] Compiling rib/remote-registrator.cpp
:info:build [ 68/115] Compiling daemon/face/unix-stream-factory.cpp
:info:build [ 69/115] Compiling daemon/fw/client-control-strategy.cpp
:info:build [ 70/115] Compiling tools/ndn-autoconfig/guess-from-identity-name.cpp
:info:build [ 71/115] Compiling daemon/face/udp-face.cpp
:info:build [ 72/115] Compiling rib/rib.cpp
:info:build [ 73/115] Compiling daemon/mgmt/strategy-choice-manager.cpp
:info:build [ 74/115] Compiling daemon/mgmt/fib-enumeration-publisher.cpp
:info:build [ 75/115] Compiling daemon/fw/available-strategies.cpp
:info:build [ 76/115] Compiling daemon/fw/forwarder.cpp
:info:build [ 77/115] Compiling tools/nfdc.cpp
:info:build [ 78/115] Compiling core/logger-factory.cpp
:info:build [ 79/115] Compiling daemon/face/ndnlp-parse.cpp
:info:build [ 80/115] Compiling tools/ndn-tlv-peek.cpp
:info:build [ 81/115] Compiling daemon/table/pit-in-record.cpp
:info:build [ 82/115] Compiling daemon/face/websocket-channel.cpp
:info:build [ 83/115] Compiling daemon/face/websocket-factory.cpp
:info:build [ 84/115] Compiling daemon/face/ndnlp-partial-message-store.cpp
:info:build [ 85/115] Compiling daemon/face/ndnlp-sequence-generator.cpp
:info:build [ 86/115] Compiling tools/ndn-autoconfig-server.cpp
:info:build [ 87/115] Compiling daemon/table/pit-face-record.cpp
:info:build [ 88/115] Compiling daemon/face/tcp-face.cpp
:info:build [ 89/115] Compiling tools/ndn-autoconfig/multicast-discovery.cpp
:info:build [ 90/115] Compiling daemon/mgmt/channel-status-publisher.cpp
:info:build [ 91/115] Compiling daemon/mgmt/general-config-section.cpp
:info:build [ 92/115] Compiling daemon/table/measurements.cpp
:info:build [ 93/115] Compiling daemon/face/websocket-face.cpp
:info:build [ 94/115] Compiling daemon/table/pit-entry.cpp
:info:build [ 95/115] Compiling daemon/fw/best-route-strategy.cpp
:info:build [ 96/115] Compiling core/logger.cpp
:info:build [ 97/115] Compiling daemon/mgmt/face-query-status-publisher.cpp
:info:build [ 98/115] Compiling daemon/table/fib.cpp
:info:build [ 99/115] Compiling daemon/mgmt/face-manager.cpp
:info:build [100/115] Compiling daemon/table/cs-skip-list-entry.cpp
:info:build [101/115] Compiling daemon/table/fib-entry.cpp
:info:build [102/115] Compiling tools/ndn-autoconfig/main.cpp
:info:build [103/115] Compiling tools/nfd-autoreg.cpp
:info:build [104/115] Compiling daemon/table/strategy-choice.cpp
:info:build [105/115] Compiling daemon/fw/best-route-strategy2.cpp
:info:build [106/115] Compiling daemon/table/cs-entry-impl.cpp
:info:build [107/115] Linking build/bin/nrd
:info:build [108/115] Linking build/bin/ndn-tlv-peek
:info:build [109/115] Linking build/bin/ndn-autoconfig-server
:info:build [110/115] Linking build/bin/nfd-status
:info:build [111/115] Linking build/bin/ndn-tlv-poke
:info:build [112/115] Linking build/bin/nfdc
:info:build [113/115] Linking build/bin/ndn-autoconfig
:info:build [114/115] Linking build/bin/nfd
:info:build [115/115] Linking build/bin/nfd-autoreg
:info:build Waf: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/NFD-NFD-0.3.0/build'
:info:build 'build' finished successfully (1m18.561s)
:debug:build Privilege de-escalation not attempted as not running as root.
:debug:destroot destroot phase started at Tue Feb 10 11:00:59 PST 2015
:notice:destroot --->  Staging nfd into destroot
:debug:destroot Can't run destroot under sudo without elevated privileges (due to mtree).
:debug:destroot Run destroot without sudo to avoid root privileges.
:debug:destroot Going to escalate privileges back to root.
:debug:destroot euid changed to: 0. egid changed to: 0.
:info:destroot ./usr missing (created)
:info:destroot . missing (directory not created: File exists)
:info:destroot ./Applications missing (created)
:info:destroot ./Developer missing (created)
:info:destroot ./Library missing (created)
:info:destroot ./bin missing (created)
:info:destroot ./etc missing (created)
:info:destroot ./include missing (created)
:info:destroot ./lib missing (created)
:info:destroot ./lib/pkgconfig missing (created)
:info:destroot ./libexec missing (created)
:info:destroot ./sbin missing (created)
:info:destroot ./share missing (created)
:info:destroot ./share/info missing (created)
:info:destroot ./share/man missing (created)
:info:destroot ./share/man/cat1 missing (created)
:info:destroot ./share/man/cat2 missing (created)
:info:destroot ./share/man/cat3 missing (created)
:info:destroot ./share/man/cat4 missing (created)
:info:destroot ./share/man/cat5 missing (created)
:info:destroot ./share/man/cat6 missing (created)
:info:destroot ./share/man/cat7 missing (created)
:info:destroot ./share/man/cat8 missing (created)
:info:destroot ./share/man/cat9 missing (created)
:info:destroot ./share/man/catl missing (created)
:info:destroot ./share/man/catn missing (created)
:info:destroot ./share/man/man1 missing (created)
:info:destroot ./share/man/man2 missing (created)
:info:destroot ./share/man/man3 missing (created)
:info:destroot ./share/man/man4 missing (created)
:info:destroot ./share/man/man5 missing (created)
:info:destroot ./share/man/man6 missing (created)
:info:destroot ./share/man/man7 missing (created)
:info:destroot ./share/man/man8 missing (created)
:info:destroot ./share/man/man9 missing (created)
:info:destroot ./share/man/manl missing (created)
:info:destroot ./share/man/mann missing (created)
:info:destroot ./share/nls missing (created)
:info:destroot ./share/nls/C missing (created)
:info:destroot ./share/nls/af_ZA.ISO8859-1 missing (created)
:info:destroot ./share/nls/af_ZA.ISO8859-15 missing (created)
:info:destroot ./share/nls/bg_BG.CP1251 missing (created)
:info:destroot ./share/nls/cs_CZ.ISO8859-2 missing (created)
:info:destroot ./share/nls/da_DK.ISO8859-1 missing (created)
:info:destroot ./share/nls/da_DK.ISO8859-15 missing (created)
:info:destroot ./share/nls/de_AT.ISO8859-1 missing (created)
:info:destroot ./share/nls/de_AT.ISO8859-15 missing (created)
:info:destroot ./share/nls/de_CH.ISO8859-1 missing (created)
:info:destroot ./share/nls/de_CH.ISO8859-15 missing (created)
:info:destroot ./share/nls/de_DE.ISO8859-1 missing (created)
:info:destroot ./share/nls/de_DE.ISO8859-15 missing (created)
:info:destroot ./share/nls/el_GR.ISO8859-7 missing (created)
:info:destroot ./share/nls/en_AU.ISO8859-1 missing (created)
:info:destroot ./share/nls/en_AU.ISO8859-15 missing (created)
:info:destroot ./share/nls/en_AU.US-ASCII missing (created)
:info:destroot ./share/nls/en_CA.ISO8859-1 missing (created)
:info:destroot ./share/nls/en_CA.ISO8859-15 missing (created)
:info:destroot ./share/nls/en_CA.US-ASCII missing (created)
:info:destroot ./share/nls/en_GB.ISO8859-1 missing (created)
:info:destroot ./share/nls/en_GB.ISO8859-15 missing (created)
:info:destroot ./share/nls/en_GB.US-ASCII missing (created)
:info:destroot ./share/nls/en_NZ.ISO8859-1 missing (created)
:info:destroot ./share/nls/en_NZ.ISO8859-15 missing (created)
:info:destroot ./share/nls/en_NZ.US-ASCII missing (created)
:info:destroot ./share/nls/en_US.ISO8859-1 missing (created)
:info:destroot ./share/nls/en_US.ISO8859-15 missing (created)
:info:destroot ./share/nls/es_ES.ISO8859-1 missing (created)
:info:destroot ./share/nls/es_ES.ISO8859-15 missing (created)
:info:destroot ./share/nls/et_EE.ISO8859-15 missing (created)
:info:destroot ./share/nls/fi_FI.ISO8859-1 missing (created)
:info:destroot ./share/nls/fi_FI.ISO8859-15 missing (created)
:info:destroot ./share/nls/fr_BE.ISO8859-1 missing (created)
:info:destroot ./share/nls/fr_BE.ISO8859-15 missing (created)
:info:destroot ./share/nls/fr_CA.ISO8859-1 missing (created)
:info:destroot ./share/nls/fr_CA.ISO8859-15 missing (created)
:info:destroot ./share/nls/fr_CH.ISO8859-1 missing (created)
:info:destroot ./share/nls/fr_CH.ISO8859-15 missing (created)
:info:destroot ./share/nls/fr_FR.ISO8859-1 missing (created)
:info:destroot ./share/nls/fr_FR.ISO8859-15 missing (created)
:info:destroot ./share/nls/hi_IN.ISCII-DEV missing (created)
:info:destroot ./share/nls/hr_HR.ISO8859-2 missing (created)
:info:destroot ./share/nls/hu_HU.ISO8859-2 missing (created)
:info:destroot ./share/nls/is_IS.ISO8859-1 missing (created)
:info:destroot ./share/nls/is_IS.ISO8859-15 missing (created)
:info:destroot ./share/nls/it_CH.ISO8859-1 missing (created)
:info:destroot ./share/nls/it_CH.ISO8859-15 missing (created)
:info:destroot ./share/nls/it_IT.ISO8859-1 missing (created)
:info:destroot ./share/nls/it_IT.ISO8859-15 missing (created)
:info:destroot ./share/nls/ja_JP.SJIS missing (created)
:info:destroot ./share/nls/ja_JP.eucJP missing (created)
:info:destroot ./share/nls/ko_KR.eucKR missing (created)
:info:destroot ./share/nls/la_LN.ISO8859-1 missing (created)
:info:destroot ./share/nls/la_LN.ISO8859-15 missing (created)
:info:destroot ./share/nls/la_LN.ISO8859-2 missing (created)
:info:destroot ./share/nls/la_LN.ISO8859-4 missing (created)
:info:destroot ./share/nls/la_LN.US-ASCII missing (created)
:info:destroot ./share/nls/lt_LT.ISO8859-4 missing (created)
:info:destroot ./share/nls/nl_BE.ISO8859-1 missing (created)
:info:destroot ./share/nls/nl_BE.ISO8859-15 missing (created)
:info:destroot ./share/nls/nl_NL.ISO8859-1 missing (created)
:info:destroot ./share/nls/nl_NL.ISO8859-15 missing (created)
:info:destroot ./share/nls/no_NO.ISO8859-1 missing (created)
:info:destroot ./share/nls/no_NO.ISO8859-15 missing (created)
:info:destroot ./share/nls/pl_PL.ISO8859-2 missing (created)
:info:destroot ./share/nls/pt_BR.ISO8859-1 missing (created)
:info:destroot ./share/nls/pt_PT.ISO8859-1 missing (created)
:info:destroot ./share/nls/pt_PT.ISO8859-15 missing (created)
:info:destroot ./share/nls/ro_RO.ISO8859-2 missing (created)
:info:destroot ./share/nls/ru_RU.CP866 missing (created)
:info:destroot ./share/nls/ru_RU.ISO8859-5 missing (created)
:info:destroot ./share/nls/ru_RU.KOI8-R missing (created)
:info:destroot ./share/nls/sk_SK.ISO8859-2 missing (created)
:info:destroot ./share/nls/sl_SI.ISO8859-2 missing (created)
:info:destroot ./share/nls/sv_SE.ISO8859-1 missing (created)
:info:destroot ./share/nls/sv_SE.ISO8859-15 missing (created)
:info:destroot ./share/nls/tr_TR.ISO8859-9 missing (created)
:info:destroot ./share/nls/uk_UA.ISO8859-5 missing (created)
:info:destroot ./share/nls/uk_UA.KOI8-U missing (created)
:info:destroot ./share/nls/zh_CN.eucCN missing (created)
:info:destroot ./share/nls/zh_TW.Big5 missing (created)
:info:destroot ./share/skel missing (created)
:info:destroot ./src missing (created)
:info:destroot ./var missing (created)
:info:destroot ./www missing (created)
:debug:destroot Executing org.macports.destroot (nfd)
:debug:destroot Environment: 
CC_PRINT_OPTIONS='YES'
CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/.CC_PRINT_OPTIONS'
CPATH='/opt/local/include'
LIBRARY_PATH='/opt/local/lib'
MACOSX_DEPLOYMENT_TARGET='10.9'
:debug:destroot Assembled command: 'cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/NFD-NFD-0.3.0" && ./waf install --destdir=/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot'
:debug:destroot Executing command line:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/NFD-NFD-0.3.0" && ./waf install --destdir=/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot 
:info:destroot Waf: Entering directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/NFD-NFD-0.3.0/build'
:info:destroot fatal: Not a git repository (or any of the parent directories): .git
:info:destroot Extension 'sphinxcontrib.doxylink' in not available. Some documentation may not build correctly.
:info:destroot To install, use 
:info:destroot   sudo pip install sphinxcontrib-doxylink
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/ndn/nfd-status.xsl (from tools/nfd-status-http-server-files/nfd-status.xsl)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/ndn/reset.css (from tools/nfd-status-http-server-files/reset.css)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/ndn/robots.txt (from tools/nfd-status-http-server-files/robots.txt)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/ndn/style.css (from tools/nfd-status-http-server-files/style.css)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/ndn/text.css (from tools/nfd-status-http-server-files/text.css)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/nfd (from build/bin/nfd)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/nrd (from build/bin/nrd)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/ndn-autoconfig-server (from build/bin/ndn-autoconfig-server)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/ndn-tlv-peek (from build/bin/ndn-tlv-peek)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/ndn-tlv-poke (from build/bin/ndn-tlv-poke)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/nfd-autoreg (from build/bin/nfd-autoreg)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/nfd-status (from build/bin/nfd-status)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/nfdc (from build/bin/nfdc)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/ndn-autoconfig (from build/bin/ndn-autoconfig)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/nfd-start (from build/bin/nfd-start)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/nfd-status-http-server (from build/bin/nfd-status-http-server)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/nfd-stop (from build/bin/nfd-stop)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/etc/ndn/nfd.conf.sample (from build/nfd.conf.sample)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/man//man1/nfd.1 (from build/docs/manpages/nfd.1)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/man//man1/nrd.1 (from build/docs/manpages/nrd.1)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/man//man1/ndn-autoconfig-server.1 (from build/docs/manpages/ndn-autoconfig-server.1)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/man//man1/ndn-autoconfig.1 (from build/docs/manpages/ndn-autoconfig.1)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/man//man1/nfdc.1 (from build/docs/manpages/nfdc.1)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/man//man1/ndn-tlv-peek.1 (from build/docs/manpages/ndn-tlv-peek.1)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/man//man1/ndn-tlv-poke.1 (from build/docs/manpages/ndn-tlv-poke.1)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/man//man1/nfd-autoreg.1 (from build/docs/manpages/nfd-autoreg.1)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/man//man1/nfd-status-http-server.1 (from build/docs/manpages/nfd-status-http-server.1)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/man//man1/nfd-status.1 (from build/docs/manpages/nfd-status.1)
:info:destroot Waf: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/NFD-NFD-0.3.0/build'
:info:destroot 'install' finished successfully (2.262s)
:debug:destroot Executing proc-post-org.macports.destroot-destroot-0
:info:destroot xinstall: mkdir /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/etc/LaunchDaemons
:info:destroot xinstall: mkdir /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/etc/LaunchDaemons/net.named-data.nfd
:info:destroot xinstall: /opt/local/var/macports/sources/macports.named-data.net/macports/net/nfd/files/net.named-data.nfd.plist -> /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/etc/LaunchDaemons/net.named-data.nfd//net.named-data.nfd.plist
:info:destroot xinstall: /opt/local/var/macports/sources/macports.named-data.net/macports/net/nfd/files/net.named-data.nrd.plist -> /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/etc/LaunchDaemons/net.named-data.nfd//net.named-data.nrd.plist
:info:destroot --->  Patching net.named-data.nfd.plist: s|/usr/local|/opt/local|g
:debug:destroot Executing reinplace: /usr/bin/sed s|/usr/local|/opt/local|g < /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/etc/LaunchDaemons/net.named-data.nfd/net.named-data.nfd.plist >@ file10 2>@stderr
:info:destroot --->  Patching net.named-data.nrd.plist: s|/usr/local|/opt/local|g
:debug:destroot Executing reinplace: /usr/bin/sed s|/usr/local|/opt/local|g < /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/etc/LaunchDaemons/net.named-data.nfd/net.named-data.nrd.plist >@ file10 2>@stderr
:info:destroot xinstall: /opt/local/var/macports/sources/macports.named-data.net/macports/net/nfd/files/nfd-start -> /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin//nfd-start
:info:destroot xinstall: /opt/local/var/macports/sources/macports.named-data.net/macports/net/nfd/files/nfd-stop -> /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin//nfd-stop
:debug:destroot Executing portdestroot::destroot_finish
:debug:destroot Fixing glibtool .la files in destroot for nfd
:info:destroot --->  Compressing man pages for nfd
:debug:destroot Scanning man1
:info:destroot man1/ndn-autoconfig-server.1:	   55.4% -- replaced with man1/ndn-autoconfig-server.1.gz
:info:destroot man1/ndn-autoconfig-server.1.gz: changing permissions from 00644 to 00444
:info:destroot man1/ndn-autoconfig.1:	   61.1% -- replaced with man1/ndn-autoconfig.1.gz
:info:destroot man1/ndn-autoconfig.1.gz: changing permissions from 00644 to 00444
:info:destroot man1/ndn-tlv-peek.1:	   57.7% -- replaced with man1/ndn-tlv-peek.1.gz
:info:destroot man1/ndn-tlv-peek.1.gz: changing permissions from 00644 to 00444
:info:destroot man1/ndn-tlv-poke.1:	   55.7% -- replaced with man1/ndn-tlv-poke.1.gz
:info:destroot man1/ndn-tlv-poke.1.gz: changing permissions from 00644 to 00444
:info:destroot man1/nfd-autoreg.1:	   60.5% -- replaced with man1/nfd-autoreg.1.gz
:info:destroot man1/nfd-autoreg.1.gz: changing permissions from 00644 to 00444
:info:destroot man1/nfd-status-http-server.1:	   59.6% -- replaced with man1/nfd-status-http-server.1.gz
:info:destroot man1/nfd-status-http-server.1.gz: changing permissions from 00644 to 00444
:info:destroot man1/nfd-status.1:	   66.0% -- replaced with man1/nfd-status.1.gz
:info:destroot man1/nfd-status.1.gz: changing permissions from 00644 to 00444
:info:destroot man1/nfd.1:	   57.5% -- replaced with man1/nfd.1.gz
:info:destroot man1/nfd.1.gz: changing permissions from 00644 to 00444
:info:destroot man1/nfdc.1:	   72.7% -- replaced with man1/nfdc.1.gz
:info:destroot man1/nfdc.1.gz: changing permissions from 00644 to 00444
:info:destroot man1/nrd.1:	   53.8% -- replaced with man1/nrd.1.gz
:info:destroot man1/nrd.1.gz: changing permissions from 00644 to 00444
:debug:destroot checking for mtree violations
:debug:destroot changing euid/egid - current euid: 0 - current egid: 0
:debug:destroot egid changed to: 501
:debug:destroot euid changed to: 501
:debug:install install phase started at Tue Feb 10 11:01:04 PST 2015
:notice:install --->  Installing nfd @0.3.0_0
:debug:install Can't run install on this port without elevated privileges. Escalating privileges back to root.
:debug:install euid changed to: 0. egid changed to: 0.
:debug:install Executing org.macports.install (nfd)
:debug:install Using /usr/bin/tar
:debug:install Using /usr/bin/bzip2
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/ndn-autoconfig
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/ndn-autoconfig-server
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/ndn-tlv-peek
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/ndn-tlv-poke
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/nfd
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/nfd-autoreg
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/nfd-start
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/nfd-status
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/nfd-status-http-server
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/nfd-stop
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/nfdc
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/nrd
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/etc/LaunchDaemons/net.named-data.nfd/net.named-data.nfd.plist
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/etc/LaunchDaemons/net.named-data.nfd/net.named-data.nrd.plist
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/etc/ndn/nfd.conf.sample
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/man/man1/ndn-autoconfig-server.1.gz
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/man/man1/ndn-autoconfig.1.gz
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/man/man1/ndn-tlv-peek.1.gz
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/man/man1/ndn-tlv-poke.1.gz
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/man/man1/nfd-autoreg.1.gz
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/man/man1/nfd-status-http-server.1.gz
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/man/man1/nfd-status.1.gz
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/man/man1/nfd.1.gz
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/man/man1/nfdc.1.gz
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/man/man1/nrd.1.gz
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/ndn/nfd-status.xsl
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/ndn/reset.css
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/ndn/robots.txt
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/ndn/style.css
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/ndn/text.css
:debug:install Creating nfd-0.3.0_0.darwin_13.x86_64.tbz2
:debug:install Environment: 
CC_PRINT_OPTIONS='YES'
CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/.CC_PRINT_OPTIONS'
CPATH='/opt/local/include'
LIBRARY_PATH='/opt/local/lib'
MACOSX_DEPLOYMENT_TARGET='10.9'
:debug:install Assembled command: 'cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot" && /usr/bin/tar -cvf - . | /usr/bin/bzip2 -c9 > /opt/local/var/macports/software/nfd/nfd-0.3.0_0.darwin_13.x86_64.tbz2'
:debug:install Executing command line:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot" && /usr/bin/tar -cvf - . | /usr/bin/bzip2 -c9 > /opt/local/var/macports/software/nfd/nfd-0.3.0_0.darwin_13.x86_64.tbz2 
:info:install a .
:info:install a ./+COMMENT
:info:install a ./+CONTENTS
:info:install a ./+DESC
:info:install a ./+PORTFILE
:info:install a ./+STATE
:info:install a ./opt
:info:install a ./opt/local
:info:install a ./opt/local/bin
:info:install a ./opt/local/etc
:info:install a ./opt/local/share
:info:install a ./opt/local/share/man
:info:install a ./opt/local/share/ndn
:info:install a ./opt/local/share/ndn/nfd-status.xsl
:info:install a ./opt/local/share/ndn/reset.css
:info:install a ./opt/local/share/ndn/robots.txt
:info:install a ./opt/local/share/ndn/style.css
:info:install a ./opt/local/share/ndn/text.css
:info:install a ./opt/local/share/man/man1
:info:install a ./opt/local/share/man/man1/ndn-autoconfig-server.1.gz
:info:install a ./opt/local/share/man/man1/ndn-autoconfig.1.gz
:info:install a ./opt/local/share/man/man1/ndn-tlv-peek.1.gz
:info:install a ./opt/local/share/man/man1/ndn-tlv-poke.1.gz
:info:install a ./opt/local/share/man/man1/nfd-autoreg.1.gz
:info:install a ./opt/local/share/man/man1/nfd-status-http-server.1.gz
:info:install a ./opt/local/share/man/man1/nfd-status.1.gz
:info:install a ./opt/local/share/man/man1/nfd.1.gz
:info:install a ./opt/local/share/man/man1/nfdc.1.gz
:info:install a ./opt/local/share/man/man1/nrd.1.gz
:info:install a ./opt/local/etc/LaunchDaemons
:info:install a ./opt/local/etc/ndn
:info:install a ./opt/local/etc/ndn/nfd.conf.sample
:info:install a ./opt/local/etc/LaunchDaemons/net.named-data.nfd
:info:install a ./opt/local/etc/LaunchDaemons/net.named-data.nfd/net.named-data.nfd.plist
:info:install a ./opt/local/etc/LaunchDaemons/net.named-data.nfd/net.named-data.nrd.plist
:info:install a ./opt/local/bin/ndn-autoconfig
:info:install a ./opt/local/bin/ndn-autoconfig-server
:info:install a ./opt/local/bin/ndn-tlv-peek
:info:install a ./opt/local/bin/ndn-tlv-poke
:info:install a ./opt/local/bin/nfd
:info:install a ./opt/local/bin/nfd-autoreg
:info:install a ./opt/local/bin/nfd-start
:info:install a ./opt/local/bin/nfd-status
:info:install a ./opt/local/bin/nfd-status-http-server
:info:install a ./opt/local/bin/nfd-stop
:info:install a ./opt/local/bin/nfdc
:info:install a ./opt/local/bin/nrd
:debug:install Archive nfd-0.3.0_0.darwin_13.x86_64.tbz2 packaged
:debug:install removing file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/+COMMENT
:debug:install removing file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/+CONTENTS
:debug:install removing file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/+DESC
:debug:install removing file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/+PORTFILE
:debug:install removing file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/+STATE
:debug:activate activate phase started at Tue Feb 10 11:01:12 PST 2015
:debug:activate Executing org.macports.activate (nfd)
:msg:activate --->  Activating nfd @0.3.0_0
:debug:activate Using /usr/bin/tar
:debug:activate Using /usr/bin/bzip2
:info:activate x ./
:info:activate x ./+COMMENT
:info:activate x ./+CONTENTS
:info:activate x ./+DESC
:info:activate x ./+PORTFILE
:info:activate x ./+STATE
:info:activate x ./opt/
:info:activate x ./opt/local/
:info:activate x ./opt/local/bin/
:info:activate x ./opt/local/etc/
:info:activate x ./opt/local/share/
:info:activate x ./opt/local/share/man/
:info:activate x ./opt/local/share/ndn/
:info:activate x ./opt/local/share/ndn/nfd-status.xsl
:info:activate x ./opt/local/share/ndn/reset.css
:info:activate x ./opt/local/share/ndn/robots.txt
:info:activate x ./opt/local/share/ndn/style.css
:info:activate x ./opt/local/share/ndn/text.css
:info:activate x ./opt/local/share/man/man1/
:info:activate x ./opt/local/share/man/man1/ndn-autoconfig-server.1.gz
:info:activate x ./opt/local/share/man/man1/ndn-autoconfig.1.gz
:info:activate x ./opt/local/share/man/man1/ndn-tlv-peek.1.gz
:info:activate x ./opt/local/share/man/man1/ndn-tlv-poke.1.gz
:info:activate x ./opt/local/share/man/man1/nfd-autoreg.1.gz
:info:activate x ./opt/local/share/man/man1/nfd-status-http-server.1.gz
:info:activate x ./opt/local/share/man/man1/nfd-status.1.gz
:info:activate x ./opt/local/share/man/man1/nfd.1.gz
:info:activate x ./opt/local/share/man/man1/nfdc.1.gz
:info:activate x ./opt/local/share/man/man1/nrd.1.gz
:info:activate x ./opt/local/etc/LaunchDaemons/
:info:activate x ./opt/local/etc/ndn/
:info:activate x ./opt/local/etc/ndn/nfd.conf.sample
:info:activate x ./opt/local/etc/LaunchDaemons/net.named-data.nfd/
:info:activate x ./opt/local/etc/LaunchDaemons/net.named-data.nfd/net.named-data.nfd.plist
:info:activate x ./opt/local/etc/LaunchDaemons/net.named-data.nfd/net.named-data.nrd.plist
:info:activate x ./opt/local/bin/ndn-autoconfig
:info:activate x ./opt/local/bin/ndn-autoconfig-server
:info:activate x ./opt/local/bin/ndn-tlv-peek
:info:activate x ./opt/local/bin/ndn-tlv-poke
:info:activate x ./opt/local/bin/nfd
:info:activate x ./opt/local/bin/nfd-autoreg
:info:activate x ./opt/local/bin/nfd-start
:info:activate x ./opt/local/bin/nfd-status
:info:activate x ./opt/local/bin/nfd-status-http-server
:info:activate x ./opt/local/bin/nfd-stop
:info:activate x ./opt/local/bin/nfdc
:info:activate x ./opt/local/bin/nrd
:debug:activate activating directory: /
:debug:activate activating directory: /opt
:debug:activate activating directory: /opt/local
:debug:activate activating directory: /opt/local/bin
:debug:activate activating file: /opt/local/bin/ndn-autoconfig
:debug:activate activating file: /opt/local/bin/ndn-autoconfig-server
:debug:activate activating file: /opt/local/bin/ndn-tlv-peek
:debug:activate activating file: /opt/local/bin/ndn-tlv-poke
:debug:activate activating file: /opt/local/bin/nfd
:debug:activate activating file: /opt/local/bin/nfd-autoreg
:debug:activate activating file: /opt/local/bin/nfd-start
:debug:activate activating file: /opt/local/bin/nfd-status
:debug:activate activating file: /opt/local/bin/nfd-status-http-server
:debug:activate activating file: /opt/local/bin/nfd-stop
:debug:activate activating file: /opt/local/bin/nfdc
:debug:activate activating file: /opt/local/bin/nrd
:debug:activate activating directory: /opt/local/etc
:debug:activate activating directory: /opt/local/etc/LaunchDaemons
:debug:activate activating directory: /opt/local/etc/LaunchDaemons/net.named-data.nfd
:debug:activate activating file: /opt/local/etc/LaunchDaemons/net.named-data.nfd/net.named-data.nfd.plist
:debug:activate activating file: /opt/local/etc/LaunchDaemons/net.named-data.nfd/net.named-data.nrd.plist
:debug:activate activating directory: /opt/local/etc/ndn
:debug:activate activating file: /opt/local/etc/ndn/nfd.conf.sample
:debug:activate activating directory: /opt/local/share
:debug:activate activating directory: /opt/local/share/man
:debug:activate activating directory: /opt/local/share/man/man1
:debug:activate activating file: /opt/local/share/man/man1/ndn-autoconfig-server.1.gz
:debug:activate activating file: /opt/local/share/man/man1/ndn-autoconfig.1.gz
:debug:activate activating file: /opt/local/share/man/man1/ndn-tlv-peek.1.gz
:debug:activate activating file: /opt/local/share/man/man1/ndn-tlv-poke.1.gz
:debug:activate activating file: /opt/local/share/man/man1/nfd-autoreg.1.gz
:debug:activate activating file: /opt/local/share/man/man1/nfd-status-http-server.1.gz
:debug:activate activating file: /opt/local/share/man/man1/nfd-status.1.gz
:debug:activate activating file: /opt/local/share/man/man1/nfd.1.gz
:debug:activate activating file: /opt/local/share/man/man1/nfdc.1.gz
:debug:activate activating file: /opt/local/share/man/man1/nrd.1.gz
:debug:activate activating directory: /opt/local/share/ndn
:debug:activate activating file: /opt/local/share/ndn/nfd-status.xsl
:debug:activate activating file: /opt/local/share/ndn/reset.css
:debug:activate activating file: /opt/local/share/ndn/robots.txt
:debug:activate activating file: /opt/local/share/ndn/style.css
:debug:activate activating file: /opt/local/share/ndn/text.css
:notice:activate 
:notice:activate 
:notice:activate To start NFD and ensure it is started when system boots:
:notice:activate 
:notice:activate     nfd-start
:notice:activate 
:notice:activate To stop NFD and disable auto-start when system boots:
:notice:activate 
:notice:activate     nfd-stop
:notice:activate 
:notice:activate NFD log files are located in /opt/local/var/log/ndn/
:notice:activate 
:notice:activate Configuration file is in /opt/local/var/etc/ndn/
:notice:activate 
:notice:activate 
:debug:activate Executing proc-post-org.macports.activate-activate-0
:info:activate ERROR: TPM locator supplied does not match TPM locator in PIB: file: != tpm-file:
:info:activate Command failed: HOME=/opt/local/var/lib/ndn/nfd ndnsec-keygen /localhost/daemons/nfd |  HOME=/opt/local/var/lib/ndn/nfd ndnsec-install-cert -
:info:activate Exit code: 1
:error:activate org.macports.activate for port nfd returned: command execution failed
:debug:activate Error code: NONE
:debug:activate Backtrace: command execution failed
    while executing
"proc-post-org.macports.activate-activate-0 org.macports.activate"
    ("eval" body line 1)
    invoked from within
"eval $post $targetname"
:info:activate Warning: targets not executed for nfd: org.macports.activate
:notice:activate Please see the log file for port nfd for details:
    /opt/local/var/macports/logs/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/main.log

From shijunxiao at email.arizona.edu  Tue Feb 10 12:24:07 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Tue, 10 Feb 2015 13:24:07 -0700
Subject: [Nfd-dev] Error installing nfd @0.3.0_0 on Mac OSX 10.9.5
In-Reply-To: <20150210190714.GV72603@caida.org>
References: <20150210190714.GV72603@caida.org>
Message-ID: <CAOFH+Obu+LbRUWiC+BynuZb-zzuf+WLco3_F7gJhYeSFh-fAVQ@mail.gmail.com>

Hi Josh

Log says:
:info:activate ERROR: TPM locator supplied does not match TPM locator in
PIB: file: != tpm-file:
:info:activate Command failed: HOME=/opt/local/var/lib/ndn/nfd
ndnsec-keygen /localhost/daemons/nfd |  HOME=/opt/local/var/lib/ndn/nfd
ndnsec-install-cert -
:info:activate Exit code: 1

This seems related to one or more of #2242, #2384, #2391.
@Yingdi and @Alex should take a look.

I'm not sure what you mean by "completely clean install".
Does the system have NFD installed previously and you have uninstalled it,
or does the system never have ndn-cxx and NFD previously?

The workaround is:
sudo rm -rf /opt/local/var/lib/ndn/nfd/.ndn

Yours, Junxiao

On Tue, Feb 10, 2015 at 12:07 PM, Josh Polterock <josh at caida.org> wrote:

> I'm trying to do a completely clean install of NFD using ports.
> The ndn-cxx install completed successfully. The NFD install
> completes but finishes with the following error
>
> --->  Computing dependencies for nfd
> --->  Fetching archive for nfd
> --->  Attempting to fetch nfd-0.3.0_0.darwin_13.x86_64.tbz2 from
> http://packages.macports.org/nfd
> --->  Attempting to fetch nfd-0.3.0_0.darwin_13.x86_64.tbz2 from
> http://nue.de.packages.macports.org/macports/packages/nfd
> --->  Attempting to fetch nfd-0.3.0_0.darwin_13.x86_64.tbz2 from
> http://mse.uk.packages.macports.org/sites/packages.macports.org/nfd
> --->  Fetching distfiles for nfd
> --->  Attempting to fetch NFD-NFD-0.3.0.tar.gz from
> http://distfiles.macports.org/nfd
> --->  Attempting to fetch NFD-NFD-0.3.0.tar.gz from
> http://sea.us.distfiles.macports.org/macports/distfiles/nfd
> --->  Attempting to fetch NFD-NFD-0.3.0.tar.gz from
> https://github.com/named-data/NFD/tarball/NFD-0.3.0
> --->  Verifying checksums for nfd
> --->  Extracting nfd
> --->  Configuring nfd
> --->  Building nfd
> --->  Staging nfd into destroot
> --->  Installing nfd @0.3.0_0
> --->  Activating nfd @0.3.0_0
>
>
> To start NFD and ensure it is started when system boots:
>
>     nfd-start
>
> To stop NFD and disable auto-start when system boots:
>
>     nfd-stop
>
> NFD log files are located in /opt/local/var/log/ndn/
>
> Configuration file is in /opt/local/var/etc/ndn/
>
> Error: org.macports.activate for port nfd returned: command execution
> failed
> Please see the log file for port nfd for details:
>
> /opt/local/var/macports/logs/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/main.log
> To report a bug, follow the instructions in the guide:
>     http://guide.macports.org/#project.tickets
> Error: Processing of port nfd failed
>
> _______________________________________________
> 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/20150210/eeec9481/attachment.html>

From josh at caida.org  Tue Feb 10 12:31:52 2015
From: josh at caida.org (Josh Polterock)
Date: Tue, 10 Feb 2015 12:31:52 -0800
Subject: [Nfd-dev] Error installing nfd @0.3.0_0 on Mac OSX 10.9.5
In-Reply-To: <CAOFH+Obu+LbRUWiC+BynuZb-zzuf+WLco3_F7gJhYeSFh-fAVQ@mail.gmail.com>
References: <20150210190714.GV72603@caida.org>
	<CAOFH+Obu+LbRUWiC+BynuZb-zzuf+WLco3_F7gJhYeSFh-fAVQ@mail.gmail.com>
Message-ID: <20150210203152.GZ72603@caida.org>

On Tue, Feb 10, 2015 at 01:24:07PM -0700, Junxiao Shi wrote:
> Hi Josh
> 
> Log says:
> :info:activate ERROR: TPM locator supplied does not match TPM locator in
> PIB: file: != tpm-file:
> :info:activate Command failed: HOME=/opt/local/var/lib/ndn/nfd
> ndnsec-keygen /localhost/daemons/nfd |  HOME=/opt/local/var/lib/ndn/nfd
> ndnsec-install-cert -
> :info:activate Exit code: 1
> 
> This seems related to one or more of #2242, #2384, #2391.
> @Yingdi and @Alex should take a look.
> 
> I'm not sure what you mean by "completely clean install".
> Does the system have NFD installed previously and you have uninstalled it,
> or does the system never have ndn-cxx and NFD previously?

The system had nfd and ndn-cxx installed previously.

I simply mean that I did a port uninstall of nfd and ndn-cxx. 

> 
> The workaround is:
> sudo rm -rf /opt/local/var/lib/ndn/nfd/.ndn

I executed this command. Should nfd then start?

Thanks,
Josh

> 
> Yours, Junxiao
> 
> On Tue, Feb 10, 2015 at 12:07 PM, Josh Polterock <josh at caida.org> wrote:
> 
> > I'm trying to do a completely clean install of NFD using ports.
> > The ndn-cxx install completed successfully. The NFD install
> > completes but finishes with the following error
> >
> > --->  Computing dependencies for nfd
> > --->  Fetching archive for nfd
> > --->  Attempting to fetch nfd-0.3.0_0.darwin_13.x86_64.tbz2 from
> > http://packages.macports.org/nfd
> > --->  Attempting to fetch nfd-0.3.0_0.darwin_13.x86_64.tbz2 from
> > http://nue.de.packages.macports.org/macports/packages/nfd
> > --->  Attempting to fetch nfd-0.3.0_0.darwin_13.x86_64.tbz2 from
> > http://mse.uk.packages.macports.org/sites/packages.macports.org/nfd
> > --->  Fetching distfiles for nfd
> > --->  Attempting to fetch NFD-NFD-0.3.0.tar.gz from
> > http://distfiles.macports.org/nfd
> > --->  Attempting to fetch NFD-NFD-0.3.0.tar.gz from
> > http://sea.us.distfiles.macports.org/macports/distfiles/nfd
> > --->  Attempting to fetch NFD-NFD-0.3.0.tar.gz from
> > https://github.com/named-data/NFD/tarball/NFD-0.3.0
> > --->  Verifying checksums for nfd
> > --->  Extracting nfd
> > --->  Configuring nfd
> > --->  Building nfd
> > --->  Staging nfd into destroot
> > --->  Installing nfd @0.3.0_0
> > --->  Activating nfd @0.3.0_0
> >
> >
> > To start NFD and ensure it is started when system boots:
> >
> >     nfd-start
> >
> > To stop NFD and disable auto-start when system boots:
> >
> >     nfd-stop
> >
> > NFD log files are located in /opt/local/var/log/ndn/
> >
> > Configuration file is in /opt/local/var/etc/ndn/
> >
> > Error: org.macports.activate for port nfd returned: command execution
> > failed
> > Please see the log file for port nfd for details:
> >
> > /opt/local/var/macports/logs/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/main.log
> > To report a bug, follow the instructions in the guide:
> >     http://guide.macports.org/#project.tickets
> > Error: Processing of port nfd failed
> >
> > _______________________________________________
> > Nfd-dev mailing list
> > Nfd-dev at lists.cs.ucla.edu
> > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
> >


From afanasev at CS.UCLA.EDU  Tue Feb 10 12:36:52 2015
From: afanasev at CS.UCLA.EDU (Alex Afanasyev)
Date: Tue, 10 Feb 2015 12:36:52 -0800
Subject: [Nfd-dev] Error installing nfd @0.3.0_0 on Mac OSX 10.9.5
In-Reply-To: <20150210203152.GZ72603@caida.org>
References: <20150210190714.GV72603@caida.org>
	<CAOFH+Obu+LbRUWiC+BynuZb-zzuf+WLco3_F7gJhYeSFh-fAVQ@mail.gmail.com>
	<20150210203152.GZ72603@caida.org>
Message-ID: <ACCFAB96-A567-497E-91A7-DE6602D23B8E@cs.ucla.edu>

Hi Josh,

I need to double check default configuration that comes with macports.  It may be a little wrong.  Deleting /opt/local/var/lib/ndn/nfd/.ndn would not solve the problem, as there are a few security restrictions when running macports.

---
Alex

> On Feb 10, 2015, at 12:31 PM, Josh Polterock <josh at caida.org> wrote:
> 
> On Tue, Feb 10, 2015 at 01:24:07PM -0700, Junxiao Shi wrote:
>> Hi Josh
>> 
>> Log says:
>> :info:activate ERROR: TPM locator supplied does not match TPM locator in
>> PIB: file: != tpm-file:
>> :info:activate Command failed: HOME=/opt/local/var/lib/ndn/nfd
>> ndnsec-keygen /localhost/daemons/nfd |  HOME=/opt/local/var/lib/ndn/nfd
>> ndnsec-install-cert -
>> :info:activate Exit code: 1
>> 
>> This seems related to one or more of #2242, #2384, #2391.
>> @Yingdi and @Alex should take a look.
>> 
>> I'm not sure what you mean by "completely clean install".
>> Does the system have NFD installed previously and you have uninstalled it,
>> or does the system never have ndn-cxx and NFD previously?
> 
> The system had nfd and ndn-cxx installed previously.
> 
> I simply mean that I did a port uninstall of nfd and ndn-cxx. 
> 
>> 
>> The workaround is:
>> sudo rm -rf /opt/local/var/lib/ndn/nfd/.ndn
> 
> I executed this command. Should nfd then start?
> 
> Thanks,
> Josh
> 
>> 
>> Yours, Junxiao
>> 
>> On Tue, Feb 10, 2015 at 12:07 PM, Josh Polterock <josh at caida.org> wrote:
>> 
>>> I'm trying to do a completely clean install of NFD using ports.
>>> The ndn-cxx install completed successfully. The NFD install
>>> completes but finishes with the following error
>>> 
>>> --->  Computing dependencies for nfd
>>> --->  Fetching archive for nfd
>>> --->  Attempting to fetch nfd-0.3.0_0.darwin_13.x86_64.tbz2 from
>>> http://packages.macports.org/nfd
>>> --->  Attempting to fetch nfd-0.3.0_0.darwin_13.x86_64.tbz2 from
>>> http://nue.de.packages.macports.org/macports/packages/nfd
>>> --->  Attempting to fetch nfd-0.3.0_0.darwin_13.x86_64.tbz2 from
>>> http://mse.uk.packages.macports.org/sites/packages.macports.org/nfd
>>> --->  Fetching distfiles for nfd
>>> --->  Attempting to fetch NFD-NFD-0.3.0.tar.gz from
>>> http://distfiles.macports.org/nfd
>>> --->  Attempting to fetch NFD-NFD-0.3.0.tar.gz from
>>> http://sea.us.distfiles.macports.org/macports/distfiles/nfd
>>> --->  Attempting to fetch NFD-NFD-0.3.0.tar.gz from
>>> https://github.com/named-data/NFD/tarball/NFD-0.3.0
>>> --->  Verifying checksums for nfd
>>> --->  Extracting nfd
>>> --->  Configuring nfd
>>> --->  Building nfd
>>> --->  Staging nfd into destroot
>>> --->  Installing nfd @0.3.0_0
>>> --->  Activating nfd @0.3.0_0
>>> 
>>> 
>>> To start NFD and ensure it is started when system boots:
>>> 
>>>    nfd-start
>>> 
>>> To stop NFD and disable auto-start when system boots:
>>> 
>>>    nfd-stop
>>> 
>>> NFD log files are located in /opt/local/var/log/ndn/
>>> 
>>> Configuration file is in /opt/local/var/etc/ndn/
>>> 
>>> Error: org.macports.activate for port nfd returned: command execution
>>> failed
>>> Please see the log file for port nfd for details:
>>> 
>>> /opt/local/var/macports/logs/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/main.log
>>> To report a bug, follow the instructions in the guide:
>>>    http://guide.macports.org/#project.tickets
>>> Error: Processing of port nfd failed
>>> 
>>> _______________________________________________
>>> Nfd-dev mailing list
>>> Nfd-dev at lists.cs.ucla.edu
>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev




From alexander.afanasyev at ucla.edu  Tue Feb 10 19:22:39 2015
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Tue, 10 Feb 2015 19:22:39 -0800
Subject: [Nfd-dev] [ndn-cxx] Deprecation notice for Name::set methods
Message-ID: <94E45A74-570C-44FC-AA20-6BC6F2080E87@ucla.edu>

Hi everybody,

We will be deprecating Name::set method from public API of ndn-cxx library.  If you're using them, you should rewrite your code to use the corresponding constructor.  To ensure that move operation is used, you can add std::move().

The affecting commit will be merged after February 24, 2015.  After this date, usage of Name::set method will result in deprecation warning.  Methods will exist until version 0.4 and will be removed afterwards

For reference: http://redmine.named-data.net/issues/2505

---
Alex

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

From alexander.afanasyev at ucla.edu  Tue Feb 10 19:53:30 2015
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Tue, 10 Feb 2015 19:53:30 -0800
Subject: [Nfd-dev] Alert about default value change
Message-ID: <330FD0FD-EEB5-44C0-AB37-A7BF9EE55693@ucla.edu>

Hi again,

As part of one of the tasks (http://redmine.named-data.net/issues/2473) we will be changing default value for on-demand UDP face timeout.  For a long time we had inconsistency between "effective" default value in sample configuration file and actual default value inside FaceManager.

We will wait until February 17, 2015 to merge the offending commit.

---
Alex

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

From lanwang at memphis.edu  Fri Feb 13 14:24:57 2015
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Fri, 13 Feb 2015 22:24:57 +0000
Subject: [Nfd-dev] Fwd: Loss Rate
References: <53F3B3DF.5050707@seas.wustl.edu>
Message-ID: <72AC047A-64AD-4E8A-B952-25685C17A8C2@memphis.edu>

FYI, some information about the overlay link loss rate (measured with ping) over the testbed.  Loss rate is pretty low, e.g., 10 losses out of 100000 between UCLA and PKU at 100 pings per second (see below).

Lan

Begin forwarded message:

From: John DeHart <jdd at seas.wustl.edu<mailto:jdd at seas.wustl.edu>>
Subject: Re: Loss Rate
Date: August 19, 2014 3:30:23 PM CDT
To: "Lan Wang (lanwang)" <lanwang at memphis.edu<mailto:lanwang at memphis.edu>>, "marcsb at bellsouth.net<mailto:marcsb at bellsouth.net>" <marcsb at bellsouth.net<mailto:marcsb at bellsouth.net>>
Cc: "obaidasyed at gmail.com<mailto:obaidasyed at gmail.com>" <obaidasyed at gmail.com<mailto:obaidasyed at gmail.com>>


100,000 ping requests:

UCLA (spurs) to PKU (loss of 10 packets)

ndnops at spurs:~$ sudo ping -q -i 0.01 -c 100000 162.105.146.26
PING 162.105.146.26 (162.105.146.26) 56(84) bytes of data.

--- 162.105.146.26 ping statistics ---
100000 packets transmitted, 99990 received, 0% packet loss, time 1112399ms
rtt min/avg/max/mdev = 148.080/155.447/970.675/43.102 ms, pipe 96



TONGJI to CAIDA (loss of 8 packets):

ndnops at ndnops:~$ sudo ping -q -i 0.01 -c 100000 click.caida.org<http://click.caida.org>
PING click.caida.org<http://click.caida.org> (192.172.226.248) 56(84) bytes of data.

--- click.caida.org<http://click.caida.org> ping statistics ---
100000 packets transmitted, 99992 received, 0% packet loss, time 1371267ms
rtt min/avg/max/mdev = 181.647/202.676/251.866/12.110 ms, pipe 19

On 8/19/14, 2:37 PM, John DeHart wrote:

And here is a similar pair of results for 10000 pings trying at 100 requests per second.
Let me know if this level of result helps at all.

UCLA (spurs) to PKU:

ndnops at spurs:~$ sudo ping -q -i 0.01 -c 10000 162.105.146.26
PING 162.105.146.26 (162.105.146.26) 56(84) bytes of data.

--- 162.105.146.26 ping statistics ---
10000 packets transmitted, 10000 received, 0% packet loss, time 109146ms
rtt min/avg/max/mdev = 148.050/154.401/631.033/39.391 ms, pipe 63
ndnops at spurs:~$


TONGJI to CAIDA (1 loss out of 10000)

ndnops at ndnops:~$ sudo ping -q -i 0.01 -c 10000 click.caida.org<http://click.caida.org>
PING click.caida.org<http://click.caida.org> (192.172.226.248) 56(84) bytes of data.

--- click.caida.org<http://click.caida.org> ping statistics ---
10000 packets transmitted, 9999 received, 0% packet loss, time 136946ms
rtt min/avg/max/mdev = 181.710/193.677/210.785/5.104 ms, pipe 17
ndnops at ndnops:~$
On 8/19/14, 2:22 PM, John DeHart wrote:

Here are two initial tests doing 1000 ping requests,
using approximately 10 ping requests per second.

UCLA (spurs) to PKU:
ndnops at spurs:~$ sudo ping -q -i 0.1 -c 1000 162.105.146.26
PING 162.105.146.26 (162.105.146.26) 56(84) bytes of data.

--- 162.105.146.26 ping statistics ---
1000 packets transmitted, 1000 received, 0% packet loss, time 100958ms
rtt min/avg/max/mdev = 148.277/166.666/597.244/67.553 ms, pipe 6



TONGJI to CAIDA:
ndnops at ndnops:~$ sudo ping -q -i 0.1 -c 1000 click.caida.org<http://click.caida.org>
PING click.caida.org<http://click.caida.org> (192.172.226.248) 56(84) bytes of data.

--- click.caida.org<http://click.caida.org> ping statistics ---
1000 packets transmitted, 1000 received, 0% packet loss, time 106763ms
rtt min/avg/max/mdev = 181.729/224.260/270.358/19.935 ms, pipe 3



John

On 8/19/14, 2:15 PM, John DeHart wrote:

Lan,

The other issue I am encountering as I try some initial tests is
that not all sites seem to allow pings. For instance, Tongji,
one of the ones we would be most interested in, does not seem
to allow pings.

John

On 8/19/14, 2:09 PM, John DeHart wrote:

Lan,

How urgent is this? Are you trying to get some results before NDNComm?

John

On 8/19/14, 8:56 AM, Lan Wang (lanwang) wrote:
John,

For the international links, I am guessing 1 in 1000 or more.  Domestic ones may be lower (1 in 10000?)  These are overlay links, so they should have higher loss rate than a single physical link.

Lan



-------- Original message --------
From: John DeHart <jdd at seas.wustl.edu><mailto:jdd at seas.wustl.edu>
Date: 08/18/2014 7:36 PM (GMT-06:00)
To: "Lan Wang (lanwang)" <lanwang at memphis.edu><mailto:lanwang at memphis.edu>,marcsb at bellsouth.net<mailto:marcsb at bellsouth.net>
Cc: obaidasyed at gmail.com<mailto:obaidasyed at gmail.com>
Subject: Re: Loss Rate



Lan,

What are you expecting the loss rates to be? Are you expecting 1 in a million?

I would think we would have to run ping for a long time to get an accurate picture of the loss rate on a link.

John

On 8/18/14, 6:15 PM, Lan Wang (lanwang) wrote:
John,

Sorry for the lack of details.  Marc should have given you some background.  We are trying to emulate the testbed and losses are an important characteristic of the topology that can affect the behavior of the protocols and performance.   It is also good for testing the robustness of our design and implementation.  Right now we do not have a good idea of the loss rate on the testbed links.

We are mainly interested in losses from one nic to another nic.  I think running a continuous ping with one packet every second would be good enough.

Lan



-------- Original message --------
From: John DeHart <jdd at seas.wustl.edu><mailto:jdd at seas.wustl.edu>
Date: 08/18/2014 4:23 PM (GMT-06:00)
To: marcsb at bellsouth.net<mailto:marcsb at bellsouth.net>
Cc: obaidasyed at gmail.com<mailto:obaidasyed at gmail.com>,"Lan Wang (lanwang)" <lanwang at memphis.edu><mailto:lanwang at memphis.edu>
Subject: Re: Loss Rate



Marc,

Wow. That sounds like a simple question but I'm guessing it opens up a lot of possibilities.
Do you guys have something that you do on your local testbed already?

What is it you are really interested in?  Are you looking for losses from when
data leaves one NIC to when it arrives at the remote NIC
or are you looking for losses from sending process to receiving process?

John

On 8/18/14, 2:50 PM, Marc Badrian wrote:
Hey John,


Is there any way you could get the loss rate for each link/between each site for the current testbed topology?



Thanks,

- Marc








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

From lixia at CS.UCLA.EDU  Fri Feb 13 21:27:35 2015
From: lixia at CS.UCLA.EDU (Lixia Zhang)
Date: Fri, 13 Feb 2015 21:27:35 -0800
Subject: [Nfd-dev] Loss Rate
In-Reply-To: <72AC047A-64AD-4E8A-B952-25685C17A8C2@memphis.edu>
References: <53F3B3DF.5050707@seas.wustl.edu>
	<72AC047A-64AD-4E8A-B952-25685C17A8C2@memphis.edu>
Message-ID: <DC0C7C8A-BF93-4EDF-B39C-9B529E29B6DC@cs.ucla.edu>


> On Feb 13, 2015, at 2:24 PM, Lan Wang (lanwang) <lanwang at memphis.edu> wrote:
> 
> FYI, some information about the overlay link loss rate (measured with ping) over the testbed.  Loss rate is pretty low, e.g., 10 losses out of 100000 between UCLA and PKU at 100 pings per second (see below).
> 
> Lan

just curious: wonder if we know what may happen if we increase the rate to 500 pings/sec?


> 
> Begin forwarded message:
> 
>> From: John DeHart <jdd at seas.wustl.edu <mailto:jdd at seas.wustl.edu>>
>> Subject: Re: Loss Rate
>> Date: August 19, 2014 3:30:23 PM CDT
>> To: "Lan Wang (lanwang)" <lanwang at memphis.edu <mailto:lanwang at memphis.edu>>, "marcsb at bellsouth.net <mailto:marcsb at bellsouth.net>" <marcsb at bellsouth.net <mailto:marcsb at bellsouth.net>>
>> Cc: "obaidasyed at gmail.com <mailto:obaidasyed at gmail.com>" <obaidasyed at gmail.com <mailto:obaidasyed at gmail.com>>
>> 
>> 
>> 100,000 ping requests:
>> 
>> UCLA (spurs) to PKU (loss of 10 packets)
>> 
>> ndnops at spurs:~$ sudo ping -q -i 0.01 -c 100000 162.105.146.26
>> PING 162.105.146.26 (162.105.146.26) 56(84) bytes of data.
>> 
>> --- 162.105.146.26 ping statistics ---
>> 100000 packets transmitted, 99990 received, 0% packet loss, time 1112399ms
>> rtt min/avg/max/mdev = 148.080/155.447/970.675/43.102 ms, pipe 96
>> 
>> 
>> 
>> TONGJI to CAIDA (loss of 8 packets):
>> 
>> ndnops at ndnops:~$ sudo ping -q -i 0.01 -c 100000 click.caida.org <http://click.caida.org/>
>> PING click.caida.org <http://click.caida.org/> (192.172.226.248) 56(84) bytes of data.
>> 
>> --- click.caida.org <http://click.caida.org/> ping statistics ---
>> 100000 packets transmitted, 99992 received, 0% packet loss, time 1371267ms
>> rtt min/avg/max/mdev = 181.647/202.676/251.866/12.110 ms, pipe 19
>> 
>> On 8/19/14, 2:37 PM, John DeHart wrote:
>>> 
>>> And here is a similar pair of results for 10000 pings trying at 100 requests per second.
>>> Let me know if this level of result helps at all.
>>> 
>>> UCLA (spurs) to PKU:
>>> 
>>> ndnops at spurs:~$ sudo ping -q -i 0.01 -c 10000 162.105.146.26
>>> PING 162.105.146.26 (162.105.146.26) 56(84) bytes of data.
>>> 
>>> --- 162.105.146.26 ping statistics ---
>>> 10000 packets transmitted, 10000 received, 0% packet loss, time 109146ms
>>> rtt min/avg/max/mdev = 148.050/154.401/631.033/39.391 ms, pipe 63
>>> ndnops at spurs:~$
>>> 
>>> 
>>> TONGJI to CAIDA (1 loss out of 10000)
>>> 
>>> ndnops at ndnops:~$ sudo ping -q -i 0.01 -c 10000 click.caida.org <http://click.caida.org/>
>>> PING click.caida.org <http://click.caida.org/> (192.172.226.248) 56(84) bytes of data.
>>> 
>>> --- click.caida.org <http://click.caida.org/> ping statistics ---
>>> 10000 packets transmitted, 9999 received, 0% packet loss, time 136946ms
>>> rtt min/avg/max/mdev = 181.710/193.677/210.785/5.104 ms, pipe 17
>>> ndnops at ndnops:~$
>>> On 8/19/14, 2:22 PM, John DeHart wrote:
>>>> 
>>>> Here are two initial tests doing 1000 ping requests,
>>>> using approximately 10 ping requests per second.
>>>> 
>>>> UCLA (spurs) to PKU:
>>>> ndnops at spurs:~$ sudo ping -q -i 0.1 -c 1000 162.105.146.26
>>>> PING 162.105.146.26 (162.105.146.26) 56(84) bytes of data.
>>>> 
>>>> --- 162.105.146.26 ping statistics ---
>>>> 1000 packets transmitted, 1000 received, 0% packet loss, time 100958ms
>>>> rtt min/avg/max/mdev = 148.277/166.666/597.244/67.553 ms, pipe 6
>>>> 
>>>> 
>>>> 
>>>> TONGJI to CAIDA:
>>>> ndnops at ndnops:~$ sudo ping -q -i 0.1 -c 1000 click.caida.org <http://click.caida.org/>
>>>> PING click.caida.org <http://click.caida.org/> (192.172.226.248) 56(84) bytes of data.
>>>> 
>>>> --- click.caida.org <http://click.caida.org/> ping statistics ---
>>>> 1000 packets transmitted, 1000 received, 0% packet loss, time 106763ms
>>>> rtt min/avg/max/mdev = 181.729/224.260/270.358/19.935 ms, pipe 3
>>>> 
>>>> John

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

From lanwang at memphis.edu  Sat Feb 14 13:28:16 2015
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Sat, 14 Feb 2015 21:28:16 +0000
Subject: [Nfd-dev] Loss Rate
In-Reply-To: <DC0C7C8A-BF93-4EDF-B39C-9B529E29B6DC@cs.ucla.edu>
References: <53F3B3DF.5050707@seas.wustl.edu>
	<72AC047A-64AD-4E8A-B952-25685C17A8C2@memphis.edu>,
	<DC0C7C8A-BF93-4EDF-B39C-9B529E29B6DC@cs.ucla.edu>
Message-ID: <69C34E1B-5D05-4640-8267-82A49DEF7D31@memphis.edu>



Sent from my iPhone

On Feb 13, 2015, at 11:28 PM, Lixia Zhang <lixia at cs.ucla.edu<mailto:lixia at cs.ucla.edu>> wrote:


On Feb 13, 2015, at 2:24 PM, Lan Wang (lanwang) <lanwang at memphis.edu<mailto:lanwang at memphis.edu>> wrote:

FYI, some information about the overlay link loss rate (measured with ping) over the testbed.  Loss rate is pretty low, e.g., 10 losses out of 100000 between UCLA and PKU at 100 pings per second (see below).

Lan

just curious: wonder if we know what may happen if we increase the rate to 500 pings/sec?

I am cc'ing John to see if he can do this on the testbed.

Lan



Begin forwarded message:

From: John DeHart <jdd at seas.wustl.edu<mailto:jdd at seas.wustl.edu>>
Subject: Re: Loss Rate
Date: August 19, 2014 3:30:23 PM CDT
To: "Lan Wang (lanwang)" <lanwang at memphis.edu<mailto:lanwang at memphis.edu>>, "marcsb at bellsouth.net<mailto:marcsb at bellsouth.net>" <marcsb at bellsouth.net<mailto:marcsb at bellsouth.net>>
Cc: "obaidasyed at gmail.com<mailto:obaidasyed at gmail.com>" <obaidasyed at gmail.com<mailto:obaidasyed at gmail.com>>


100,000 ping requests:

UCLA (spurs) to PKU (loss of 10 packets)

ndnops at spurs:~$ sudo ping -q -i 0.01 -c 100000 162.105.146.26
PING 162.105.146.26 (162.105.146.26) 56(84) bytes of data.

--- 162.105.146.26 ping statistics ---
100000 packets transmitted, 99990 received, 0% packet loss, time 1112399ms
rtt min/avg/max/mdev = 148.080/155.447/970.675/43.102 ms, pipe 96



TONGJI to CAIDA (loss of 8 packets):

ndnops at ndnops:~$ sudo ping -q -i 0.01 -c 100000 click.caida.org<http://click.caida.org/>
PING click.caida.org<http://click.caida.org/> (192.172.226.248) 56(84) bytes of data.

--- click.caida.org<http://click.caida.org/> ping statistics ---
100000 packets transmitted, 99992 received, 0% packet loss, time 1371267ms
rtt min/avg/max/mdev = 181.647/202.676/251.866/12.110 ms, pipe 19

On 8/19/14, 2:37 PM, John DeHart wrote:

And here is a similar pair of results for 10000 pings trying at 100 requests per second.
Let me know if this level of result helps at all.

UCLA (spurs) to PKU:

ndnops at spurs:~$ sudo ping -q -i 0.01 -c 10000 162.105.146.26
PING 162.105.146.26 (162.105.146.26) 56(84) bytes of data.

--- 162.105.146.26 ping statistics ---
10000 packets transmitted, 10000 received, 0% packet loss, time 109146ms
rtt min/avg/max/mdev = 148.050/154.401/631.033/39.391 ms, pipe 63
ndnops at spurs:~$


TONGJI to CAIDA (1 loss out of 10000)

ndnops at ndnops:~$ sudo ping -q -i 0.01 -c 10000 click.caida.org<http://click.caida.org/>
PING click.caida.org<http://click.caida.org/> (192.172.226.248) 56(84) bytes of data.

--- click.caida.org<http://click.caida.org/> ping statistics ---
10000 packets transmitted, 9999 received, 0% packet loss, time 136946ms
rtt min/avg/max/mdev = 181.710/193.677/210.785/5.104 ms, pipe 17
ndnops at ndnops:~$
On 8/19/14, 2:22 PM, John DeHart wrote:

Here are two initial tests doing 1000 ping requests,
using approximately 10 ping requests per second.

UCLA (spurs) to PKU:
ndnops at spurs:~$ sudo ping -q -i 0.1 -c 1000 162.105.146.26
PING 162.105.146.26 (162.105.146.26) 56(84) bytes of data.

--- 162.105.146.26 ping statistics ---
1000 packets transmitted, 1000 received, 0% packet loss, time 100958ms
rtt min/avg/max/mdev = 148.277/166.666/597.244/67.553 ms, pipe 6



TONGJI to CAIDA:
ndnops at ndnops:~$ sudo ping -q -i 0.1 -c 1000 click.caida.org<http://click.caida.org/>
PING click.caida.org<http://click.caida.org/> (192.172.226.248) 56(84) bytes of data.

--- click.caida.org<http://click.caida.org/> ping statistics ---
1000 packets transmitted, 1000 received, 0% packet loss, time 106763ms
rtt min/avg/max/mdev = 181.729/224.260/270.358/19.935 ms, pipe 3

John

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

From jdd at wustl.edu  Sat Feb 14 14:09:39 2015
From: jdd at wustl.edu (Dehart, John)
Date: Sat, 14 Feb 2015 22:09:39 +0000
Subject: [Nfd-dev] Loss Rate
In-Reply-To: <69C34E1B-5D05-4640-8267-82A49DEF7D31@memphis.edu>
References: <53F3B3DF.5050707@seas.wustl.edu>
	<72AC047A-64AD-4E8A-B952-25685C17A8C2@memphis.edu>,
	<DC0C7C8A-BF93-4EDF-B39C-9B529E29B6DC@cs.ucla.edu>
	<69C34E1B-5D05-4640-8267-82A49DEF7D31@memphis.edu>
Message-ID: <45692BB8-3205-4D7C-95DA-315E7CE89537@wustl.edu>


Lan,

Sure, I can do that.
What is it you are looking for, a characterization of the full Testbed or just this link?

John

On Feb 14, 2015, at 3:28 PM, Lan Wang (lanwang) <lanwang at memphis.edu<mailto:lanwang at memphis.edu>> wrote:



Sent from my iPhone

On Feb 13, 2015, at 11:28 PM, Lixia Zhang <lixia at cs.ucla.edu<mailto:lixia at cs.ucla.edu>> wrote:


On Feb 13, 2015, at 2:24 PM, Lan Wang (lanwang) <lanwang at memphis.edu<mailto:lanwang at memphis.edu>> wrote:

FYI, some information about the overlay link loss rate (measured with ping) over the testbed.  Loss rate is pretty low, e.g., 10 losses out of 100000 between UCLA and PKU at 100 pings per second (see below).

Lan

just curious: wonder if we know what may happen if we increase the rate to 500 pings/sec?

I am cc'ing John to see if he can do this on the testbed.

Lan



Begin forwarded message:

From: John DeHart <jdd at seas.wustl.edu<mailto:jdd at seas.wustl.edu>>
Subject: Re: Loss Rate
Date: August 19, 2014 3:30:23 PM CDT
To: "Lan Wang (lanwang)" <lanwang at memphis.edu<mailto:lanwang at memphis.edu>>, "marcsb at bellsouth.net<mailto:marcsb at bellsouth.net>" <marcsb at bellsouth.net<mailto:marcsb at bellsouth.net>>
Cc: "obaidasyed at gmail.com<mailto:obaidasyed at gmail.com>" <obaidasyed at gmail.com<mailto:obaidasyed at gmail.com>>


100,000 ping requests:

UCLA (spurs) to PKU (loss of 10 packets)

ndnops at spurs:~$ sudo ping -q -i 0.01 -c 100000 162.105.146.26
PING 162.105.146.26 (162.105.146.26) 56(84) bytes of data.

--- 162.105.146.26 ping statistics ---
100000 packets transmitted, 99990 received, 0% packet loss, time 1112399ms
rtt min/avg/max/mdev = 148.080/155.447/970.675/43.102 ms, pipe 96



TONGJI to CAIDA (loss of 8 packets):

ndnops at ndnops:~$ sudo ping -q -i 0.01 -c 100000 click.caida.org<http://click.caida.org/>
PING click.caida.org<http://click.caida.org/> (192.172.226.248) 56(84) bytes of data.

--- click.caida.org<http://click.caida.org/> ping statistics ---
100000 packets transmitted, 99992 received, 0% packet loss, time 1371267ms
rtt min/avg/max/mdev = 181.647/202.676/251.866/12.110 ms, pipe 19

On 8/19/14, 2:37 PM, John DeHart wrote:

And here is a similar pair of results for 10000 pings trying at 100 requests per second.
Let me know if this level of result helps at all.

UCLA (spurs) to PKU:

ndnops at spurs:~$ sudo ping -q -i 0.01 -c 10000 162.105.146.26
PING 162.105.146.26 (162.105.146.26) 56(84) bytes of data.

--- 162.105.146.26 ping statistics ---
10000 packets transmitted, 10000 received, 0% packet loss, time 109146ms
rtt min/avg/max/mdev = 148.050/154.401/631.033/39.391 ms, pipe 63
ndnops at spurs:~$


TONGJI to CAIDA (1 loss out of 10000)

ndnops at ndnops:~$ sudo ping -q -i 0.01 -c 10000 click.caida.org<http://click.caida.org/>
PING click.caida.org<http://click.caida.org/> (192.172.226.248) 56(84) bytes of data.

--- click.caida.org<http://click.caida.org/> ping statistics ---
10000 packets transmitted, 9999 received, 0% packet loss, time 136946ms
rtt min/avg/max/mdev = 181.710/193.677/210.785/5.104 ms, pipe 17
ndnops at ndnops:~$
On 8/19/14, 2:22 PM, John DeHart wrote:

Here are two initial tests doing 1000 ping requests,
using approximately 10 ping requests per second.

UCLA (spurs) to PKU:
ndnops at spurs:~$ sudo ping -q -i 0.1 -c 1000 162.105.146.26
PING 162.105.146.26 (162.105.146.26) 56(84) bytes of data.

--- 162.105.146.26 ping statistics ---
1000 packets transmitted, 1000 received, 0% packet loss, time 100958ms
rtt min/avg/max/mdev = 148.277/166.666/597.244/67.553 ms, pipe 6



TONGJI to CAIDA:
ndnops at ndnops:~$ sudo ping -q -i 0.1 -c 1000 click.caida.org<http://click.caida.org/>
PING click.caida.org<http://click.caida.org/> (192.172.226.248) 56(84) bytes of data.

--- click.caida.org<http://click.caida.org/> ping statistics ---
1000 packets transmitted, 1000 received, 0% packet loss, time 106763ms
rtt min/avg/max/mdev = 181.729/224.260/270.358/19.935 ms, pipe 3

John


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

From lixia at CS.UCLA.EDU  Sat Feb 14 16:23:32 2015
From: lixia at CS.UCLA.EDU (Lixia Zhang)
Date: Sat, 14 Feb 2015 16:23:32 -0800
Subject: [Nfd-dev] Loss Rate
In-Reply-To: <45692BB8-3205-4D7C-95DA-315E7CE89537@wustl.edu>
References: <53F3B3DF.5050707@seas.wustl.edu>
	<72AC047A-64AD-4E8A-B952-25685C17A8C2@memphis.edu> <,
	<DC0C7C8A-BF93-4EDF-B39C-9B529E29B6DC@cs.ucla.edu> <>>
	<69C34E1B-5D05-4640-8267-82A49DEF7D31@memphis.edu>
	<45692BB8-3205-4D7C-95DA-315E7CE89537@wustl.edu>
Message-ID: <32F5D49A-5C9F-4E5D-BC79-61BFEBF720C2@cs.ucla.edu>


> On Feb 14, 2015, at 2:09 PM, Dehart, John <jdd at wustl.edu> wrote:
> 
> 
> Lan,
> 
> Sure, I can do that.
> What is it you are looking for, a characterization of the full Testbed or just this link?
> 
> John

My personal interest is to get an idea of the testbed performance, so a path with across one or two NFD hops would be interesting.
See what Lan may want.

> 
> On Feb 14, 2015, at 3:28 PM, Lan Wang (lanwang) <lanwang at memphis.edu <mailto:lanwang at memphis.edu>> wrote:
> 
>> 
>> 
>> Sent from my iPhone
>> 
>> On Feb 13, 2015, at 11:28 PM, Lixia Zhang <lixia at cs.ucla.edu <mailto:lixia at cs.ucla.edu>> wrote:
>> 
>>> 
>>>> On Feb 13, 2015, at 2:24 PM, Lan Wang (lanwang) <lanwang at memphis.edu <mailto:lanwang at memphis.edu>> wrote:
>>>> 
>>>> FYI, some information about the overlay link loss rate (measured with ping) over the testbed.  Loss rate is pretty low, e.g., 10 losses out of 100000 between UCLA and PKU at 100 pings per second (see below).
>>>> 
>>>> Lan
>>> 
>>> just curious: wonder if we know what may happen if we increase the rate to 500 pings/sec?
>> 
>> I am cc'ing John to see if he can do this on the testbed.
>> 
>> Lan
>>> 
>>> 
>>>> 
>>>> Begin forwarded message:
>>>> 
>>>>> From: John DeHart <jdd at seas.wustl.edu <mailto:jdd at seas.wustl.edu>>
>>>>> Subject: Re: Loss Rate
>>>>> Date: August 19, 2014 3:30:23 PM CDT
>>>>> To: "Lan Wang (lanwang)" <lanwang at memphis.edu <mailto:lanwang at memphis.edu>>, "marcsb at bellsouth.net <mailto:marcsb at bellsouth.net>" <marcsb at bellsouth.net <mailto:marcsb at bellsouth.net>>
>>>>> Cc: "obaidasyed at gmail.com <mailto:obaidasyed at gmail.com>" <obaidasyed at gmail.com <mailto:obaidasyed at gmail.com>>
>>>>> 
>>>>> 
>>>>> 100,000 ping requests:
>>>>> 
>>>>> UCLA (spurs) to PKU (loss of 10 packets)
>>>>> 
>>>>> ndnops at spurs:~$ sudo ping -q -i 0.01 -c 100000 162.105.146.26
>>>>> PING 162.105.146.26 (162.105.146.26) 56(84) bytes of data.
>>>>> 
>>>>> --- 162.105.146.26 ping statistics ---
>>>>> 100000 packets transmitted, 99990 received, 0% packet loss, time 1112399ms
>>>>> rtt min/avg/max/mdev = 148.080/155.447/970.675/43.102 ms, pipe 96
>>>>> 
>>>>> 
>>>>> 
>>>>> TONGJI to CAIDA (loss of 8 packets):
>>>>> 
>>>>> ndnops at ndnops:~$ sudo ping -q -i 0.01 -c 100000 click.caida.org <http://click.caida.org/>
>>>>> PING click.caida.org <http://click.caida.org/> (192.172.226.248) 56(84) bytes of data.
>>>>> 
>>>>> --- click.caida.org <http://click.caida.org/> ping statistics ---
>>>>> 100000 packets transmitted, 99992 received, 0% packet loss, time 1371267ms
>>>>> rtt min/avg/max/mdev = 181.647/202.676/251.866/12.110 ms, pipe 19
>>>>> 
>>>>> On 8/19/14, 2:37 PM, John DeHart wrote:
>>>>>> 
>>>>>> And here is a similar pair of results for 10000 pings trying at 100 requests per second.
>>>>>> Let me know if this level of result helps at all.
>>>>>> 
>>>>>> UCLA (spurs) to PKU:
>>>>>> 
>>>>>> ndnops at spurs:~$ sudo ping -q -i 0.01 -c 10000 162.105.146.26
>>>>>> PING 162.105.146.26 (162.105.146.26) 56(84) bytes of data.
>>>>>> 
>>>>>> --- 162.105.146.26 ping statistics ---
>>>>>> 10000 packets transmitted, 10000 received, 0% packet loss, time 109146ms
>>>>>> rtt min/avg/max/mdev = 148.050/154.401/631.033/39.391 ms, pipe 63
>>>>>> ndnops at spurs:~$
>>>>>> 
>>>>>> 
>>>>>> TONGJI to CAIDA (1 loss out of 10000)
>>>>>> 
>>>>>> ndnops at ndnops:~$ sudo ping -q -i 0.01 -c 10000 click.caida.org <http://click.caida.org/>
>>>>>> PING click.caida.org <http://click.caida.org/> (192.172.226.248) 56(84) bytes of data.
>>>>>> 
>>>>>> --- click.caida.org <http://click.caida.org/> ping statistics ---
>>>>>> 10000 packets transmitted, 9999 received, 0% packet loss, time 136946ms
>>>>>> rtt min/avg/max/mdev = 181.710/193.677/210.785/5.104 ms, pipe 17
>>>>>> ndnops at ndnops:~$
>>>>>> On 8/19/14, 2:22 PM, John DeHart wrote:
>>>>>>> 
>>>>>>> Here are two initial tests doing 1000 ping requests,
>>>>>>> using approximately 10 ping requests per second.
>>>>>>> 
>>>>>>> UCLA (spurs) to PKU:
>>>>>>> ndnops at spurs:~$ sudo ping -q -i 0.1 -c 1000 162.105.146.26
>>>>>>> PING 162.105.146.26 (162.105.146.26) 56(84) bytes of data.
>>>>>>> 
>>>>>>> --- 162.105.146.26 ping statistics ---
>>>>>>> 1000 packets transmitted, 1000 received, 0% packet loss, time 100958ms
>>>>>>> rtt min/avg/max/mdev = 148.277/166.666/597.244/67.553 ms, pipe 6
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> TONGJI to CAIDA:
>>>>>>> ndnops at ndnops:~$ sudo ping -q -i 0.1 -c 1000 click.caida.org <http://click.caida.org/>
>>>>>>> PING click.caida.org <http://click.caida.org/> (192.172.226.248) 56(84) bytes of data.
>>>>>>> 
>>>>>>> --- click.caida.org <http://click.caida.org/> ping statistics ---
>>>>>>> 1000 packets transmitted, 1000 received, 0% packet loss, time 106763ms
>>>>>>> rtt min/avg/max/mdev = 181.729/224.260/270.358/19.935 ms, pipe 3
>>>>>>> 
>>>>>>> John
>>> 
> 

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

From shijunxiao at email.arizona.edu  Sun Feb 15 20:14:49 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Sun, 15 Feb 2015 21:14:49 -0700
Subject: [Nfd-dev] Signed Interest processing: alternate to stop-and-wait
Message-ID: <CAOFH+OZyN8CWKM07DzRjS9R_=RtYZBWs5wdLzhLT_JtFn5TH7A@mail.gmail.com>

Dear folks

During the resolution of #1990, SignedInterestProcessing
<http://redmine.named-data.net/projects/ndn-cxx/wiki/SignedInterestProcessing>
wiki
page recommends stop-and-wait in order to fit the validation procedure.

Stop-and-wait is easy to implement but is not a good design because it
throttles command rate. Sliding window such as that used by TCP is a better
solution for Interest ordering.
A sliding window based validation procedure could be: a signed Interest is
accepted if its timestamp is greater than (latestTimestamp - windowSize),
and it hasn't been accepted previously.

The risk is: an attacker can intercept (and block to transmission of) an
earlier command, and replay it later.
Depending on the nature of the command, this attack may or may not cause
harmful effect.

   - "1. turn on kitchen light" "2. turn on bedroom light": reordering
   doesn't change final state; if the intention is to turn on both lights
   without caring the order, it's acceptable
   - "1. set light to red" "2. set light to green": reordering causes an
   undesirable final state

I think this risk is acceptable, given the risk is always controllable by
the requester:

   - when order of execution doesn't matter (such as in first example), the
   requester can send multiple commands together
   - when reordering (either by network or by attacker) will cause
   undesirable effects (such as in second example), the requester can adopt
   stop-and-wait: don't send the second batch of commands before all commands
   in the first batch are complete


What do others on this mailing list think?

Yours, Junxiao

On Sat, Feb 14, 2015 at 8:16 AM, Beichuan Zhang <bzhang at cs.arizona.edu>
wrote:

> NDN network doesn?t guarantee in-order delivery; the end consumer, either
> implemented in app or in library, should handle out-of-order packets. This
> situation is no different from IP.
>
> I don?t understand why the love of stop-and-wait. Not only did you mention
> it in this email, but also on the wiki page as a suggested design. Look,
> you used stop-and-slow because it?s easy to implement, not because it has
> better features. The traditional sliding window that TCP uses can do the
> same and better, and there are other ways to ensure packet order. Just your
> app uses stop-and-wait doesn?t mean it?s a good one for others. You should
> stop making such a recommendation, e.g., remove it from the wiki.
>
> Beichuan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150215/2dd62c4d/attachment.html>

From lanwang at memphis.edu  Tue Feb 17 12:07:28 2015
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Tue, 17 Feb 2015 20:07:28 +0000
Subject: [Nfd-dev] Signed Interest processing: alternate to stop-and-wait
In-Reply-To: <CAOFH+OZyN8CWKM07DzRjS9R_=RtYZBWs5wdLzhLT_JtFn5TH7A@mail.gmail.com>
References: <CAOFH+OZyN8CWKM07DzRjS9R_=RtYZBWs5wdLzhLT_JtFn5TH7A@mail.gmail.com>
Message-ID: <FEE72A0C-1183-4795-8AE4-C79739D10076@memphis.edu>



On Feb 15, 2015, at 10:14 PM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:

Dear folks

During the resolution of #1990, SignedInterestProcessing<http://redmine.named-data.net/projects/ndn-cxx/wiki/SignedInterestProcessing> wiki page recommends stop-and-wait in order to fit the validation procedure.

Stop-and-wait is easy to implement but is not a good design because it throttles command rate. Sliding window such as that used by TCP is a better solution for Interest ordering.
A sliding window based validation procedure could be: a signed Interest is accepted if its timestamp is greater than (latestTimestamp - windowSize), and it hasn't been accepted previously.

If you always check "it hasn't been accepted previously.", how can an attacker replay it (below)?

Lan

The risk is: an attacker can intercept (and block to transmission of) an earlier command, and replay it later.
Depending on the nature of the command, this attack may or may not cause harmful effect.

  *   "1. turn on kitchen light" "2. turn on bedroom light": reordering doesn't change final state; if the intention is to turn on both lights without caring the order, it's acceptable
  *   "1. set light to red" "2. set light to green": reordering causes an undesirable final state

I think this risk is acceptable, given the risk is always controllable by the requester:

  *   when order of execution doesn't matter (such as in first example), the requester can send multiple commands together
  *   when reordering (either by network or by attacker) will cause undesirable effects (such as in second example), the requester can adopt stop-and-wait: don't send the second batch of commands before all commands in the first batch are complete

What do others on this mailing list think?

Yours, Junxiao

On Sat, Feb 14, 2015 at 8:16 AM, Beichuan Zhang <bzhang at cs.arizona.edu<mailto:bzhang at cs.arizona.edu>> wrote:
NDN network doesn?t guarantee in-order delivery; the end consumer, either implemented in app or in library, should handle out-of-order packets. This situation is no different from IP.

I don?t understand why the love of stop-and-wait. Not only did you mention it in this email, but also on the wiki page as a suggested design. Look, you used stop-and-slow because it?s easy to implement, not because it has better features. The traditional sliding window that TCP uses can do the same and better, and there are other ways to ensure packet order. Just your app uses stop-and-wait doesn?t mean it?s a good one for others. You should stop making such a recommendation, e.g., remove it from the wiki.

Beichuan
_______________________________________________
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/20150217/20429d7f/attachment.html>

From yingdi at CS.UCLA.EDU  Tue Feb 17 13:05:29 2015
From: yingdi at CS.UCLA.EDU (Yingdi Yu)
Date: Tue, 17 Feb 2015 13:05:29 -0800
Subject: [Nfd-dev] Signed Interest processing: alternate to stop-and-wait
In-Reply-To: <CAOFH+OZyN8CWKM07DzRjS9R_=RtYZBWs5wdLzhLT_JtFn5TH7A@mail.gmail.com>
References: <CAOFH+OZyN8CWKM07DzRjS9R_=RtYZBWs5wdLzhLT_JtFn5TH7A@mail.gmail.com>
Message-ID: <34C72100-76E8-4C4C-BFC6-EAE92FB404AF@cs.ucla.edu>

I do not like the idea of handling timestamp and nonce in the validator. The validator checks signatures. The timestamp and nonce is not the attributes of signatures but the attribute of the command. So timestamp and nonce should be handled by those which process the command. 

Actually, there are a variety of mechanisms to check timestamps. If we move the timestamp and nonce checking out of validator, then applications can freely choose the timestamp checking mechanism that fits their requirement best. Say if stop-and-wait fits the requirements of an app, then there is no need to use or implement sliding window. If strong sequencing is required, the app may use the timestamp as a session id and append sequence number after the timestamp, and then the nonce. For commands in the same session, they can be issued without waiting for the ack from the other side. 

I just do not feel it correct if we hardcode the timestamp checking procedure as a part of signature verification, because it forces every application to use the same timestamp checking mechanism. This is my 2 cents.

Yingdi



> On Feb 15, 2015, at 8:14 PM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:
> 
> Dear folks
> 
> During the resolution of #1990, SignedInterestProcessing <http://redmine.named-data.net/projects/ndn-cxx/wiki/SignedInterestProcessing> wiki page recommends stop-and-wait in order to fit the validation procedure.
> 
> Stop-and-wait is easy to implement but is not a good design because it throttles command rate. Sliding window such as that used by TCP is a better solution for Interest ordering.
> A sliding window based validation procedure could be: a signed Interest is accepted if its timestamp is greater than (latestTimestamp - windowSize), and it hasn't been accepted previously.
> 
> The risk is: an attacker can intercept (and block to transmission of) an earlier command, and replay it later.
> Depending on the nature of the command, this attack may or may not cause harmful effect.
> "1. turn on kitchen light" "2. turn on bedroom light": reordering doesn't change final state; if the intention is to turn on both lights without caring the order, it's acceptable
> "1. set light to red" "2. set light to green": reordering causes an undesirable final state
> I think this risk is acceptable, given the risk is always controllable by the requester:
> when order of execution doesn't matter (such as in first example), the requester can send multiple commands together
> when reordering (either by network or by attacker) will cause undesirable effects (such as in second example), the requester can adopt stop-and-wait: don't send the second batch of commands before all commands in the first batch are complete
> 
> What do others on this mailing list think?
> 
> Yours, Junxiao
> 
> On Sat, Feb 14, 2015 at 8:16 AM, Beichuan Zhang <bzhang at cs.arizona.edu <mailto:bzhang at cs.arizona.edu>> wrote:
> NDN network doesn?t guarantee in-order delivery; the end consumer, either implemented in app or in library, should handle out-of-order packets. This situation is no different from IP.
> 
> I don?t understand why the love of stop-and-wait. Not only did you mention it in this email, but also on the wiki page as a suggested design. Look, you used stop-and-slow because it?s easy to implement, not because it has better features. The traditional sliding window that TCP uses can do the same and better, and there are other ways to ensure packet order. Just your app uses stop-and-wait doesn?t mean it?s a good one for others. You should stop making such a recommendation, e.g., remove it from the wiki.
> 
> Beichuan

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

From jburke at remap.UCLA.EDU  Tue Feb 17 22:19:33 2015
From: jburke at remap.UCLA.EDU (Burke, Jeff)
Date: Wed, 18 Feb 2015 06:19:33 +0000
Subject: [Nfd-dev] Signed Interest processing: alternate to stop-and-wait
In-Reply-To: <34C72100-76E8-4C4C-BFC6-EAE92FB404AF@cs.ucla.edu>
Message-ID: <D1096BE2.1B8C3A%jburke@remap.ucla.edu>

Hi Yingdi,

I thought one design motivation for the security libraries was to implement some widely-applicable techniques so as to avoid likely security screw-ups in applications?  Is that something to consider here?

Also, is it practical that the average application would to have to implement timestamp/nonce checking itself to just handle a signed interest?  Even if it's not that hard, this seems way too detailed?and unrelated to the actual functionality of many applications?for many straightforward apps that might still use Signed Interests.

A possibility would be to offer one or more "standard" timestamp/nonce checking approaches in the library but at the same time allow applications that have different needs to override them.   There might be more likelihood of application interoperability if such standard techniques are widely available, too.

As with encryption, perhaps it make sense for these capabilities to be implemented in another library "on top of" a core library that only does verification of signatures... but this second library is still useful to flesh out at this point, I think.

Just a thought...

Thanks,
Jeff



From: Yingdi Yu <yingdi at CS.UCLA.EDU<mailto:yingdi at CS.UCLA.EDU>>
Date: Tue, 17 Feb 2015 13:05:29 -0800
To: Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>>
Cc: "<nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>" <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: Re: [Nfd-dev] Signed Interest processing: alternate to stop-and-wait

I do not like the idea of handling timestamp and nonce in the validator. The validator checks signatures. The timestamp and nonce is not the attributes of signatures but the attribute of the command. So timestamp and nonce should be handled by those which process the command.

Actually, there are a variety of mechanisms to check timestamps. If we move the timestamp and nonce checking out of validator, then applications can freely choose the timestamp checking mechanism that fits their requirement best. Say if stop-and-wait fits the requirements of an app, then there is no need to use or implement sliding window. If strong sequencing is required, the app may use the timestamp as a session id and append sequence number after the timestamp, and then the nonce. For commands in the same session, they can be issued without waiting for the ack from the other side.

I just do not feel it correct if we hardcode the timestamp checking procedure as a part of signature verification, because it forces every application to use the same timestamp checking mechanism. This is my 2 cents.

Yingdi



On Feb 15, 2015, at 8:14 PM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:

Dear folks

During the resolution of #1990, SignedInterestProcessing<http://redmine.named-data.net/projects/ndn-cxx/wiki/SignedInterestProcessing> wiki page recommends stop-and-wait in order to fit the validation procedure.

Stop-and-wait is easy to implement but is not a good design because it throttles command rate. Sliding window such as that used by TCP is a better solution for Interest ordering.
A sliding window based validation procedure could be: a signed Interest is accepted if its timestamp is greater than (latestTimestamp - windowSize), and it hasn't been accepted previously.

The risk is: an attacker can intercept (and block to transmission of) an earlier command, and replay it later.
Depending on the nature of the command, this attack may or may not cause harmful effect.

  *   "1. turn on kitchen light" "2. turn on bedroom light": reordering doesn't change final state; if the intention is to turn on both lights without caring the order, it's acceptable
  *   "1. set light to red" "2. set light to green": reordering causes an undesirable final state

I think this risk is acceptable, given the risk is always controllable by the requester:

  *   when order of execution doesn't matter (such as in first example), the requester can send multiple commands together
  *   when reordering (either by network or by attacker) will cause undesirable effects (such as in second example), the requester can adopt stop-and-wait: don't send the second batch of commands before all commands in the first batch are complete

What do others on this mailing list think?

Yours, Junxiao

On Sat, Feb 14, 2015 at 8:16 AM, Beichuan Zhang <bzhang at cs.arizona.edu<mailto:bzhang at cs.arizona.edu>> wrote:
NDN network doesn?t guarantee in-order delivery; the end consumer, either implemented in app or in library, should handle out-of-order packets. This situation is no different from IP.

I don?t understand why the love of stop-and-wait. Not only did you mention it in this email, but also on the wiki page as a suggested design. Look, you used stop-and-slow because it?s easy to implement, not because it has better features. The traditional sliding window that TCP uses can do the same and better, and there are other ways to ensure packet order. Just your app uses stop-and-wait doesn?t mean it?s a good one for others. You should stop making such a recommendation, e.g., remove it from the wiki.

Beichuan

_______________________________________________ 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/20150218/df5a7664/attachment.html>

From yingdi at CS.UCLA.EDU  Wed Feb 18 10:01:03 2015
From: yingdi at CS.UCLA.EDU (Yingdi Yu)
Date: Wed, 18 Feb 2015 10:01:03 -0800
Subject: [Nfd-dev] Signed Interest processing: alternate to stop-and-wait
In-Reply-To: <D1096BE2.1B8C3A%jburke@remap.ucla.edu>
References: <D1096BE2.1B8C3A%jburke@remap.ucla.edu>
Message-ID: <FD30B726-3260-40FC-97ED-DB984D7CAB9A@cs.ucla.edu>

Hi Jeff,

I did not mean the timestamp and nonce checking should be done outside of the security library. I just thought it should not be a part of a validator. We used to have a design that the validator is wrapped by another abstraction with a specific timestamp checking logic, so that the security library may provide different abstractions with their timestamp checking logic, and application can use which one to use. 

However, there were some different opinion that timestamp checking should be moved into validator, and the argument is that there should not be more than one mechanism to check timestamp, then the timestamp checking is moved into validator. 

Yingdi




> On Feb 17, 2015, at 10:19 PM, Burke, Jeff <jburke at remap.ucla.edu> wrote:
> 
> Hi Yingdi, 
> 
> I thought one design motivation for the security libraries was to implement some widely-applicable techniques so as to avoid likely security screw-ups in applications?  Is that something to consider here? 
> 
> Also, is it practical that the average application would to have to implement timestamp/nonce checking itself to just handle a signed interest?  Even if it's not that hard, this seems way too detailed?and unrelated to the actual functionality of many applications?for many straightforward apps that might still use Signed Interests.
> 
> A possibility would be to offer one or more "standard" timestamp/nonce checking approaches in the library but at the same time allow applications that have different needs to override them.   There might be more likelihood of application interoperability if such standard techniques are widely available, too.  
> 
> As with encryption, perhaps it make sense for these capabilities to be implemented in another library "on top of" a core library that only does verification of signatures... but this second library is still useful to flesh out at this point, I think.
> 
> Just a thought... 
> 
> Thanks,
> Jeff
> 
> 
> 
> From: Yingdi Yu <yingdi at CS.UCLA.EDU <mailto:yingdi at CS.UCLA.EDU>>
> Date: Tue, 17 Feb 2015 13:05:29 -0800
> To: Junxiao Shi <shijunxiao at email.arizona.edu <mailto:shijunxiao at email.arizona.edu>>
> Cc: "<nfd-dev at lists.cs.ucla.edu <mailto:nfd-dev at lists.cs.ucla.edu>>" <nfd-dev at lists.cs.ucla.edu <mailto:nfd-dev at lists.cs.ucla.edu>>
> Subject: Re: [Nfd-dev] Signed Interest processing: alternate to stop-and-wait
> 
>> I do not like the idea of handling timestamp and nonce in the validator. The validator checks signatures. The timestamp and nonce is not the attributes of signatures but the attribute of the command. So timestamp and nonce should be handled by those which process the command. 
>> 
>> Actually, there are a variety of mechanisms to check timestamps. If we move the timestamp and nonce checking out of validator, then applications can freely choose the timestamp checking mechanism that fits their requirement best. Say if stop-and-wait fits the requirements of an app, then there is no need to use or implement sliding window. If strong sequencing is required, the app may use the timestamp as a session id and append sequence number after the timestamp, and then the nonce. For commands in the same session, they can be issued without waiting for the ack from the other side. 
>> 
>> I just do not feel it correct if we hardcode the timestamp checking procedure as a part of signature verification, because it forces every application to use the same timestamp checking mechanism. This is my 2 cents.
>> 
>> Yingdi
>> 
>> 
>> 
>>> On Feb 15, 2015, at 8:14 PM, Junxiao Shi <shijunxiao at email.arizona.edu <mailto:shijunxiao at email.arizona.edu>> wrote:
>>> 
>>> Dear folks
>>> 
>>> During the resolution of #1990, SignedInterestProcessing <http://redmine.named-data.net/projects/ndn-cxx/wiki/SignedInterestProcessing> wiki page recommends stop-and-wait in order to fit the validation procedure.
>>> 
>>> Stop-and-wait is easy to implement but is not a good design because it throttles command rate. Sliding window such as that used by TCP is a better solution for Interest ordering.
>>> A sliding window based validation procedure could be: a signed Interest is accepted if its timestamp is greater than (latestTimestamp - windowSize), and it hasn't been accepted previously.
>>> 
>>> The risk is: an attacker can intercept (and block to transmission of) an earlier command, and replay it later.
>>> Depending on the nature of the command, this attack may or may not cause harmful effect.
>>> "1. turn on kitchen light" "2. turn on bedroom light": reordering doesn't change final state; if the intention is to turn on both lights without caring the order, it's acceptable
>>> "1. set light to red" "2. set light to green": reordering causes an undesirable final state
>>> I think this risk is acceptable, given the risk is always controllable by the requester:
>>> when order of execution doesn't matter (such as in first example), the requester can send multiple commands together
>>> when reordering (either by network or by attacker) will cause undesirable effects (such as in second example), the requester can adopt stop-and-wait: don't send the second batch of commands before all commands in the first batch are complete
>>> 
>>> What do others on this mailing list think?
>>> 
>>> Yours, Junxiao
>>> 
>>> On Sat, Feb 14, 2015 at 8:16 AM, Beichuan Zhang <bzhang at cs.arizona.edu <mailto:bzhang at cs.arizona.edu>> wrote:
>>>> NDN network doesn?t guarantee in-order delivery; the end consumer, either implemented in app or in library, should handle out-of-order packets. This situation is no different from IP.
>>>> 
>>>> I don?t understand why the love of stop-and-wait. Not only did you mention it in this email, but also on the wiki page as a suggested design. Look, you used stop-and-slow because it?s easy to implement, not because it has better features. The traditional sliding window that TCP uses can do the same and better, and there are other ways to ensure packet order. Just your app uses stop-and-wait doesn?t mean it?s a good one for others. You should stop making such a recommendation, e.g., remove it from the wiki.
>>>> 
>>>> Beichuan
>> 
>> _______________________________________________ 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/20150218/57a5c158/attachment.html>

From josh at caida.org  Wed Feb 18 10:02:06 2015
From: josh at caida.org (Josh Polterock)
Date: Wed, 18 Feb 2015 10:02:06 -0800
Subject: [Nfd-dev] Error installing nfd @0.3.0_0 on Mac OSX 10.9.5
In-Reply-To: <ACCFAB96-A567-497E-91A7-DE6602D23B8E@cs.ucla.edu>
References: <20150210190714.GV72603@caida.org>
	<CAOFH+Obu+LbRUWiC+BynuZb-zzuf+WLco3_F7gJhYeSFh-fAVQ@mail.gmail.com>
	<20150210203152.GZ72603@caida.org>
	<ACCFAB96-A567-497E-91A7-DE6602D23B8E@cs.ucla.edu>
Message-ID: <20150218180206.GH1596@caida.org>

Alex,

I'm following up on your last message regarding ports install of NFD.

Currently, starting from scratch, ndn-cxx installs without error. When 
I do the install of NFD, (on my desktop iMac running 10.9.5) it
completes the install with the error below. I've attached the resulting
log file.

Josh

tao:~ $ sudo port install nfd
Password:
--->  Computing dependencies for nfd
--->  Fetching archive for nfd
--->  Attempting to fetch nfd-0.3.0_0.darwin_13.x86_64.tbz2 from http://packages.macports.org/nfd
--->  Attempting to fetch nfd-0.3.0_0.darwin_13.x86_64.tbz2 from http://lil.fr.packages.macports.org/nfd
--->  Attempting to fetch nfd-0.3.0_0.darwin_13.x86_64.tbz2 from http://nue.de.packages.macports.org/macports/packages/nfd
--->  Fetching distfiles for nfd
--->  Verifying checksums for nfd
--->  Extracting nfd
--->  Configuring nfd
--->  Building nfd
--->  Staging nfd into destroot
--->  Installing nfd @0.3.0_0
--->  Activating nfd @0.3.0_0


To start NFD and ensure it is started when system boots:

    nfd-start

To stop NFD and disable auto-start when system boots:

    nfd-stop

NFD log files are located in /opt/local/var/log/ndn/

Configuration file is in /opt/local/var/etc/ndn/

Error: org.macports.activate for port nfd returned: command execution
failed
Please see the log file for port nfd for details:
    /opt/local/var/macports/logs/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/main.log
To report a bug, follow the instructions in the guide:
    http://guide.macports.org/#project.tickets
Error: Processing of port nfd failed


On Tue, Feb 10, 2015 at 12:36:52PM -0800, Alex Afanasyev wrote:
> Hi Josh,
> 
> I need to double check default configuration that comes with macports.  It may be a little wrong.  Deleting /opt/local/var/lib/ndn/nfd/.ndn would not solve the problem, as there are a few security restrictions when running macports.
> 
> ---
> Alex
> 
> > On Feb 10, 2015, at 12:31 PM, Josh Polterock <josh at caida.org> wrote:
> > 
> > On Tue, Feb 10, 2015 at 01:24:07PM -0700, Junxiao Shi wrote:
> >> Hi Josh
> >> 
> >> Log says:
> >> :info:activate ERROR: TPM locator supplied does not match TPM locator in
> >> PIB: file: != tpm-file:
> >> :info:activate Command failed: HOME=/opt/local/var/lib/ndn/nfd
> >> ndnsec-keygen /localhost/daemons/nfd |  HOME=/opt/local/var/lib/ndn/nfd
> >> ndnsec-install-cert -
> >> :info:activate Exit code: 1
> >> 
> >> This seems related to one or more of #2242, #2384, #2391.
> >> @Yingdi and @Alex should take a look.
> >> 
> >> I'm not sure what you mean by "completely clean install".
> >> Does the system have NFD installed previously and you have uninstalled it,
> >> or does the system never have ndn-cxx and NFD previously?
> > 
> > The system had nfd and ndn-cxx installed previously.
> > 
> > I simply mean that I did a port uninstall of nfd and ndn-cxx. 
> > 
> >> 
> >> The workaround is:
> >> sudo rm -rf /opt/local/var/lib/ndn/nfd/.ndn
> > 
> > I executed this command. Should nfd then start?
> > 
> > Thanks,
> > Josh
> > 
> >> 
> >> Yours, Junxiao
> >> 
> >> On Tue, Feb 10, 2015 at 12:07 PM, Josh Polterock <josh at caida.org> wrote:
> >> 
> >>> I'm trying to do a completely clean install of NFD using ports.
> >>> The ndn-cxx install completed successfully. The NFD install
> >>> completes but finishes with the following error
> >>> 
> >>> --->  Computing dependencies for nfd
> >>> --->  Fetching archive for nfd
> >>> --->  Attempting to fetch nfd-0.3.0_0.darwin_13.x86_64.tbz2 from
> >>> http://packages.macports.org/nfd
> >>> --->  Attempting to fetch nfd-0.3.0_0.darwin_13.x86_64.tbz2 from
> >>> http://nue.de.packages.macports.org/macports/packages/nfd
> >>> --->  Attempting to fetch nfd-0.3.0_0.darwin_13.x86_64.tbz2 from
> >>> http://mse.uk.packages.macports.org/sites/packages.macports.org/nfd
> >>> --->  Fetching distfiles for nfd
> >>> --->  Attempting to fetch NFD-NFD-0.3.0.tar.gz from
> >>> http://distfiles.macports.org/nfd
> >>> --->  Attempting to fetch NFD-NFD-0.3.0.tar.gz from
> >>> http://sea.us.distfiles.macports.org/macports/distfiles/nfd
> >>> --->  Attempting to fetch NFD-NFD-0.3.0.tar.gz from
> >>> https://github.com/named-data/NFD/tarball/NFD-0.3.0
> >>> --->  Verifying checksums for nfd
> >>> --->  Extracting nfd
> >>> --->  Configuring nfd
> >>> --->  Building nfd
> >>> --->  Staging nfd into destroot
> >>> --->  Installing nfd @0.3.0_0
> >>> --->  Activating nfd @0.3.0_0
> >>> 
> >>> 
> >>> To start NFD and ensure it is started when system boots:
> >>> 
> >>>    nfd-start
> >>> 
> >>> To stop NFD and disable auto-start when system boots:
> >>> 
> >>>    nfd-stop
> >>> 
> >>> NFD log files are located in /opt/local/var/log/ndn/
> >>> 
> >>> Configuration file is in /opt/local/var/etc/ndn/
> >>> 
> >>> Error: org.macports.activate for port nfd returned: command execution
> >>> failed
> >>> Please see the log file for port nfd for details:
> >>> 
> >>> /opt/local/var/macports/logs/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/main.log
> >>> To report a bug, follow the instructions in the guide:
> >>>    http://guide.macports.org/#project.tickets
> >>> Error: Processing of port nfd failed
> >>> 
> >>> _______________________________________________
> >>> Nfd-dev mailing list
> >>> Nfd-dev at lists.cs.ucla.edu
> >>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
-------------- next part --------------
version:1
:debug:main epoch: in tree: 0 installed: 0
:debug:main pkgconfig 0.28_0 exists in the ports tree
:debug:main pkgconfig 0.28_0  is the latest installed
:debug:main pkgconfig 0.28_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/devel/pkgconfig
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main adding the default universal variant
:debug:main Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/variant_descriptions.conf
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! pkgconfig 0.28_0 >= pkgconfig 0.28_0
:debug:main epoch: in tree: 0 installed: 0
:debug:main libiconv 1.14_0 exists in the ports tree
:debug:main libiconv 1.14_0  is the latest installed
:debug:main libiconv 1.14_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/textproc/libiconv
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/variant_descriptions.conf
:debug:main Sourcing PortGroup muniversal 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/muniversal-1.0.tcl
:debug:main universal variant already exists, so not adding the default one
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! libiconv 1.14_0 >= libiconv 1.14_0
:debug:main epoch: in tree: 0 installed: 0
:debug:main py27-sphinx 1.2.3_0 exists in the ports tree
:debug:main py27-sphinx 1.2.3_0  is the latest installed
:debug:main py27-sphinx 1.2.3_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/python/py-sphinx
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main Re-registering default for build.cmd
:debug:main Re-registering default for destroot.cmd
:debug:main Re-registering default for destroot.destdir
:debug:main Sourcing PortGroup python 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/python-1.0.tcl
:debug:main Sourcing PortGroup select 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/select-1.0.tcl
:debug:main only one arch supported, so not adding the default universal variant
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! py27-sphinx 1.2.3_0 >= py27-sphinx 1.2.3_0
:debug:main epoch: in tree: 0 installed: 0
:debug:main py27-docutils 0.12_0 exists in the ports tree
:debug:main py27-docutils 0.12_0  is the latest installed
:debug:main py27-docutils 0.12_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/python/py-docutils
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main Re-registering default for build.cmd
:debug:main Re-registering default for destroot.cmd
:debug:main Re-registering default for destroot.destdir
:debug:main Sourcing PortGroup python 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/python-1.0.tcl
:debug:main only one arch supported, so not adding the default universal variant
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! py27-docutils 0.12_0 >= py27-docutils 0.12_0
:debug:main epoch: in tree: 0 installed: 0
:debug:main py27-roman 2.0.0_0 exists in the ports tree
:debug:main py27-roman 2.0.0_0  is the latest installed
:debug:main py27-roman 2.0.0_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/python/py-roman
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main Re-registering default for build.cmd
:debug:main Re-registering default for destroot.cmd
:debug:main Re-registering default for destroot.destdir
:debug:main Sourcing PortGroup python 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/python-1.0.tcl
:debug:main only one arch supported, so not adding the default universal variant
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! py27-roman 2.0.0_0 >= py27-roman 2.0.0_0
:debug:main epoch: in tree: 2 installed: 2
:debug:main python27 2.7.9_0 exists in the ports tree
:debug:main python27 2.7.9_0  is the latest installed
:debug:main python27 2.7.9_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/lang/python27
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main Sourcing PortGroup select 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/select-1.0.tcl
:debug:main Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/variant_descriptions.conf
:debug:main universal variant already exists, so not adding the default one
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! python27 2.7.9_0 >= python27 2.7.9_0
:debug:main epoch: in tree: 2 installed: 2
:debug:main gettext 0.19.4_0 exists in the ports tree
:debug:main gettext 0.19.4_0  is the latest installed
:debug:main gettext 0.19.4_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/devel/gettext
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main Sourcing PortGroup compiler_blacklist_versions 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/compiler_blacklist_versions-1.0.tcl
:debug:main Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/variant_descriptions.conf
:debug:main Sourcing PortGroup muniversal 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/muniversal-1.0.tcl
:debug:main compiler clang 600.0.56 not blacklisted because it doesn't match {clang < 211.10.1}
:debug:main universal variant already exists, so not adding the default one
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! gettext 0.19.4_0 >= gettext 0.19.4_0
:debug:main epoch: in tree: 0 installed: 0
:debug:main expat 2.1.0_0 exists in the ports tree
:debug:main expat 2.1.0_0  is the latest installed
:debug:main expat 2.1.0_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/textproc/expat
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main adding the default universal variant
:debug:main Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/variant_descriptions.conf
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! expat 2.1.0_0 >= expat 2.1.0_0
:debug:main epoch: in tree: 0 installed: 0
:debug:main ncurses 5.9_2 exists in the ports tree
:debug:main ncurses 5.9_2  is the latest installed
:debug:main ncurses 5.9_2  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/devel/ncurses
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main adding the default universal variant
:debug:main Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/variant_descriptions.conf
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! ncurses 5.9_2 >= ncurses 5.9_2
:debug:main epoch: in tree: 0 installed: 0
:debug:main zlib 1.2.8_0 exists in the ports tree
:debug:main zlib 1.2.8_0  is the latest installed
:debug:main zlib 1.2.8_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/archivers/zlib
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main Sourcing PortGroup xcodeversion 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/xcodeversion-1.0.tcl
:debug:main adding the default universal variant
:debug:main Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/variant_descriptions.conf
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! zlib 1.2.8_0 >= zlib 1.2.8_0
:debug:main epoch: in tree: 1 installed: 1
:debug:main openssl 1.0.2_0 exists in the ports tree
:debug:main openssl 1.0.2_0  is the latest installed
:debug:main openssl 1.0.2_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/devel/openssl
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/variant_descriptions.conf
:debug:main Sourcing PortGroup muniversal 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/muniversal-1.0.tcl
:debug:main universal variant already exists, so not adding the default one
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! openssl 1.0.2_0 >= openssl 1.0.2_0
:debug:main epoch: in tree: 0 installed: 0
:debug:main sqlite3 3.8.8.2_0 exists in the ports tree
:debug:main sqlite3 3.8.8.2_0  is the latest installed
:debug:main sqlite3 3.8.8.2_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/databases/sqlite3
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main adding the default universal variant
:debug:main Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/variant_descriptions.conf
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! sqlite3 3.8.8.2_0 >= sqlite3 3.8.8.2_0
:debug:main epoch: in tree: 20090923 installed: 20090923
:debug:main libedit 20140620-3.1_0 exists in the ports tree
:debug:main libedit 20140620-3.1_0  is the latest installed
:debug:main libedit 20140620-3.1_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/devel/libedit
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/variant_descriptions.conf
:debug:main Sourcing PortGroup muniversal 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/muniversal-1.0.tcl
:debug:main universal variant already exists, so not adding the default one
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! libedit 20140620-3.1_0 >= libedit 20140620-3.1_0
:debug:main epoch: in tree: 0 installed: 0
:debug:main db48 4.8.30_4 exists in the ports tree
:debug:main db48 4.8.30_4  is the latest installed
:debug:main db48 4.8.30_4  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/databases/db48
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/variant_descriptions.conf
:debug:main Sourcing PortGroup muniversal 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/muniversal-1.0.tcl
:debug:main Sourcing PortGroup select 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/select-1.0.tcl
:debug:main universal variant already exists, so not adding the default one
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! db48 4.8.30_4 >= db48 4.8.30_4
:debug:main epoch: in tree: 0 installed: 0
:debug:main db_select 0.1_2 exists in the ports tree
:debug:main db_select 0.1_2  is the latest installed
:debug:main db_select 0.1_2  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/sysutils/db_select
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main Sourcing PortGroup select 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/select-1.0.tcl
:debug:main universal_variant is false, so not adding the default universal variant
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! db_select 0.1_2 >= db_select 0.1_2
:debug:main epoch: in tree: 0 installed: 0
:debug:main bzip2 1.0.6_0 exists in the ports tree
:debug:main bzip2 1.0.6_0  is the latest installed
:debug:main bzip2 1.0.6_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/archivers/bzip2
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/variant_descriptions.conf
:debug:main universal variant already exists, so not adding the default one
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! bzip2 1.0.6_0 >= bzip2 1.0.6_0
:debug:main epoch: in tree: 0 installed: 0
:debug:main python_select 0.3_4 exists in the ports tree
:debug:main python_select 0.3_4  is the latest installed
:debug:main python_select 0.3_4  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/sysutils/python_select
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main Sourcing PortGroup select 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/select-1.0.tcl
:debug:main universal_variant is false, so not adding the default universal variant
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! python_select 0.3_4 >= python_select 0.3_4
:debug:main epoch: in tree: 0 installed: 0
:debug:main py27-setuptools 12.1_0 exists in the ports tree
:debug:main py27-setuptools 12.1_0  is the latest installed
:debug:main py27-setuptools 12.1_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/python/py-setuptools
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main Re-registering default for build.cmd
:debug:main Re-registering default for destroot.cmd
:debug:main Re-registering default for destroot.destdir
:debug:main Sourcing PortGroup python 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/python-1.0.tcl
:debug:main only one arch supported, so not adding the default universal variant
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! py27-setuptools 12.1_0 >= py27-setuptools 12.1_0
:debug:main epoch: in tree: 0 installed: 0
:debug:main py27-pygments 2.0.2_0 exists in the ports tree
:debug:main py27-pygments 2.0.2_0  is the latest installed
:debug:main py27-pygments 2.0.2_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/python/py-pygments
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main Re-registering default for build.cmd
:debug:main Re-registering default for destroot.cmd
:debug:main Re-registering default for destroot.destdir
:debug:main Sourcing PortGroup python 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/python-1.0.tcl
:debug:main only one arch supported, so not adding the default universal variant
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! py27-pygments 2.0.2_0 >= py27-pygments 2.0.2_0
:debug:main epoch: in tree: 0 installed: 0
:debug:main py27-jinja2 2.7.3_0 exists in the ports tree
:debug:main py27-jinja2 2.7.3_0  is the latest installed
:debug:main py27-jinja2 2.7.3_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/python/py-jinja2
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main Re-registering default for build.cmd
:debug:main Re-registering default for destroot.cmd
:debug:main Re-registering default for destroot.destdir
:debug:main Sourcing PortGroup python 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/python-1.0.tcl
:debug:main only one arch supported, so not adding the default universal variant
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! py27-jinja2 2.7.3_0 >= py27-jinja2 2.7.3_0
:debug:main epoch: in tree: 0 installed: 0
:debug:main py27-markupsafe 0.23_0 exists in the ports tree
:debug:main py27-markupsafe 0.23_0  is the latest installed
:debug:main py27-markupsafe 0.23_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/python/py-markupsafe
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main Re-registering default for build.cmd
:debug:main Re-registering default for destroot.cmd
:debug:main Re-registering default for destroot.destdir
:debug:main Sourcing PortGroup python 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/python-1.0.tcl
:debug:main adding the default universal variant
:debug:main Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/variant_descriptions.conf
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! py27-markupsafe 0.23_0 >= py27-markupsafe 0.23_0
:debug:main epoch: in tree: 0 installed: 0
:debug:main sphinx_select 0.1_0 exists in the ports tree
:debug:main sphinx_select 0.1_0  is the latest installed
:debug:main sphinx_select 0.1_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/python/sphinx_select
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main Sourcing PortGroup select 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/select-1.0.tcl
:debug:main universal_variant is false, so not adding the default universal variant
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! sphinx_select 0.1_0 >= sphinx_select 0.1_0
:debug:main epoch: in tree: 3 installed: 3
:debug:main ndn-cxx 0.3.0_0 exists in the ports tree
:debug:main ndn-cxx 0.3.0_0  is the latest installed
:debug:main ndn-cxx 0.3.0_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/macports.named-data.net/macports/net/ndn-cxx
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main Sourcing PortGroup github 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/github-1.0.tcl
:debug:main adding the default universal variant
:debug:main Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/variant_descriptions.conf
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! ndn-cxx 0.3.0_0 >= ndn-cxx 0.3.0_0
:debug:main epoch: in tree: 0 installed: 0
:debug:main boost 1.57.0_0 exists in the ports tree
:debug:main boost 1.57.0_0 +no_single+no_static+python27 is the latest installed
:debug:main boost 1.57.0_0 +no_single+no_static+python27 is active
:debug:main Merging existing variants '+no_single+no_static+python27' into variants
:debug:main new fully merged portvariants: no_static + no_single + python27 +
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/devel/boost
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main Sourcing PortGroup compiler_blacklist_versions 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/compiler_blacklist_versions-1.0.tcl
:debug:main Sourcing PortGroup active_variants 1.1 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/active_variants-1.1.tcl
:debug:main Sourcing PortGroup compilers 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/compilers-1.0.tcl
:debug:main Sourcing PortGroup mpi 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/mpi-1.0.tcl
:debug:main compiler clang 600.0.56 not blacklisted because it doesn't match {clang < 421}
:debug:main Unmatched blacklisted compiler: macports-clang-2.9
:debug:main Unmatched blacklisted compiler: *gcc-4.0
:debug:main Unmatched blacklisted compiler: gcc-3.3
:debug:main Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/variant_descriptions.conf
:debug:main universal variant already exists, so not adding the default one
:debug:main Executing variant python27 provides python27
:debug:main Executing variant no_static provides no_static
:debug:main Executing variant no_single provides no_single
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! boost 1.57.0_0 >= boost 1.57.0_0
:debug:main epoch: in tree: 0 installed: 0
:debug:main icu 54.1_0 exists in the ports tree
:debug:main icu 54.1_0  is the latest installed
:debug:main icu 54.1_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/devel/icu
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/variant_descriptions.conf
:debug:main Sourcing PortGroup muniversal 1.0 from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/group/muniversal-1.0.tcl
:debug:main universal variant already exists, so not adding the default one
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! icu 54.1_0 >= icu 54.1_0
:debug:main epoch: in tree: 0 installed: 0
:debug:main libcryptopp 5.6.2_0 exists in the ports tree
:debug:main libcryptopp 5.6.2_0  is the latest installed
:debug:main libcryptopp 5.6.2_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/devel/libcryptopp
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/variant_descriptions.conf
:debug:main universal variant already exists, so not adding the default one
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! libcryptopp 5.6.2_0 >= libcryptopp 5.6.2_0
:debug:main epoch: in tree: 0 installed: 0
:debug:main libpcap 1.6.2_0 exists in the ports tree
:debug:main libpcap 1.6.2_0  is the latest installed
:debug:main libpcap 1.6.2_0  is active
:debug:main Merging existing variants '' into variants
:debug:main new fully merged portvariants: 
:debug:main Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/release/ports/net/libpcap
:debug:main OS darwin/13.4.0 (Mac OS X 10.9) arch i386
:debug:main adding the default universal variant
:debug:main Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/release/ports/_resources/port1.0/variant_descriptions.conf
:debug:main Running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Finished running callback portconfigure::add_automatic_compiler_dependencies
:debug:main Running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main Finished running callback portbuild::add_automatic_buildsystem_dependencies
:debug:main No need to upgrade! libpcap 1.6.2_0 >= libpcap 1.6.2_0
:msg:main --->  Computing dependencies for nfd:info:main .:debug:main nfd has no conflicts
:debug:main Searching for dependency: pkgconfig
:debug:main Found Dependency: receipt exists for pkgconfig
:debug:main Searching for dependency: py27-sphinx
:debug:main Found Dependency: receipt exists for py27-sphinx
:debug:main Searching for dependency: ndn-cxx
:debug:main Found Dependency: receipt exists for ndn-cxx
:debug:main Searching for dependency: libpcap
:debug:main Found Dependency: receipt exists for libpcap
:msg:main 
:debug:main Executing org.macports.main (nfd)
:debug:main changing euid/egid - current euid: 0 - current egid: 0
:debug:main egid changed to: 501
:debug:main euid changed to: 501
:debug:archivefetch archivefetch phase started at Wed Feb 18 09:57:11 PST 2015
:msg:archivefetch --->  Fetching archive for nfd
:debug:archivefetch Executing org.macports.archivefetch (nfd)
:debug:archivefetch euid/egid changed to: 0/0
:debug:archivefetch chowned /opt/local/var/macports/incoming to macports
:debug:archivefetch euid/egid changed to: 501/501
:info:archivefetch --->  nfd-0.3.0_0.darwin_13.x86_64.tbz2 doesn't seem to exist in /opt/local/var/macports/incoming/verified
:msg:archivefetch --->  Attempting to fetch nfd-0.3.0_0.darwin_13.x86_64.tbz2 from http://packages.macports.org/nfd
:debug:archivefetch Fetching archive failed:: The requested URL returned error: 404 Not Found
:msg:archivefetch --->  Attempting to fetch nfd-0.3.0_0.darwin_13.x86_64.tbz2 from http://lil.fr.packages.macports.org/nfd
:debug:archivefetch Fetching archive failed:: The requested URL returned error: 404 Not Found
:msg:archivefetch --->  Attempting to fetch nfd-0.3.0_0.darwin_13.x86_64.tbz2 from http://nue.de.packages.macports.org/macports/packages/nfd
:debug:archivefetch Fetching archive failed:: The requested URL returned error: 404 Not Found
:debug:archivefetch Privilege de-escalation not attempted as not running as root.
:debug:fetch fetch phase started at Wed Feb 18 09:57:11 PST 2015
:notice:fetch --->  Fetching distfiles for nfd
:debug:fetch Executing org.macports.fetch (nfd)
:debug:fetch Privilege de-escalation not attempted as not running as root.
:debug:checksum checksum phase started at Wed Feb 18 09:57:11 PST 2015
:notice:checksum --->  Verifying checksums for nfd
:debug:checksum Executing org.macports.checksum (nfd)
:info:checksum --->  Checksumming NFD-NFD-0.3.0.tar.gz
:debug:checksum Calculated (rmd160) is 1adfd25be1889ff0fa0073fcab1b9f6b82371ba0
:debug:checksum Correct (rmd160) checksum for NFD-NFD-0.3.0.tar.gz
:debug:checksum Calculated (sha256) is 695274851fa3b9c0b17cc2e16ff00259749bae35ef429c5a90400f93b3daf6a0
:debug:checksum Correct (sha256) checksum for NFD-NFD-0.3.0.tar.gz
:debug:checksum Privilege de-escalation not attempted as not running as root.
:debug:extract extract phase started at Wed Feb 18 09:57:12 PST 2015
:notice:extract --->  Extracting nfd
:debug:extract Executing org.macports.extract (nfd)
:info:extract --->  Extracting NFD-NFD-0.3.0.tar.gz
:debug:extract setting option extract.args to '/opt/local/var/macports/distfiles/nfd/NFD-NFD-0.3.0.tar.gz'
:debug:extract Environment: 
CC_PRINT_OPTIONS='YES'
CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/.CC_PRINT_OPTIONS'
CPATH='/opt/local/include'
LIBRARY_PATH='/opt/local/lib'
MACOSX_DEPLOYMENT_TARGET='10.9'
:debug:extract Assembled command: 'cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work" && /usr/bin/gzip -dc '/opt/local/var/macports/distfiles/nfd/NFD-NFD-0.3.0.tar.gz' | /usr/bin/tar -xf -'
:debug:extract Executing command line:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work" && /usr/bin/gzip -dc '/opt/local/var/macports/distfiles/nfd/NFD-NFD-0.3.0.tar.gz' | /usr/bin/tar -xf - 
:debug:extract Executing proc-post-org.macports.extract-extract-0
:debug:extract changing euid/egid - current euid: 0 - current egid: 0
:debug:extract egid changed to: 501
:debug:extract euid changed to: 501
:debug:patch patch phase started at Wed Feb 18 09:57:13 PST 2015
:debug:patch Executing org.macports.patch (nfd)
:debug:patch Privilege de-escalation not attempted as not running as root.
:debug:configure configure phase started at Wed Feb 18 09:57:13 PST 2015
:notice:configure --->  Configuring nfd
:debug:configure Using compiler 'Xcode Clang'
:debug:configure Executing proc-pre-org.macports.configure-configure-0
:info:configure   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
:info:configure                                  Dload  Upload   Total   Spent    Left  Speed
:info:configure 
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100   168    0   168    0     0    200      0 --:--:-- --:--:-- --:--:--   203
:info:configure 
100  174k    0  174k    0     0  96330      0 --:--:--  0:00:01 --:--:-- 96330
100  612k    0  612k    0     0   291k      0 --:--:--  0:00:02 --:--:-- 1740k
:debug:configure Executing org.macports.configure (nfd)
:debug:configure Environment: 
CC='/usr/bin/clang'
CC_PRINT_OPTIONS='YES'
CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/.CC_PRINT_OPTIONS'
CFLAGS='-pipe -Os -arch x86_64'
CPATH='/opt/local/include'
CPPFLAGS='-I/opt/local/include'
CXX='/usr/bin/clang++'
CXXFLAGS='-pipe -Os -std=c++11 -arch x86_64 -stdlib=libc++'
F77FLAGS='-m64'
F90FLAGS='-pipe -Os -m64'
FCFLAGS='-pipe -Os -m64'
FFLAGS='-pipe -Os'
INSTALL='/usr/bin/install -c'
LDFLAGS='-L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64'
LIBRARY_PATH='/opt/local/lib'
MACOSX_DEPLOYMENT_TARGET='10.9'
OBJC='/usr/bin/clang'
OBJCFLAGS='-pipe -Os -arch x86_64'
OBJCXX='/usr/bin/clang++'
OBJCXXFLAGS='-pipe -Os -arch x86_64 -stdlib=libc++'
SPHINX_BUILD='/opt/local/bin/sphinx-build-2.7'
:debug:configure Assembled command: 'cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/NFD-NFD-0.3.0" && ./waf configure --prefix=/opt/local'
:debug:configure Executing command line:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/NFD-NFD-0.3.0" && ./waf configure --prefix=/opt/local 
:info:configure Setting top to                           : /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/NFD-NFD-0.3.0 
:info:configure Setting out to                           : /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/NFD-NFD-0.3.0/build 
:info:configure Checking for 'clang++' (C++ compiler)    : /usr/bin/clang++ 
:info:configure Checking supported CXXFLAGS              : -std=c++11 -Wno-error=unneeded-internal-declaration -Wno-error=deprecated-register -stdlib=libc++ 
:info:configure Checking supported LINKFLAGS             : -stdlib=libc++ 
:info:configure Checking for program 'doxygen'           : /opt/local/bin/doxygen 
:info:configure Checking for program 'tar'               : /usr/bin/tar 
:info:configure Checking for program 'sphinx-build'      : /opt/local/bin/sphinx-build-2.7 
:info:configure Checking for std::is_default_constructible : yes 
:info:configure Checking for std::is_move_constructible    : yes 
:info:configure Checking for override specifier            : yes 
:info:configure Checking for program 'bash'                : /bin/bash 
:info:configure Checking for program 'pkg-config'          : /opt/local/bin/pkg-config 
:info:configure Checking for 'libndn-cxx'                  : yes 
:info:configure Checking for librt library                 : not found 
:info:configure Checking for libresolv library             : yes 
:info:configure Checking if privilege drop/elevation is supported : yes 
:info:configure Checking for header ifaddrs.h                     : yes 
:info:configure Checking boost includes                           : 1.57.0 
:info:configure Checking boost libs                               : ok 
:info:configure Checking for boost linkage                        : ok 
:info:configure Checking if Unix sockets are supported            : yes 
:info:configure Checking for WebSocket includes                   : 0.4.0 
:info:configure Checking if Ethernet face support can be enabled  : yes 
:info:configure Checking for libpcap library                      : yes 
:info:configure Checking for function pcap_set_immediate_mode     : yes 
:info:configure 'configure' finished successfully (7.736s)
:debug:configure Privilege de-escalation not attempted as not running as root.
:debug:build build phase started at Wed Feb 18 09:57:24 PST 2015
:notice:build --->  Building nfd
:debug:build Executing org.macports.build (nfd)
:debug:build Environment: 
CC_PRINT_OPTIONS='YES'
CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/.CC_PRINT_OPTIONS'
CPATH='/opt/local/include'
LIBRARY_PATH='/opt/local/lib'
MACOSX_DEPLOYMENT_TARGET='10.9'
:debug:build Assembled command: 'cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/NFD-NFD-0.3.0" && ./waf build'
:debug:build Executing command line:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/NFD-NFD-0.3.0" && ./waf build 
:info:build Waf: Entering directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/NFD-NFD-0.3.0/build'
:info:build fatal: Not a git repository (or any of the parent directories): .git
:info:build Extension 'sphinxcontrib.doxylink' in not available. Some documentation may not build correctly.
:info:build To install, use 
:info:build   sudo pip install sphinxcontrib-doxylink
:info:build [  1/115] Compiling version.hpp.in
:info:build [  2/115] Compiling common.hpp
:info:build [  3/115] Compiling tools/nfd-start.sh
:info:build [  4/115] Compiling tools/nfd-status-http-server.py
:info:build [  5/115] Compiling tools/nfd-stop.sh
:info:build [  6/115] Compiling nfd.conf.sample.in
:info:build [  7/115] Processing sphinx_build [man]: docs/manpages/ndn-autoconfig-server.rst docs/manpages/ndn-autoconfig.rst docs/manpages/ndn-tlv-peek.rst docs/manpages/ndn-tlv-poke.rst docs/manpages/nfd-autoreg.rst docs/manpages/nfd-status-http-server.rst docs/manpages/nfd-status.rst docs/manpages/nfd.rst docs/manpages/nfdc.rst docs/manpages/nrd.rst docs/conf.py -> build/docs/manpages/nfd.1 build/docs/manpages/nrd.1 build/docs/manpages/ndn-autoconfig-server.1 build/docs/manpages/ndn-autoconfig.1 build/docs/manpages/nfdc.1 build/docs/manpages/ndn-tlv-peek.1 build/docs/manpages/ndn-tlv-poke.1 build/docs/manpages/nfd-autoreg.1 build/docs/manpages/nfd-status-http-server.1 build/docs/manpages/nfd-status.1
:info:build 
:info:build Extension 'sphinxcontrib.doxylink' in not available. Some documentation may not build correctly.
:info:build To install, use 
:info:build   sudo pip install sphinxcontrib-doxylink
:info:build 
:info:build [  8/115] Compiling daemon/face/udp-face.cpp
:info:build [  9/115] Compiling daemon/table/measurements-accessor.cpp
:info:build [ 10/115] Compiling daemon/fw/face-table.cpp
:info:build [ 11/115] Compiling core/city-hash.cpp
:info:build [ 12/115] Compiling daemon/mgmt/strategy-choice-publisher.cpp
:info:build [ 13/115] Compiling core/logger-factory.cpp
:info:build [ 14/115] Compiling daemon/mgmt/manager-base.cpp
:info:build [ 15/115] Compiling daemon/mgmt/face-status-publisher.cpp
:info:build [ 16/115] Compiling tools/ndn-autoconfig/base-dns.cpp
:info:build [ 17/115] Compiling daemon/mgmt/tables-config-section.cpp
:info:build [ 18/115] Compiling tools/ndn-autoconfig/main.cpp
:info:build [ 19/115] Compiling daemon/face/websocket-channel.cpp
:info:build [ 20/115] Compiling daemon/fw/ncc-strategy.cpp
:info:build [ 21/115] Compiling core/logger.cpp
:info:build [ 22/115] Compiling rib/rib-manager.cpp
:info:build [ 23/115] Compiling daemon/face/ndnlp-sequence-generator.cpp
:info:build [ 24/115] Compiling daemon/fw/strategy.cpp
:info:build [ 25/115] Compiling daemon/mgmt/status-server.cpp
:info:build [ 26/115] Compiling daemon/mgmt/fib-manager.cpp
:info:build [ 27/115] Compiling daemon/face/face.cpp
:info:build [ 28/115] Compiling daemon/mgmt/command-validator.cpp
:info:build [ 29/115] Compiling core/network.cpp
:info:build [ 30/115] Compiling rib/main.cpp
:info:build [ 31/115] Compiling daemon/fw/best-route-strategy2.cpp
:info:build [ 32/115] Compiling rib/fib-update.cpp
:info:build [ 33/115] Compiling daemon/table/strategy-choice-entry.cpp
:info:build [ 34/115] Compiling daemon/table/pit-face-record.cpp
:info:build [ 35/115] Compiling tools/ndn-autoconfig/base.cpp
:info:build [ 36/115] Compiling tools/ndn-autoconfig/guess-from-identity-name.cpp
:info:build [ 37/115] Compiling daemon/face/websocket-factory.cpp
:info:build [ 38/115] Compiling daemon/face/tcp-face.cpp
:info:build [ 39/115] Compiling daemon/fw/client-control-strategy.cpp
:info:build [ 40/115] Compiling daemon/face/tcp-channel.cpp
:info:build [ 41/115] Compiling daemon/table/cs.cpp
:info:build [ 42/115] Compiling daemon/face/ethernet-face.cpp
:info:build [ 43/115] Compiling daemon/face/null-face.cpp
:info:build [ 44/115] Compiling daemon/fw/retransmission-suppression.cpp
:info:build [ 45/115] Compiling daemon/mgmt/internal-face.cpp
:info:build [ 46/115] Compiling daemon/table/name-tree-entry.cpp
:info:build [ 47/115] Compiling core/random.cpp
:info:build [ 48/115] Compiling daemon/mgmt/channel-status-publisher.cpp
:info:build [ 49/115] Compiling daemon/table/pit.cpp
:info:build [ 50/115] Compiling daemon/mgmt/fib-enumeration-publisher.cpp
:info:build [ 51/115] Compiling tools/nfdc.cpp
:info:build [ 52/115] Compiling rib/rib-status-publisher.cpp
:info:build [ 53/115] Compiling rib/rib.cpp
:info:build [ 54/115] Compiling rib/remote-registrator.cpp
:info:build [ 55/115] Compiling daemon/mgmt/strategy-choice-manager.cpp
:info:build [ 56/115] Compiling daemon/face/ethernet-factory.cpp
:info:build [ 57/115] Compiling core/network-interface.cpp
:info:build [ 58/115] Compiling daemon/fw/access-strategy.cpp
:info:build [ 59/115] Compiling daemon/table/pit-entry.cpp
:info:build [ 60/115] Compiling daemon/face/multicast-udp-face.cpp
:info:build [ 61/115] Compiling daemon/table/fib.cpp
:info:build [ 62/115] Compiling daemon/face/tcp-factory.cpp
:info:build [ 63/115] Compiling daemon/table/pit-out-record.cpp
:info:build [ 64/115] Compiling daemon/face/ndnlp-parse.cpp
:info:build [ 65/115] Compiling daemon/mgmt/face-query-status-publisher.cpp
:info:build [ 66/115] Compiling daemon/mgmt/general-config-section.cpp
:info:build [ 67/115] Compiling daemon/table/measurements-entry.cpp
:info:build [ 68/115] Compiling daemon/fw/best-route-strategy.cpp
:info:build [ 69/115] Compiling core/global-io.cpp
:info:build [ 70/115] Compiling daemon/table/dead-nonce-list.cpp
:info:build [ 71/115] Compiling daemon/main.cpp
:info:build [ 72/115] Compiling tools/nfd-autoreg.cpp
:info:build [ 73/115] Compiling daemon/mgmt/face-manager.cpp
:info:build [ 74/115] Compiling daemon/face/ndnlp-slicer.cpp
:info:build [ 75/115] Compiling core/config-file.cpp
:info:build [ 76/115] Compiling tools/ndn-autoconfig-server.cpp
:info:build [ 77/115] Compiling tools/ndn-tlv-peek.cpp
:info:build [ 78/115] Compiling daemon/face/unix-stream-channel.cpp
:info:build [ 79/115] Compiling rib/rib-entry.cpp
:info:build [ 80/115] Compiling core/privilege-helper.cpp
:info:build [ 81/115] Compiling daemon/table/cs-entry.cpp
:info:build [ 82/115] Compiling daemon/face/ndnlp-partial-message-store.cpp
:info:build [ 83/115] Compiling daemon/fw/rtt-estimator.cpp
:info:build [ 84/115] Compiling tools/ndn-autoconfig/guess-from-search-domains.cpp
:info:build [ 85/115] Compiling daemon/face/unix-stream-face.cpp
:info:build [ 86/115] Compiling tools/nfd-status.cpp
:info:build [ 87/115] Compiling daemon/table/fib-nexthop.cpp
:info:build [ 88/115] Compiling daemon/table/strategy-info-host.cpp
:info:build [ 89/115] Compiling daemon/table/strategy-choice.cpp
:info:build [ 90/115] Compiling daemon/face/udp-factory.cpp
:info:build [ 91/115] Compiling daemon/table/name-tree.cpp
:info:build [ 92/115] Compiling daemon/fw/broadcast-strategy.cpp
:info:build [ 93/115] Compiling daemon/table/measurements.cpp
:info:build [ 94/115] Compiling daemon/face/websocket-face.cpp
:info:build [ 95/115] Compiling core/scheduler.cpp
:info:build [ 96/115] Compiling daemon/face/udp-channel.cpp
:info:build [ 97/115] Compiling daemon/table/cs-skip-list-entry.cpp
:info:build [ 98/115] Compiling tools/ndn-tlv-poke.cpp
:info:build [ 99/115] Compiling daemon/fw/available-strategies.cpp
:info:build [100/115] Compiling daemon/face/unix-stream-factory.cpp
:info:build [101/115] Compiling daemon/table/cs-entry-impl.cpp
:info:build [102/115] Compiling daemon/face/channel.cpp
:info:build [103/115] Compiling daemon/fw/forwarder.cpp
:info:build [104/115] Compiling daemon/table/fib-entry.cpp
:info:build [105/115] Compiling tools/ndn-autoconfig/multicast-discovery.cpp
:info:build [106/115] Compiling daemon/table/pit-in-record.cpp
:info:build [107/115] Linking build/bin/nfd-status
:info:build [108/115] Linking build/bin/nfd-autoreg
:info:build [109/115] Linking build/bin/nrd
:info:build [110/115] Linking build/bin/ndn-autoconfig-server
:info:build [111/115] Linking build/bin/ndn-tlv-peek
:info:build [112/115] Linking build/bin/nfdc
:info:build [113/115] Linking build/bin/ndn-tlv-poke
:info:build [114/115] Linking build/bin/ndn-autoconfig
:info:build [115/115] Linking build/bin/nfd
:info:build Waf: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/NFD-NFD-0.3.0/build'
:info:build 'build' finished successfully (1m24.652s)
:debug:build Privilege de-escalation not attempted as not running as root.
:debug:destroot destroot phase started at Wed Feb 18 09:58:49 PST 2015
:notice:destroot --->  Staging nfd into destroot
:debug:destroot Can't run destroot under sudo without elevated privileges (due to mtree).
:debug:destroot Run destroot without sudo to avoid root privileges.
:debug:destroot Going to escalate privileges back to root.
:debug:destroot euid changed to: 0. egid changed to: 0.
:info:destroot ./usr missing (created)
:info:destroot . missing (directory not created: File exists)
:info:destroot ./Applications missing (created)
:info:destroot ./Developer missing (created)
:info:destroot ./Library missing (created)
:info:destroot ./bin missing (created)
:info:destroot ./etc missing (created)
:info:destroot ./include missing (created)
:info:destroot ./lib missing (created)
:info:destroot ./lib/pkgconfig missing (created)
:info:destroot ./libexec missing (created)
:info:destroot ./sbin missing (created)
:info:destroot ./share missing (created)
:info:destroot ./share/info missing (created)
:info:destroot ./share/man missing (created)
:info:destroot ./share/man/cat1 missing (created)
:info:destroot ./share/man/cat2 missing (created)
:info:destroot ./share/man/cat3 missing (created)
:info:destroot ./share/man/cat4 missing (created)
:info:destroot ./share/man/cat5 missing (created)
:info:destroot ./share/man/cat6 missing (created)
:info:destroot ./share/man/cat7 missing (created)
:info:destroot ./share/man/cat8 missing (created)
:info:destroot ./share/man/cat9 missing (created)
:info:destroot ./share/man/catl missing (created)
:info:destroot ./share/man/catn missing (created)
:info:destroot ./share/man/man1 missing (created)
:info:destroot ./share/man/man2 missing (created)
:info:destroot ./share/man/man3 missing (created)
:info:destroot ./share/man/man4 missing (created)
:info:destroot ./share/man/man5 missing (created)
:info:destroot ./share/man/man6 missing (created)
:info:destroot ./share/man/man7 missing (created)
:info:destroot ./share/man/man8 missing (created)
:info:destroot ./share/man/man9 missing (created)
:info:destroot ./share/man/manl missing (created)
:info:destroot ./share/man/mann missing (created)
:info:destroot ./share/nls missing (created)
:info:destroot ./share/nls/C missing (created)
:info:destroot ./share/nls/af_ZA.ISO8859-1 missing (created)
:info:destroot ./share/nls/af_ZA.ISO8859-15 missing (created)
:info:destroot ./share/nls/bg_BG.CP1251 missing (created)
:info:destroot ./share/nls/cs_CZ.ISO8859-2 missing (created)
:info:destroot ./share/nls/da_DK.ISO8859-1 missing (created)
:info:destroot ./share/nls/da_DK.ISO8859-15 missing (created)
:info:destroot ./share/nls/de_AT.ISO8859-1 missing (created)
:info:destroot ./share/nls/de_AT.ISO8859-15 missing (created)
:info:destroot ./share/nls/de_CH.ISO8859-1 missing (created)
:info:destroot ./share/nls/de_CH.ISO8859-15 missing (created)
:info:destroot ./share/nls/de_DE.ISO8859-1 missing (created)
:info:destroot ./share/nls/de_DE.ISO8859-15 missing (created)
:info:destroot ./share/nls/el_GR.ISO8859-7 missing (created)
:info:destroot ./share/nls/en_AU.ISO8859-1 missing (created)
:info:destroot ./share/nls/en_AU.ISO8859-15 missing (created)
:info:destroot ./share/nls/en_AU.US-ASCII missing (created)
:info:destroot ./share/nls/en_CA.ISO8859-1 missing (created)
:info:destroot ./share/nls/en_CA.ISO8859-15 missing (created)
:info:destroot ./share/nls/en_CA.US-ASCII missing (created)
:info:destroot ./share/nls/en_GB.ISO8859-1 missing (created)
:info:destroot ./share/nls/en_GB.ISO8859-15 missing (created)
:info:destroot ./share/nls/en_GB.US-ASCII missing (created)
:info:destroot ./share/nls/en_NZ.ISO8859-1 missing (created)
:info:destroot ./share/nls/en_NZ.ISO8859-15 missing (created)
:info:destroot ./share/nls/en_NZ.US-ASCII missing (created)
:info:destroot ./share/nls/en_US.ISO8859-1 missing (created)
:info:destroot ./share/nls/en_US.ISO8859-15 missing (created)
:info:destroot ./share/nls/es_ES.ISO8859-1 missing (created)
:info:destroot ./share/nls/es_ES.ISO8859-15 missing (created)
:info:destroot ./share/nls/et_EE.ISO8859-15 missing (created)
:info:destroot ./share/nls/fi_FI.ISO8859-1 missing (created)
:info:destroot ./share/nls/fi_FI.ISO8859-15 missing (created)
:info:destroot ./share/nls/fr_BE.ISO8859-1 missing (created)
:info:destroot ./share/nls/fr_BE.ISO8859-15 missing (created)
:info:destroot ./share/nls/fr_CA.ISO8859-1 missing (created)
:info:destroot ./share/nls/fr_CA.ISO8859-15 missing (created)
:info:destroot ./share/nls/fr_CH.ISO8859-1 missing (created)
:info:destroot ./share/nls/fr_CH.ISO8859-15 missing (created)
:info:destroot ./share/nls/fr_FR.ISO8859-1 missing (created)
:info:destroot ./share/nls/fr_FR.ISO8859-15 missing (created)
:info:destroot ./share/nls/hi_IN.ISCII-DEV missing (created)
:info:destroot ./share/nls/hr_HR.ISO8859-2 missing (created)
:info:destroot ./share/nls/hu_HU.ISO8859-2 missing (created)
:info:destroot ./share/nls/is_IS.ISO8859-1 missing (created)
:info:destroot ./share/nls/is_IS.ISO8859-15 missing (created)
:info:destroot ./share/nls/it_CH.ISO8859-1 missing (created)
:info:destroot ./share/nls/it_CH.ISO8859-15 missing (created)
:info:destroot ./share/nls/it_IT.ISO8859-1 missing (created)
:info:destroot ./share/nls/it_IT.ISO8859-15 missing (created)
:info:destroot ./share/nls/ja_JP.SJIS missing (created)
:info:destroot ./share/nls/ja_JP.eucJP missing (created)
:info:destroot ./share/nls/ko_KR.eucKR missing (created)
:info:destroot ./share/nls/la_LN.ISO8859-1 missing (created)
:info:destroot ./share/nls/la_LN.ISO8859-15 missing (created)
:info:destroot ./share/nls/la_LN.ISO8859-2 missing (created)
:info:destroot ./share/nls/la_LN.ISO8859-4 missing (created)
:info:destroot ./share/nls/la_LN.US-ASCII missing (created)
:info:destroot ./share/nls/lt_LT.ISO8859-4 missing (created)
:info:destroot ./share/nls/nl_BE.ISO8859-1 missing (created)
:info:destroot ./share/nls/nl_BE.ISO8859-15 missing (created)
:info:destroot ./share/nls/nl_NL.ISO8859-1 missing (created)
:info:destroot ./share/nls/nl_NL.ISO8859-15 missing (created)
:info:destroot ./share/nls/no_NO.ISO8859-1 missing (created)
:info:destroot ./share/nls/no_NO.ISO8859-15 missing (created)
:info:destroot ./share/nls/pl_PL.ISO8859-2 missing (created)
:info:destroot ./share/nls/pt_BR.ISO8859-1 missing (created)
:info:destroot ./share/nls/pt_PT.ISO8859-1 missing (created)
:info:destroot ./share/nls/pt_PT.ISO8859-15 missing (created)
:info:destroot ./share/nls/ro_RO.ISO8859-2 missing (created)
:info:destroot ./share/nls/ru_RU.CP866 missing (created)
:info:destroot ./share/nls/ru_RU.ISO8859-5 missing (created)
:info:destroot ./share/nls/ru_RU.KOI8-R missing (created)
:info:destroot ./share/nls/sk_SK.ISO8859-2 missing (created)
:info:destroot ./share/nls/sl_SI.ISO8859-2 missing (created)
:info:destroot ./share/nls/sv_SE.ISO8859-1 missing (created)
:info:destroot ./share/nls/sv_SE.ISO8859-15 missing (created)
:info:destroot ./share/nls/tr_TR.ISO8859-9 missing (created)
:info:destroot ./share/nls/uk_UA.ISO8859-5 missing (created)
:info:destroot ./share/nls/uk_UA.KOI8-U missing (created)
:info:destroot ./share/nls/zh_CN.eucCN missing (created)
:info:destroot ./share/nls/zh_TW.Big5 missing (created)
:info:destroot ./share/skel missing (created)
:info:destroot ./src missing (created)
:info:destroot ./var missing (created)
:info:destroot ./www missing (created)
:debug:destroot Executing org.macports.destroot (nfd)
:debug:destroot Environment: 
CC_PRINT_OPTIONS='YES'
CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/.CC_PRINT_OPTIONS'
CPATH='/opt/local/include'
LIBRARY_PATH='/opt/local/lib'
MACOSX_DEPLOYMENT_TARGET='10.9'
:debug:destroot Assembled command: 'cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/NFD-NFD-0.3.0" && ./waf install --destdir=/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot'
:debug:destroot Executing command line:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/NFD-NFD-0.3.0" && ./waf install --destdir=/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot 
:info:destroot Waf: Entering directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/NFD-NFD-0.3.0/build'
:info:destroot fatal: Not a git repository (or any of the parent directories): .git
:info:destroot Extension 'sphinxcontrib.doxylink' in not available. Some documentation may not build correctly.
:info:destroot To install, use 
:info:destroot   sudo pip install sphinxcontrib-doxylink
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/ndn/nfd-status.xsl (from tools/nfd-status-http-server-files/nfd-status.xsl)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/ndn/reset.css (from tools/nfd-status-http-server-files/reset.css)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/ndn/robots.txt (from tools/nfd-status-http-server-files/robots.txt)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/nrd (from build/bin/nrd)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/nfd (from build/bin/nfd)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/ndn-autoconfig-server (from build/bin/ndn-autoconfig-server)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/ndn/style.css (from tools/nfd-status-http-server-files/style.css)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/ndn/text.css (from tools/nfd-status-http-server-files/text.css)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/ndn-tlv-peek (from build/bin/ndn-tlv-peek)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/ndn-tlv-poke (from build/bin/ndn-tlv-poke)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/nfd-autoreg (from build/bin/nfd-autoreg)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/nfd-status (from build/bin/nfd-status)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/nfdc (from build/bin/nfdc)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/ndn-autoconfig (from build/bin/ndn-autoconfig)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/nfd-start (from build/bin/nfd-start)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/nfd-status-http-server (from build/bin/nfd-status-http-server)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/nfd-stop (from build/bin/nfd-stop)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/etc/ndn/nfd.conf.sample (from build/nfd.conf.sample)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/man//man1/nfd.1 (from build/docs/manpages/nfd.1)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/man//man1/nrd.1 (from build/docs/manpages/nrd.1)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/man//man1/ndn-autoconfig-server.1 (from build/docs/manpages/ndn-autoconfig-server.1)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/man//man1/ndn-autoconfig.1 (from build/docs/manpages/ndn-autoconfig.1)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/man//man1/nfdc.1 (from build/docs/manpages/nfdc.1)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/man//man1/ndn-tlv-peek.1 (from build/docs/manpages/ndn-tlv-peek.1)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/man//man1/ndn-tlv-poke.1 (from build/docs/manpages/ndn-tlv-poke.1)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/man//man1/nfd-autoreg.1 (from build/docs/manpages/nfd-autoreg.1)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/man//man1/nfd-status-http-server.1 (from build/docs/manpages/nfd-status-http-server.1)
:info:destroot + install /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/man//man1/nfd-status.1 (from build/docs/manpages/nfd-status.1)
:info:destroot Waf: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/NFD-NFD-0.3.0/build'
:info:destroot 'install' finished successfully (2.371s)
:debug:destroot Executing proc-post-org.macports.destroot-destroot-0
:info:destroot xinstall: mkdir /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/etc/LaunchDaemons
:info:destroot xinstall: mkdir /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/etc/LaunchDaemons/net.named-data.nfd
:info:destroot xinstall: /opt/local/var/macports/sources/macports.named-data.net/macports/net/nfd/files/net.named-data.nfd.plist -> /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/etc/LaunchDaemons/net.named-data.nfd//net.named-data.nfd.plist
:info:destroot xinstall: /opt/local/var/macports/sources/macports.named-data.net/macports/net/nfd/files/net.named-data.nrd.plist -> /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/etc/LaunchDaemons/net.named-data.nfd//net.named-data.nrd.plist
:info:destroot --->  Patching net.named-data.nfd.plist: s|/usr/local|/opt/local|g
:debug:destroot Executing reinplace: /usr/bin/sed s|/usr/local|/opt/local|g < /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/etc/LaunchDaemons/net.named-data.nfd/net.named-data.nfd.plist >@ file10 2>@stderr
:info:destroot --->  Patching net.named-data.nrd.plist: s|/usr/local|/opt/local|g
:debug:destroot Executing reinplace: /usr/bin/sed s|/usr/local|/opt/local|g < /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/etc/LaunchDaemons/net.named-data.nfd/net.named-data.nrd.plist >@ file10 2>@stderr
:info:destroot xinstall: /opt/local/var/macports/sources/macports.named-data.net/macports/net/nfd/files/nfd-start -> /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin//nfd-start
:info:destroot xinstall: /opt/local/var/macports/sources/macports.named-data.net/macports/net/nfd/files/nfd-stop -> /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin//nfd-stop
:debug:destroot Executing portdestroot::destroot_finish
:debug:destroot Fixing glibtool .la files in destroot for nfd
:info:destroot --->  Compressing man pages for nfd
:debug:destroot Scanning man1
:info:destroot man1/ndn-autoconfig-server.1:	   55.4% -- replaced with man1/ndn-autoconfig-server.1.gz
:info:destroot man1/ndn-autoconfig-server.1.gz: changing permissions from 00644 to 00444
:info:destroot man1/ndn-autoconfig.1:	   61.1% -- replaced with man1/ndn-autoconfig.1.gz
:info:destroot man1/ndn-autoconfig.1.gz: changing permissions from 00644 to 00444
:info:destroot man1/ndn-tlv-peek.1:	   57.7% -- replaced with man1/ndn-tlv-peek.1.gz
:info:destroot man1/ndn-tlv-peek.1.gz: changing permissions from 00644 to 00444
:info:destroot man1/ndn-tlv-poke.1:	   55.7% -- replaced with man1/ndn-tlv-poke.1.gz
:info:destroot man1/ndn-tlv-poke.1.gz: changing permissions from 00644 to 00444
:info:destroot man1/nfd-autoreg.1:	   60.5% -- replaced with man1/nfd-autoreg.1.gz
:info:destroot man1/nfd-autoreg.1.gz: changing permissions from 00644 to 00444
:info:destroot man1/nfd-status-http-server.1:	   59.6% -- replaced with man1/nfd-status-http-server.1.gz
:info:destroot man1/nfd-status-http-server.1.gz: changing permissions from 00644 to 00444
:info:destroot man1/nfd-status.1:	   66.0% -- replaced with man1/nfd-status.1.gz
:info:destroot man1/nfd-status.1.gz: changing permissions from 00644 to 00444
:info:destroot man1/nfd.1:	   57.5% -- replaced with man1/nfd.1.gz
:info:destroot man1/nfd.1.gz: changing permissions from 00644 to 00444
:info:destroot man1/nfdc.1:	   72.7% -- replaced with man1/nfdc.1.gz
:info:destroot man1/nfdc.1.gz: changing permissions from 00644 to 00444
:info:destroot man1/nrd.1:	   53.8% -- replaced with man1/nrd.1.gz
:info:destroot man1/nrd.1.gz: changing permissions from 00644 to 00444
:debug:destroot checking for mtree violations
:debug:destroot changing euid/egid - current euid: 0 - current egid: 0
:debug:destroot egid changed to: 501
:debug:destroot euid changed to: 501
:debug:install install phase started at Wed Feb 18 09:58:55 PST 2015
:notice:install --->  Installing nfd @0.3.0_0
:debug:install Can't run install on this port without elevated privileges. Escalating privileges back to root.
:debug:install euid changed to: 0. egid changed to: 0.
:debug:install Executing org.macports.install (nfd)
:debug:install Using /usr/bin/tar
:debug:install Using /usr/bin/bzip2
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/ndn-autoconfig
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/ndn-autoconfig-server
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/ndn-tlv-peek
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/ndn-tlv-poke
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/nfd
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/nfd-autoreg
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/nfd-start
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/nfd-status
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/nfd-status-http-server
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/nfd-stop
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/nfdc
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/bin/nrd
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/etc/LaunchDaemons/net.named-data.nfd/net.named-data.nfd.plist
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/etc/LaunchDaemons/net.named-data.nfd/net.named-data.nrd.plist
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/etc/ndn/nfd.conf.sample
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/man/man1/ndn-autoconfig-server.1.gz
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/man/man1/ndn-autoconfig.1.gz
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/man/man1/ndn-tlv-peek.1.gz
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/man/man1/ndn-tlv-poke.1.gz
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/man/man1/nfd-autoreg.1.gz
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/man/man1/nfd-status-http-server.1.gz
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/man/man1/nfd-status.1.gz
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/man/man1/nfd.1.gz
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/man/man1/nfdc.1.gz
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/man/man1/nrd.1.gz
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/ndn/nfd-status.xsl
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/ndn/reset.css
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/ndn/robots.txt
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/ndn/style.css
:debug:install checksum file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/opt/local/share/ndn/text.css
:debug:install Creating nfd-0.3.0_0.darwin_13.x86_64.tbz2
:debug:install Environment: 
CC_PRINT_OPTIONS='YES'
CC_PRINT_OPTIONS_FILE='/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/.CC_PRINT_OPTIONS'
CPATH='/opt/local/include'
LIBRARY_PATH='/opt/local/lib'
MACOSX_DEPLOYMENT_TARGET='10.9'
:debug:install Assembled command: 'cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot" && /usr/bin/tar -cvf - . | /usr/bin/bzip2 -c9 > /opt/local/var/macports/software/nfd/nfd-0.3.0_0.darwin_13.x86_64.tbz2'
:debug:install Executing command line:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot" && /usr/bin/tar -cvf - . | /usr/bin/bzip2 -c9 > /opt/local/var/macports/software/nfd/nfd-0.3.0_0.darwin_13.x86_64.tbz2 
:info:install a .
:info:install a ./+COMMENT
:info:install a ./+CONTENTS
:info:install a ./+DESC
:info:install a ./+PORTFILE
:info:install a ./+STATE
:info:install a ./opt
:info:install a ./opt/local
:info:install a ./opt/local/bin
:info:install a ./opt/local/etc
:info:install a ./opt/local/share
:info:install a ./opt/local/share/man
:info:install a ./opt/local/share/ndn
:info:install a ./opt/local/share/ndn/nfd-status.xsl
:info:install a ./opt/local/share/ndn/reset.css
:info:install a ./opt/local/share/ndn/robots.txt
:info:install a ./opt/local/share/ndn/style.css
:info:install a ./opt/local/share/ndn/text.css
:info:install a ./opt/local/share/man/man1
:info:install a ./opt/local/share/man/man1/ndn-autoconfig-server.1.gz
:info:install a ./opt/local/share/man/man1/ndn-autoconfig.1.gz
:info:install a ./opt/local/share/man/man1/ndn-tlv-peek.1.gz
:info:install a ./opt/local/share/man/man1/ndn-tlv-poke.1.gz
:info:install a ./opt/local/share/man/man1/nfd-autoreg.1.gz
:info:install a ./opt/local/share/man/man1/nfd-status-http-server.1.gz
:info:install a ./opt/local/share/man/man1/nfd-status.1.gz
:info:install a ./opt/local/share/man/man1/nfd.1.gz
:info:install a ./opt/local/share/man/man1/nfdc.1.gz
:info:install a ./opt/local/share/man/man1/nrd.1.gz
:info:install a ./opt/local/etc/LaunchDaemons
:info:install a ./opt/local/etc/ndn
:info:install a ./opt/local/etc/ndn/nfd.conf.sample
:info:install a ./opt/local/etc/LaunchDaemons/net.named-data.nfd
:info:install a ./opt/local/etc/LaunchDaemons/net.named-data.nfd/net.named-data.nfd.plist
:info:install a ./opt/local/etc/LaunchDaemons/net.named-data.nfd/net.named-data.nrd.plist
:info:install a ./opt/local/bin/ndn-autoconfig
:info:install a ./opt/local/bin/ndn-autoconfig-server
:info:install a ./opt/local/bin/ndn-tlv-peek
:info:install a ./opt/local/bin/ndn-tlv-poke
:info:install a ./opt/local/bin/nfd
:info:install a ./opt/local/bin/nfd-autoreg
:info:install a ./opt/local/bin/nfd-start
:info:install a ./opt/local/bin/nfd-status
:info:install a ./opt/local/bin/nfd-status-http-server
:info:install a ./opt/local/bin/nfd-stop
:info:install a ./opt/local/bin/nfdc
:info:install a ./opt/local/bin/nrd
:debug:install Archive nfd-0.3.0_0.darwin_13.x86_64.tbz2 packaged
:debug:install removing file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/+COMMENT
:debug:install removing file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/+CONTENTS
:debug:install removing file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/+DESC
:debug:install removing file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/+PORTFILE
:debug:install removing file: /opt/local/var/macports/build/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/work/destroot/+STATE
:debug:activate activate phase started at Wed Feb 18 09:59:04 PST 2015
:debug:activate Executing org.macports.activate (nfd)
:msg:activate --->  Activating nfd @0.3.0_0
:debug:activate Using /usr/bin/tar
:debug:activate Using /usr/bin/bzip2
:info:activate x ./
:info:activate x ./+COMMENT
:info:activate x ./+CONTENTS
:info:activate x ./+DESC
:info:activate x ./+PORTFILE
:info:activate x ./+STATE
:info:activate x ./opt/
:info:activate x ./opt/local/
:info:activate x ./opt/local/bin/
:info:activate x ./opt/local/etc/
:info:activate x ./opt/local/share/
:info:activate x ./opt/local/share/man/
:info:activate x ./opt/local/share/ndn/
:info:activate x ./opt/local/share/ndn/nfd-status.xsl
:info:activate x ./opt/local/share/ndn/reset.css
:info:activate x ./opt/local/share/ndn/robots.txt
:info:activate x ./opt/local/share/ndn/style.css
:info:activate x ./opt/local/share/ndn/text.css
:info:activate x ./opt/local/share/man/man1/
:info:activate x ./opt/local/share/man/man1/ndn-autoconfig-server.1.gz
:info:activate x ./opt/local/share/man/man1/ndn-autoconfig.1.gz
:info:activate x ./opt/local/share/man/man1/ndn-tlv-peek.1.gz
:info:activate x ./opt/local/share/man/man1/ndn-tlv-poke.1.gz
:info:activate x ./opt/local/share/man/man1/nfd-autoreg.1.gz
:info:activate x ./opt/local/share/man/man1/nfd-status-http-server.1.gz
:info:activate x ./opt/local/share/man/man1/nfd-status.1.gz
:info:activate x ./opt/local/share/man/man1/nfd.1.gz
:info:activate x ./opt/local/share/man/man1/nfdc.1.gz
:info:activate x ./opt/local/share/man/man1/nrd.1.gz
:info:activate x ./opt/local/etc/LaunchDaemons/
:info:activate x ./opt/local/etc/ndn/
:info:activate x ./opt/local/etc/ndn/nfd.conf.sample
:info:activate x ./opt/local/etc/LaunchDaemons/net.named-data.nfd/
:info:activate x ./opt/local/etc/LaunchDaemons/net.named-data.nfd/net.named-data.nfd.plist
:info:activate x ./opt/local/etc/LaunchDaemons/net.named-data.nfd/net.named-data.nrd.plist
:info:activate x ./opt/local/bin/ndn-autoconfig
:info:activate x ./opt/local/bin/ndn-autoconfig-server
:info:activate x ./opt/local/bin/ndn-tlv-peek
:info:activate x ./opt/local/bin/ndn-tlv-poke
:info:activate x ./opt/local/bin/nfd
:info:activate x ./opt/local/bin/nfd-autoreg
:info:activate x ./opt/local/bin/nfd-start
:info:activate x ./opt/local/bin/nfd-status
:info:activate x ./opt/local/bin/nfd-status-http-server
:info:activate x ./opt/local/bin/nfd-stop
:info:activate x ./opt/local/bin/nfdc
:info:activate x ./opt/local/bin/nrd
:debug:activate activating directory: /
:debug:activate activating directory: /opt
:debug:activate activating directory: /opt/local
:debug:activate activating directory: /opt/local/bin
:debug:activate activating file: /opt/local/bin/ndn-autoconfig
:debug:activate activating file: /opt/local/bin/ndn-autoconfig-server
:debug:activate activating file: /opt/local/bin/ndn-tlv-peek
:debug:activate activating file: /opt/local/bin/ndn-tlv-poke
:debug:activate activating file: /opt/local/bin/nfd
:debug:activate activating file: /opt/local/bin/nfd-autoreg
:debug:activate activating file: /opt/local/bin/nfd-start
:debug:activate activating file: /opt/local/bin/nfd-status
:debug:activate activating file: /opt/local/bin/nfd-status-http-server
:debug:activate activating file: /opt/local/bin/nfd-stop
:debug:activate activating file: /opt/local/bin/nfdc
:debug:activate activating file: /opt/local/bin/nrd
:debug:activate activating directory: /opt/local/etc
:debug:activate activating directory: /opt/local/etc/LaunchDaemons
:debug:activate activating directory: /opt/local/etc/LaunchDaemons/net.named-data.nfd
:debug:activate activating file: /opt/local/etc/LaunchDaemons/net.named-data.nfd/net.named-data.nfd.plist
:debug:activate activating file: /opt/local/etc/LaunchDaemons/net.named-data.nfd/net.named-data.nrd.plist
:debug:activate activating directory: /opt/local/etc/ndn
:debug:activate activating file: /opt/local/etc/ndn/nfd.conf.sample
:debug:activate activating directory: /opt/local/share
:debug:activate activating directory: /opt/local/share/man
:debug:activate activating directory: /opt/local/share/man/man1
:debug:activate activating file: /opt/local/share/man/man1/ndn-autoconfig-server.1.gz
:debug:activate activating file: /opt/local/share/man/man1/ndn-autoconfig.1.gz
:debug:activate activating file: /opt/local/share/man/man1/ndn-tlv-peek.1.gz
:debug:activate activating file: /opt/local/share/man/man1/ndn-tlv-poke.1.gz
:debug:activate activating file: /opt/local/share/man/man1/nfd-autoreg.1.gz
:debug:activate activating file: /opt/local/share/man/man1/nfd-status-http-server.1.gz
:debug:activate activating file: /opt/local/share/man/man1/nfd-status.1.gz
:debug:activate activating file: /opt/local/share/man/man1/nfd.1.gz
:debug:activate activating file: /opt/local/share/man/man1/nfdc.1.gz
:debug:activate activating file: /opt/local/share/man/man1/nrd.1.gz
:debug:activate activating directory: /opt/local/share/ndn
:debug:activate activating file: /opt/local/share/ndn/nfd-status.xsl
:debug:activate activating file: /opt/local/share/ndn/reset.css
:debug:activate activating file: /opt/local/share/ndn/robots.txt
:debug:activate activating file: /opt/local/share/ndn/style.css
:debug:activate activating file: /opt/local/share/ndn/text.css
:notice:activate 
:notice:activate 
:notice:activate To start NFD and ensure it is started when system boots:
:notice:activate 
:notice:activate     nfd-start
:notice:activate 
:notice:activate To stop NFD and disable auto-start when system boots:
:notice:activate 
:notice:activate     nfd-stop
:notice:activate 
:notice:activate NFD log files are located in /opt/local/var/log/ndn/
:notice:activate 
:notice:activate Configuration file is in /opt/local/var/etc/ndn/
:notice:activate 
:notice:activate 
:debug:activate Executing proc-post-org.macports.activate-activate-0
:info:activate Error: PK_Signer: key too short for this signature scheme
:info:activate Command failed: HOME=/opt/local/var/lib/ndn/nfd ndnsec-keygen /localhost/daemons/nfd |  HOME=/opt/local/var/lib/ndn/nfd ndnsec-install-cert -
:info:activate Exit code: 1
:error:activate org.macports.activate for port nfd returned: command execution failed
:debug:activate Error code: NONE
:debug:activate Backtrace: command execution failed
    while executing
"proc-post-org.macports.activate-activate-0 org.macports.activate"
    ("eval" body line 1)
    invoked from within
"eval $post $targetname"
:info:activate Warning: targets not executed for nfd: org.macports.activate
:notice:activate Please see the log file for port nfd for details:
    /opt/local/var/macports/logs/_opt_local_var_macports_sources_macports.named-data.net_macports_net_nfd/nfd/main.log

From klaus.schneider at uni-bamberg.de  Thu Feb 19 05:23:50 2015
From: klaus.schneider at uni-bamberg.de (Klaus Schneider)
Date: Thu, 19 Feb 2015 14:23:50 +0100
Subject: [Nfd-dev] NDN Link Layer (2.5) Retransmissions
Message-ID: <54E5E3E6.40706@uni-bamberg.de>

Hi everyone,

while reading a redmine discussion
(http://redmine.named-data.net/issues/1999) I found the idea to
introduce a NDN link layer (2.5) to perform retransmissions below the
strategy layer.

> Updated by Alex Afanasyev about 1 month ago
>
> As I remember, the way to address link problems was to introduce a
> limited recovery inside the link (2.5) layer. This layer will do
> retransmissions much more efficiently and quicker than usually coarse
> RTO estimation (the initial value is 1 second).

I find this concept very interesting. However, I didn't find much about 
this on the web.

Can you tell me the current state of these ideas?

Thanks a lot,
Klaus


-- 
Klaus Schneider

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


From bzhang at cs.ARIZONA.EDU  Thu Feb 19 06:13:15 2015
From: bzhang at cs.ARIZONA.EDU (Beichuan Zhang)
Date: Thu, 19 Feb 2015 07:13:15 -0700
Subject: [Nfd-dev] NDN Link Layer (2.5) Retransmissions
In-Reply-To: <54E5E3E6.40706@uni-bamberg.de>
References: <54E5E3E6.40706@uni-bamberg.de>
Message-ID: <FB688549-C87B-4AC7-841E-A9D96654CA88@cs.arizona.edu>


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

> Hi everyone,
> 
> while reading a redmine discussion
> (http://redmine.named-data.net/issues/1999) I found the idea to
> introduce a NDN link layer (2.5) to perform retransmissions below the
> strategy layer.
> 
>> Updated by Alex Afanasyev about 1 month ago
>> 
>> As I remember, the way to address link problems was to introduce a
>> limited recovery inside the link (2.5) layer. This layer will do
>> retransmissions much more efficiently and quicker than usually coarse
>> RTO estimation (the initial value is 1 second).
> 
> I find this concept very interesting. However, I didn't find much about this on the web.
> 
> Can you tell me the current state of these ideas?

There is a design and implementation in NFD for the 2.5 layer, but it currently doesn?t have the retransmission part. 
http://redmine.named-data.net/projects/nfd/wiki/NDNLP-TLV. We just started the redesign of this 2.5 layer including limited loss recovery. This may take a while to get fully designed and implemented in NFD.

Beichuan

> 
> Thanks a lot,
> Klaus
> 
> 
> -- 
> Klaus Schneider
> 
> Mail: klaus.schneider at uni-bamberg.de
> LinkedIn: https://www.linkedin.com/in/schneiderklaus
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev




From klaus.schneider at uni-bamberg.de  Thu Feb 19 12:55:50 2015
From: klaus.schneider at uni-bamberg.de (Klaus Schneider)
Date: Thu, 19 Feb 2015 21:55:50 +0100
Subject: [Nfd-dev] NDN Link Layer (2.5) Retransmissions
In-Reply-To: <FB688549-C87B-4AC7-841E-A9D96654CA88@cs.arizona.edu>
References: <54E5E3E6.40706@uni-bamberg.de>
	<FB688549-C87B-4AC7-841E-A9D96654CA88@cs.arizona.edu>
Message-ID: <54E64DD6.3040400@uni-bamberg.de>

Thank you. I read the NDNLP techreport and it answers my question.

I still wonder if it wouldn't be better to do retransmissions on the 
strategy layer to exploit multiple paths.

The link layer has basically two options when faced with packet loss 
(correct me if I'm wrong about anything of the following):

1. Request the packet again
2. Announce the packet loss to upper layers (after a timeout or a 
specified number of retries)

With multiple paths the strategy layer has more options:
1. Send the Interest on the same path again
2. Send the Interest on a different path
3. Send the Interest simultaneously on multiple paths (a sort of forward 
error correction)
4. Announce the packet loss to upper layers

A good example would be burst errors. Retransmissions on the link layer 
would probably create a longer delay than switching the path on the 
strategy layer. One might find other examples where using the 
performance information of the strategy layer might be beneficial.

I would like to hear your thoughts on this.

Best regards,
Klaus



Am 19.02.2015 um 15:13 schrieb Beichuan Zhang:
>
> On Feb 19, 2015, at 6:23 AM, Klaus Schneider <klaus.schneider at uni-bamberg.de> wrote:
>
>> Hi everyone,
>>
>> while reading a redmine discussion
>> (http://redmine.named-data.net/issues/1999) I found the idea to
>> introduce a NDN link layer (2.5) to perform retransmissions below the
>> strategy layer.
>>
>>> Updated by Alex Afanasyev about 1 month ago
>>>
>>> As I remember, the way to address link problems was to introduce a
>>> limited recovery inside the link (2.5) layer. This layer will do
>>> retransmissions much more efficiently and quicker than usually coarse
>>> RTO estimation (the initial value is 1 second).
>>
>> I find this concept very interesting. However, I didn't find much about this on the web.
>>
>> Can you tell me the current state of these ideas?
>
> There is a design and implementation in NFD for the 2.5 layer, but it currently doesn?t have the retransmission part.
> http://redmine.named-data.net/projects/nfd/wiki/NDNLP-TLV. We just started the redesign of this 2.5 layer including limited loss recovery. This may take a while to get fully designed and implemented in NFD.
>
> Beichuan
>
>>
>> Thanks a lot,
>> Klaus
>>
>>
>> --
>> Klaus Schneider
>>
>> Mail: klaus.schneider at uni-bamberg.de
>> LinkedIn: https://www.linkedin.com/in/schneiderklaus
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

-- 
Klaus Schneider

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


From shijunxiao at email.arizona.edu  Fri Feb 20 21:11:23 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Fri, 20 Feb 2015 22:11:23 -0700
Subject: [Nfd-dev] Signed Interest processing: alternate to stop-and-wait
In-Reply-To: <FEE72A0C-1183-4795-8AE4-C79739D10076@memphis.edu>
References: <CAOFH+OZyN8CWKM07DzRjS9R_=RtYZBWs5wdLzhLT_JtFn5TH7A@mail.gmail.com>
	<FEE72A0C-1183-4795-8AE4-C79739D10076@memphis.edu>
Message-ID: <CAOFH+OZgWXwSCqp2bigNWc0idKrmqk0Zb8Q0C0H3NhramJBERQ@mail.gmail.com>

Hi Lan

The replay attack scenario requires the attacker to have the ability to
block the transmission of an earlier command.

   1. An legit client sends command "1. set light to red".
   2. Attacker in the middle intercepts this command, and prevents it from
   being delivered to the light.
   3. The legit client sends command "2. set light to green".
   4. Attacker forwards this command to the light.
   5. Attacker sends the command intercepted in step 2 to the light.


Yours, Junxiao

On Tue, Feb 17, 2015 at 1:07 PM, Lan Wang (lanwang) <lanwang at memphis.edu>
wrote:
>
> A sliding window based validation procedure could be: a signed Interest is
> accepted if its timestamp is greater than (latestTimestamp - windowSize),
> and it hasn't been accepted previously.
>
> If you always check "it hasn't been accepted previously.", how can an
> attacker replay it (below)?
>
> The risk is: an attacker can intercept (and block the transmission of) an
> earlier command, and replay it later.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150220/7b85c819/attachment.html>

From shijunxiao at email.arizona.edu  Fri Feb 20 21:35:13 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Fri, 20 Feb 2015 22:35:13 -0700
Subject: [Nfd-dev] How to start a certificate chain from scratch
In-Reply-To: <014A7FB5-FEC7-4AFC-BE6E-FACC53E00A94@cs.ucla.edu>
References: <CAOFH+Oav+q_aOFSL4XP_tetigHNEzg+Mgmpvoy0kO0muxZakWQ@mail.gmail.com>
	<024D7A01-E5BB-4204-9DAD-72372C17992D@cs.ucla.edu>
	<CAOFH+OYmpvc4PqvFS1oSJpqTd+8j_Lav=9sRPznjUMymf0q4Lg@mail.gmail.com>
	<014A7FB5-FEC7-4AFC-BE6E-FACC53E00A94@cs.ucla.edu>
Message-ID: <CAOFH+OZ9jKckQtF=qZDkq5Sx=ZZK8vvfurEV2ep=JWKBxdF4rA@mail.gmail.com>

Dear folks

Thanks Yingdi for providing commands on how to generate certificates. These
worked well in one of my experiments.

The only missing piece is: publish root, site, user certificate in a
repository or ndns system.
Does anyone know how to publish a certificate with repo-ng and ndns? I want
to try both.

Yours, Junxiao

On Wed, Nov 19, 2014 at 12:49 PM, Yingdi Yu <yingdi at cs.ucla.edu> wrote:

> Hi Junxiao,
>
> On Nov 19, 2014, at 11:23 AM, Junxiao Shi <shijunxiao at email.arizona.edu>
> wrote:
>
> Hi Yingdi
>
> Suppose one wants to mirror the same trust model as testbed and ndncert
> website, how can he do that? What are the commands?
>
> I list the commands for the example below:
>
> >> Specifically, what are the commands to:
>
> >> generate a root certificate: /example/KEY/ksk-1/ID-CERT
>
> $ ndnsec-keygen /example | ndnsec-cert-install -
>
> >> generate a site certificate and sign it by root certificate:
> /example/KEY/site1/ksk-2/ID-CERT
>
> $ ndnsec-keygen /example/site1 > site1-cert.req
> $ ndnsec-certgen -N /example/site1 -s /example site1-cert.req |
> ndnsec-cert-install -
>
> >> generate a user certificate and sign it by site certificate:
> /example/site1/KEY/user1/ksk-3/ID-CERT
>
> $ ndnsec-keygen /example/site1/user1 > user1-cert.req
> $ ndnsec-certgen -N /example/site1/user1 -s /example/site1 user1-cert.req
> | ndnsec-cert-install -
>
> >> publish root, site, user certificate in a repository or ndns system
>
> This depends on the tools. I usually write a simple cert publishing tool
> or use PIB to publish certificates
>
> >> generate a data signing certificate and sign it by user certificate:
> /example/site1/user1/KEY/dsk-4/ID-CERT
>
> For now, the command line tool disables dsk generation, but we could
> enable that if necessary.
>
>
> Yingdi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150220/80f5f742/attachment.html>

From shijunxiao at email.arizona.edu  Fri Feb 20 21:59:36 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Fri, 20 Feb 2015 22:59:36 -0700
Subject: [Nfd-dev] review request: ContentStore recognizes
	CachingPolicy-NoCache
Message-ID: <CAOFH+ObunLaxszgPwjndfqQgHMc=a5NrMcdAy=0WPS+qeTAzsA@mail.gmail.com>

Dear folks

I need someone to review the code for recognizing CachingPolicy-NoCache in
ContentStore.

http://gerrit.named-data.net/1782

If you are willing to have a look at the patch, I'll appreciate that.
You don't have to be an expert in order to do a code review.

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

From mjs at cisco.com  Mon Feb 23 09:50:59 2015
From: mjs at cisco.com (Mark Stapp)
Date: Mon, 23 Feb 2015 12:50:59 -0500
Subject: [Nfd-dev] Signed Interest processing: alternate to stop-and-wait
In-Reply-To: <CAOFH+OZgWXwSCqp2bigNWc0idKrmqk0Zb8Q0C0H3NhramJBERQ@mail.gmail.com>
References: <CAOFH+OZyN8CWKM07DzRjS9R_=RtYZBWs5wdLzhLT_JtFn5TH7A@mail.gmail.com>	<FEE72A0C-1183-4795-8AE4-C79739D10076@memphis.edu>
	<CAOFH+OZgWXwSCqp2bigNWc0idKrmqk0Zb8Q0C0H3NhramJBERQ@mail.gmail.com>
Message-ID: <54EB6883.2010208@cisco.com>

I'm sorry - I'm not following how this can be a realistic problem. if 
you have an application that serializes its commands, then ... each 
command _must_ have some serial number associated with it, yes? that 
sort of _must_ be monotonic, so that a receiver can determine whether a 
gap has appeared. a timestamp is not a substitute for a monotonic 
counter, because the receiver cannot detect a gap immediately. if an 
incoming message introduces a gap, the application (or a parameter to 
the security library) needs to determine whether that message can be 
processed immediately, as if it were idempotent. otherwise, there will 
out-of-order processing if any messages are reordered. if "green" is 
message #3 and it arrives before the receiver has seen "red" (#2), then 
the receiver can't just apply #3, that would be just ... wrong.

-- Mark


On 2/21/15 12:11 AM, Junxiao Shi wrote:
> Hi Lan
>
> The replay attack scenario requires the attacker to have the ability to
> block the transmission of an earlier command.
>
>  1. An legit client sends command "1. set light to red".
>  2. Attacker in the middle intercepts this command, and prevents it from
>     being delivered to the light.
>  3. The legit client sends command "2. set light to green".
>  4. Attacker forwards this command to the light.
>  5. Attacker sends the command intercepted in step 2 to the light.
>
>
> Yours, Junxiao
>
> On Tue, Feb 17, 2015 at 1:07 PM, Lan Wang (lanwang) <lanwang at memphis.edu
> <mailto:lanwang at memphis.edu>> wrote:
>
>>     A sliding window based validation procedure could be: a signed
>>     Interest is accepted if its timestamp is greater than
>>     (latestTimestamp - windowSize), and it hasn't been accepted
>>     previously.
>     If you always check "it hasn't been accepted previously.", how can
>     an attacker replay it (below)?
>>     The risk is: an attacker can intercept (and block the transmission
>>     of) an earlier command, and replay it later.
>
>
>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>


From Marc.Mosko at parc.com  Mon Feb 23 09:54:46 2015
From: Marc.Mosko at parc.com (Marc.Mosko at parc.com)
Date: Mon, 23 Feb 2015 17:54:46 +0000
Subject: [Nfd-dev] Signed Interest processing: alternate to stop-and-wait
In-Reply-To: <54EB6883.2010208@cisco.com>
References: <CAOFH+OZyN8CWKM07DzRjS9R_=RtYZBWs5wdLzhLT_JtFn5TH7A@mail.gmail.com>
	<FEE72A0C-1183-4795-8AE4-C79739D10076@memphis.edu>
	<CAOFH+OZgWXwSCqp2bigNWc0idKrmqk0Zb8Q0C0H3NhramJBERQ@mail.gmail.com>
	<54EB6883.2010208@cisco.com>
Message-ID: <BE1F46C5-8C73-4A29-A055-099BD9F37F92@parc.com>

I think if a protocol needs serialized commands, it should have its own serial number and not confound protocols by using a field from a different area of concern.  For example, if you change signing algorithms that use a different mechanism, will that break your protocol?

I think the signing algorithm and verification should use its own mechanism.  Other protocols should not peek in to there for their properties. For example, some system might ditch the existing signature and put a new signature on there.  That should not change your protocol?s behavior.

Marc

On Feb 23, 2015, at 9:50 AM, Mark Stapp <mjs at cisco.com<mailto:mjs at cisco.com>> wrote:

it

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

From jburke at remap.ucla.edu  Mon Feb 23 10:15:00 2015
From: jburke at remap.ucla.edu (Burke, Jeff)
Date: Mon, 23 Feb 2015 18:15:00 +0000
Subject: [Nfd-dev] Signed Interest processing: alternate to stop-and-wait
In-Reply-To: <BE1F46C5-8C73-4A29-A055-099BD9F37F92@parc.com>
Message-ID: <D110AD02.1B9D6D%jburke@remap.ucla.edu>


As part of early lighting control work, we had already proposed an authenticated interest approach that includes sequence #, timestamp, and RTT estimator as state to avoid replay attacks:
http://named-data.net/publications/nomen13/<http://named-data.net/wp-content/uploads/nomen13.pdf>
(see p4).

(I am not sure why SignedInterest doesn't provide at least an optional sequence number....  Can the ndn-cxx/architecture folks comment on why this was removed from the design?)

Thanks,
Jeff

From: <Marc.Mosko at parc.com<mailto:Marc.Mosko at parc.com>>
Date: Mon, 23 Feb 2015 17:54:46 +0000
To: <mjs at cisco.com<mailto:mjs at cisco.com>>
Cc: <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: Re: [Nfd-dev] Signed Interest processing: alternate to stop-and-wait

I think if a protocol needs serialized commands, it should have its own serial number and not confound protocols by using a field from a different area of concern.  For example, if you change signing algorithms that use a different mechanism, will that break your protocol?

I think the signing algorithm and verification should use its own mechanism.  Other protocols should not peek in to there for their properties. For example, some system might ditch the existing signature and put a new signature on there.  That should not change your protocol?s behavior.

Marc

On Feb 23, 2015, at 9:50 AM, Mark Stapp <mjs at cisco.com<mailto:mjs at cisco.com>> wrote:

it

_______________________________________________ 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/20150223/4b985381/attachment.html>

From alexander.afanasyev at ucla.edu  Mon Feb 23 14:18:13 2015
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Mon, 23 Feb 2015 14:18:13 -0800
Subject: [Nfd-dev] About our packet format spec
Message-ID: <8F109137-622C-4B81-82C4-8678DC09C2B2@ucla.edu>

Hi,

The current definition of the format spec makes multiple references to the "old" format. These were relevant for version 0.1, but I think we no longer need to keep that conversation in the definition.

If there are no objections, I'm proposing to clean up spec, keeping only relevant packet spec definitions.

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

From alexander.afanasyev at ucla.edu  Mon Feb 23 15:07:04 2015
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Mon, 23 Feb 2015 15:07:04 -0800
Subject: [Nfd-dev] Signed Interest processing: alternate to stop-and-wait
In-Reply-To: <54EB6883.2010208@cisco.com>
References: <CAOFH+OZyN8CWKM07DzRjS9R_=RtYZBWs5wdLzhLT_JtFn5TH7A@mail.gmail.com>
	<FEE72A0C-1183-4795-8AE4-C79739D10076@memphis.edu>
	<CAOFH+OZgWXwSCqp2bigNWc0idKrmqk0Zb8Q0C0H3NhramJBERQ@mail.gmail.com>
	<54EB6883.2010208@cisco.com>
Message-ID: <538E6B55-D47B-4754-AD1C-D2AF5077AE9F@ucla.edu>


> On Feb 23, 2015, at 9:50 AM, Mark Stapp <mjs at cisco.com> wrote:
> 
> I'm sorry - I'm not following how this can be a realistic problem. if you have an application that serializes its commands, then ... each command _must_ have some serial number associated with it, yes? that sort of _must_ be monotonic, so that a receiver can determine whether a gap has appeared. a timestamp is not a substitute for a monotonic counter, because the receiver cannot detect a gap immediately. if an incoming message introduces a gap, the application (or a parameter to the security library) needs to determine whether that message can be processed immediately, as if it were idempotent. otherwise, there will out-of-order processing if any messages are reordered. if "green" is message #3 and it arrives before the receiver has seen "red" (#2), then the receiver can't just apply #3, that would be just ... wrong.

The use case for the signed interests wasn't to support arbitrary sequences of the commands.  It was rather to support a spurious commands that are send out from time to time, generated by a distributed set of commanders.  In this case, sequence number doesn't always make sense, as it can be unknown for the commander.

When multiple control actions need to be performed, use of (signed) interests is not, in my opinion, appropriate.  In this case, it make sense to send a control command that initiates fetching of a sequence of control commands, which, given they are explicitly requested by the control unit, can be properly ordered and executed in a proper order.  In this protocol, there is no need for any kind of timestamp, because commands are requested, not unsolicitedly received.


---
Alex

> -- Mark
> 
> 
> On 2/21/15 12:11 AM, Junxiao Shi wrote:
>> Hi Lan
>> 
>> The replay attack scenario requires the attacker to have the ability to
>> block the transmission of an earlier command.
>> 
>> 1. An legit client sends command "1. set light to red".
>> 2. Attacker in the middle intercepts this command, and prevents it from
>>    being delivered to the light.
>> 3. The legit client sends command "2. set light to green".
>> 4. Attacker forwards this command to the light.
>> 5. Attacker sends the command intercepted in step 2 to the light.
>> 
>> 
>> Yours, Junxiao
>> 
>> On Tue, Feb 17, 2015 at 1:07 PM, Lan Wang (lanwang) <lanwang at memphis.edu
>> <mailto:lanwang at memphis.edu>> wrote:
>> 
>>>    A sliding window based validation procedure could be: a signed
>>>    Interest is accepted if its timestamp is greater than
>>>    (latestTimestamp - windowSize), and it hasn't been accepted
>>>    previously.
>>    If you always check "it hasn't been accepted previously.", how can
>>    an attacker replay it (below)?
>>>    The risk is: an attacker can intercept (and block the transmission
>>>    of) an earlier command, and replay it later.
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>> 
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

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

From shijunxiao at email.ARIZONA.EDU  Mon Feb 23 21:42:18 2015
From: shijunxiao at email.ARIZONA.EDU (Junxiao Shi)
Date: Mon, 23 Feb 2015 22:42:18 -0700
Subject: [Nfd-dev] About our packet format spec
In-Reply-To: <8F109137-622C-4B81-82C4-8678DC09C2B2@ucla.edu>
References: <8F109137-622C-4B81-82C4-8678DC09C2B2@ucla.edu>
Message-ID: <CAOFH+ObNtj+9c+y=ngVb+wCDgcgeGWTD7NW20QTTr-=DNj3SFQ@mail.gmail.com>

Dear folks

I suggest moving "comparison to CCNx 0.7 format" to a separate document,
and publish that as a technical report.
NDN-TLV spec itself doesn't need this comparison.

Yours, Junxiao

On Mon, Feb 23, 2015 at 3:18 PM, Alex Afanasyev <
alexander.afanasyev at ucla.edu> wrote:

> Hi,
>
> The current definition of the format spec makes multiple references to the
> "old" format. These were relevant for version 0.1, but I think we no longer
> need to keep that conversation in the definition.
>
> If there are no objections, I'm proposing to clean up spec, keeping only
> relevant packet spec definitions.
>
> ---
> Alex
>
> _______________________________________________
> 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/20150223/385a8186/attachment.html>

From shijunxiao at email.arizona.edu  Mon Feb 23 21:46:41 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Mon, 23 Feb 2015 22:46:41 -0700
Subject: [Nfd-dev] How to start a certificate chain from scratch
In-Reply-To: <014A7FB5-FEC7-4AFC-BE6E-FACC53E00A94@cs.ucla.edu>
References: <CAOFH+Oav+q_aOFSL4XP_tetigHNEzg+Mgmpvoy0kO0muxZakWQ@mail.gmail.com>
	<024D7A01-E5BB-4204-9DAD-72372C17992D@cs.ucla.edu>
	<CAOFH+OYmpvc4PqvFS1oSJpqTd+8j_Lav=9sRPznjUMymf0q4Lg@mail.gmail.com>
	<014A7FB5-FEC7-4AFC-BE6E-FACC53E00A94@cs.ucla.edu>
Message-ID: <CAOFH+Oa1zDDhf+hEoDe_T0A4Skk2tQwFPNASsT-pPbC6wMyXUg@mail.gmail.com>

Dear folks

The only missing piece is: publish root, site, user certificate in a
repository or ndns system.
Does anyone know how to publish a certificate with repo-ng and ndns? I want
to try both.

Yours, Junxiao

On Wed, Nov 19, 2014 at 12:49 PM, Yingdi Yu <yingdi at cs.ucla.edu> wrote:

> Hi Junxiao,
>
> On Nov 19, 2014, at 11:23 AM, Junxiao Shi <shijunxiao at email.arizona.edu>
> wrote:
>
> Hi Yingdi
>
> Suppose one wants to mirror the same trust model as testbed and ndncert
> website, how can he do that? What are the commands?
>
> I list the commands for the example below:
>
> >> Specifically, what are the commands to:
>
> >> generate a root certificate: /example/KEY/ksk-1/ID-CERT
>
> $ ndnsec-keygen /example | ndnsec-cert-install -
>
> >> generate a site certificate and sign it by root certificate:
> /example/KEY/site1/ksk-2/ID-CERT
>
> $ ndnsec-keygen /example/site1 > site1-cert.req
> $ ndnsec-certgen -N /example/site1 -s /example site1-cert.req |
> ndnsec-cert-install -
>
> >> generate a user certificate and sign it by site certificate:
> /example/site1/KEY/user1/ksk-3/ID-CERT
>
> $ ndnsec-keygen /example/site1/user1 > user1-cert.req
> $ ndnsec-certgen -N /example/site1/user1 -s /example/site1 user1-cert.req
> | ndnsec-cert-install -
>
> >> publish root, site, user certificate in a repository or ndns system
>
> This depends on the tools. I usually write a simple cert publishing tool
> or use PIB to publish certificates
>
> >> generate a data signing certificate and sign it by user certificate:
> /example/site1/user1/KEY/dsk-4/ID-CERT
>
> For now, the command line tool disables dsk generation, but we could
> enable that if necessary.
>
>
> Yingdi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150223/473595fe/attachment.html>

From mjs at cisco.com  Tue Feb 24 05:40:13 2015
From: mjs at cisco.com (Mark Stapp)
Date: Tue, 24 Feb 2015 08:40:13 -0500
Subject: [Nfd-dev] Signed Interest processing: alternate to stop-and-wait
In-Reply-To: <538E6B55-D47B-4754-AD1C-D2AF5077AE9F@ucla.edu>
References: <CAOFH+OZyN8CWKM07DzRjS9R_=RtYZBWs5wdLzhLT_JtFn5TH7A@mail.gmail.com>
	<FEE72A0C-1183-4795-8AE4-C79739D10076@memphis.edu>
	<CAOFH+OZgWXwSCqp2bigNWc0idKrmqk0Zb8Q0C0H3NhramJBERQ@mail.gmail.com>
	<54EB6883.2010208@cisco.com>
	<538E6B55-D47B-4754-AD1C-D2AF5077AE9F@ucla.edu>
Message-ID: <54EC7F3D.5030703@cisco.com>

just to be clear - I was responding to the thread where use of a 
timestamp was being discussed. as you know, I'm all for Interests that 
actuate, and I'm all for high-functioning, application-friendly protocols.

-- Mark

On 2/23/15 6:07 PM, Alex Afanasyev wrote:
>
>> On Feb 23, 2015, at 9:50 AM, Mark Stapp <mjs at cisco.com> wrote:
>>
>> I'm sorry - I'm not following how this can be a realistic problem. if you have an application that serializes its commands, then ... each command _must_ have some serial number associated with it, yes? that sort of _must_ be monotonic, so that a receiver can determine whether a gap has appeared. a timestamp is not a substitute for a monotonic counter, because the receiver cannot detect a gap immediately. if an incoming message introduces a gap, the application (or a parameter to the security library) needs to determine whether that message can be processed immediately, as if it were idempotent. otherwise, there will out-of-order processing if any messages are reordered. if "green" is message #3 and it arrives before the receiver has seen "red" (#2), then the receiver can't just apply #3, that would be just ... wrong.
>
> The use case for the signed interests wasn't to support arbitrary sequences of the commands.  It was rather to support a spurious commands that are send out from time to time, generated by a distributed set of commanders.  In this case, sequence number doesn't always make sense, as it can be unknown for the commander.
>
> When multiple control actions need to be performed, use of (signed) interests is not, in my opinion, appropriate.  In this case, it make sense to send a control command that initiates fetching of a sequence of control commands, which, given they are explicitly requested by the control unit, can be properly ordered and executed in a proper order.  In this protocol, there is no need for any kind of timestamp, because commands are requested, not unsolicitedly received.
>
>
> ---
> Alex
>
>> -- Mark
>>
>>
>> On 2/21/15 12:11 AM, Junxiao Shi wrote:
>>> Hi Lan
>>>
>>> The replay attack scenario requires the attacker to have the ability to
>>> block the transmission of an earlier command.
>>>
>>> 1. An legit client sends command "1. set light to red".
>>> 2. Attacker in the middle intercepts this command, and prevents it from
>>>     being delivered to the light.
>>> 3. The legit client sends command "2. set light to green".
>>> 4. Attacker forwards this command to the light.
>>> 5. Attacker sends the command intercepted in step 2 to the light.
>>>
>>>
>>> Yours, Junxiao
>>>
>>> On Tue, Feb 17, 2015 at 1:07 PM, Lan Wang (lanwang) <lanwang at memphis.edu
>>> <mailto:lanwang at memphis.edu>> wrote:
>>>
>>>>     A sliding window based validation procedure could be: a signed
>>>>     Interest is accepted if its timestamp is greater than
>>>>     (latestTimestamp - windowSize), and it hasn't been accepted
>>>>     previously.
>>>     If you always check "it hasn't been accepted previously.", how can
>>>     an attacker replay it (below)?
>>>>     The risk is: an attacker can intercept (and block the transmission
>>>>     of) an earlier command, and replay it later.
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Nfd-dev mailing list
>>> Nfd-dev at lists.cs.ucla.edu
>>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>>>
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>


From yingdi at CS.UCLA.EDU  Tue Feb 24 09:07:07 2015
From: yingdi at CS.UCLA.EDU (Yingdi Yu)
Date: Tue, 24 Feb 2015 09:07:07 -0800
Subject: [Nfd-dev] Signed Interest processing: alternate to stop-and-wait
In-Reply-To: <D110AD02.1B9D6D%jburke@remap.ucla.edu>
References: <D110AD02.1B9D6D%jburke@remap.ucla.edu>
Message-ID: <E53D2961-7523-4C32-9C12-3C962AF61F0E@cs.ucla.edu>


> On Feb 23, 2015, at 10:15 AM, Burke, Jeff <jburke at remap.ucla.edu> wrote:
> 
> 
> As part of early lighting control work, we had already proposed an authenticated interest approach that includes sequence #, timestamp, and RTT estimator as state to avoid replay attacks:
> http://named-data.net/publications/nomen13/ <http://named-data.net/wp-content/uploads/nomen13.pdf>
> (see p4).
> 
> (I am not sure why SignedInterest doesn't provide at least an optional sequence number....  Can the ndn-cxx/architecture folks comment on why this was removed from the design?)

I think, ideally, signed interest should be just ?signed? interest, that is, it does not add any semantics other than signature info and signature value. The sequencing, timestamp, and nonce are not related to signature, they are attributes of command. In an early version of ndn-cxx, there was a command interest which is a signed interest but with more information about timestamp and nonce. And at time, the command interest is designed for local NFD control where interests are rarely out-of-order, so sequencing is not added into the command interest. The original idea is that one can always develop a helper for a specific command interest based on signed interest by introducing any necessary command attribute. But why command interest is later merged into signed interest is another story?

Yingdi

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

From jburke at remap.UCLA.EDU  Tue Feb 24 23:10:34 2015
From: jburke at remap.UCLA.EDU (Burke, Jeff)
Date: Wed, 25 Feb 2015 07:10:34 +0000
Subject: [Nfd-dev] Signed Interest processing: alternate to stop-and-wait
In-Reply-To: <E53D2961-7523-4C32-9C12-3C962AF61F0E@cs.ucla.edu>
Message-ID: <D112B530.1BA164%jburke@remap.ucla.edu>




On Feb 23, 2015, at 10:15 AM, Burke, Jeff <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>> wrote:


As part of early lighting control work, we had already proposed an authenticated interest approach that includes sequence #, timestamp, and RTT estimator as state to avoid replay attacks:
http://named-data.net/publications/nomen13/<http://named-data.net/wp-content/uploads/nomen13.pdf>
(see p4).

(I am not sure why SignedInterest doesn't provide at least an optional sequence number....  Can the ndn-cxx/architecture folks comment on why this was removed from the design?)

I think, ideally, signed interest should be just ?signed? interest, that is, it does not add any semantics other than signature info and signature value. The sequencing, timestamp, and nonce are not related to signature, they are attributes of command. In an early version of ndn-cxx, there was a command interest which is a signed interest but with more information about timestamp and nonce. And at time, the command interest is designed for local NFD control where interests are rarely out-of-order, so sequencing is not added into the command interest. The original idea is that one can always develop a helper for a specific command interest based on signed interest by introducing any necessary command attribute. But why command interest is later merged into signed interest is another story?


This explanation helps...  You might consider incorporating this into the documentation ? it is presented more generally here, for example: http://redmine.named-data.net/projects/nfd/wiki/Command_Interests

Jeff


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

From jburke at remap.UCLA.EDU  Wed Feb 25 18:41:28 2015
From: jburke at remap.UCLA.EDU (Burke, Jeff)
Date: Thu, 26 Feb 2015 02:41:28 +0000
Subject: [Nfd-dev] About our packet format spec
In-Reply-To: <CAOFH+ObNtj+9c+y=ngVb+wCDgcgeGWTD7NW20QTTr-=DNj3SFQ@mail.gmail.com>
Message-ID: <D113C7CD.1BA66E%jburke@remap.ucla.edu>

+1 to both

From: Junxiao Shi <shijunxiao at email.ARIZONA.EDU<mailto:shijunxiao at email.ARIZONA.EDU>>
Date: Mon, 23 Feb 2015 22:42:18 -0700
To: Alex Afanasyev <alexander.afanasyev at ucla.edu<mailto:alexander.afanasyev at ucla.edu>>
Cc: "<nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>" <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: Re: [Nfd-dev] About our packet format spec

Dear folks

I suggest moving "comparison to CCNx 0.7 format" to a separate document, and publish that as a technical report.
NDN-TLV spec itself doesn't need this comparison.

Yours, Junxiao

On Mon, Feb 23, 2015 at 3:18 PM, Alex Afanasyev <alexander.afanasyev at ucla.edu<mailto:alexander.afanasyev at ucla.edu>> wrote:
Hi,

The current definition of the format spec makes multiple references to the "old" format. These were relevant for version 0.1, but I think we no longer need to keep that conversation in the definition.

If there are no objections, I'm proposing to clean up spec, keeping only relevant packet spec definitions.

---
Alex

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


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

From chengy.fan at gmail.com  Thu Feb 26 15:05:34 2015
From: chengy.fan at gmail.com (Chengyu Fan)
Date: Thu, 26 Feb 2015 16:05:34 -0700
Subject: [Nfd-dev] How to start a certificate chain from scratch
In-Reply-To: <CAOFH+Oa1zDDhf+hEoDe_T0A4Skk2tQwFPNASsT-pPbC6wMyXUg@mail.gmail.com>
References: <CAOFH+Oav+q_aOFSL4XP_tetigHNEzg+Mgmpvoy0kO0muxZakWQ@mail.gmail.com>
	<024D7A01-E5BB-4204-9DAD-72372C17992D@cs.ucla.edu>
	<CAOFH+OYmpvc4PqvFS1oSJpqTd+8j_Lav=9sRPznjUMymf0q4Lg@mail.gmail.com>
	<014A7FB5-FEC7-4AFC-BE6E-FACC53E00A94@cs.ucla.edu>
	<CAOFH+Oa1zDDhf+hEoDe_T0A4Skk2tQwFPNASsT-pPbC6wMyXUg@mail.gmail.com>
Message-ID: <CAFaqyJVByJqNNDMD=qE6bkcC5BuPx+sL9UZEi6NZ_-=UkoMtvw@mail.gmail.com>

Hi Junxiao,

Is this problem solved?
I have the same issue now.

On Mon, Feb 23, 2015 at 10:46 PM, Junxiao Shi <shijunxiao at email.arizona.edu>
wrote:

> Dear folks
>
> The only missing piece is: publish root, site, user certificate in a
> repository or ndns system.
> Does anyone know how to publish a certificate with repo-ng and ndns? I
> want to try both.
>
> Yours, Junxiao
>
> On Wed, Nov 19, 2014 at 12:49 PM, Yingdi Yu <yingdi at cs.ucla.edu> wrote:
>
>> Hi Junxiao,
>>
>> On Nov 19, 2014, at 11:23 AM, Junxiao Shi <shijunxiao at email.arizona.edu>
>> wrote:
>>
>> Hi Yingdi
>>
>> Suppose one wants to mirror the same trust model as testbed and ndncert
>> website, how can he do that? What are the commands?
>>
>> I list the commands for the example below:
>>
>> >> Specifically, what are the commands to:
>>
>> >> generate a root certificate: /example/KEY/ksk-1/ID-CERT
>>
>> $ ndnsec-keygen /example | ndnsec-cert-install -
>>
>> >> generate a site certificate and sign it by root certificate:
>> /example/KEY/site1/ksk-2/ID-CERT
>>
>> $ ndnsec-keygen /example/site1 > site1-cert.req
>> $ ndnsec-certgen -N /example/site1 -s /example site1-cert.req |
>> ndnsec-cert-install -
>>
>> >> generate a user certificate and sign it by site certificate:
>> /example/site1/KEY/user1/ksk-3/ID-CERT
>>
>> $ ndnsec-keygen /example/site1/user1 > user1-cert.req
>> $ ndnsec-certgen -N /example/site1/user1 -s /example/site1 user1-cert.req
>> | ndnsec-cert-install -
>>
>> >> publish root, site, user certificate in a repository or ndns system
>>
>> This depends on the tools. I usually write a simple cert publishing tool
>> or use PIB to publish certificates
>>
>> >> generate a data signing certificate and sign it by user certificate:
>> /example/site1/user1/KEY/dsk-4/ID-CERT
>>
>> For now, the command line tool disables dsk generation, but we could
>> enable that if necessary.
>>
>>
>> Yingdi
>>
>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>


-- 
Thanks,

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

From jburke at remap.UCLA.EDU  Thu Feb 26 22:37:38 2015
From: jburke at remap.UCLA.EDU (Burke, Jeff)
Date: Fri, 27 Feb 2015 06:37:38 +0000
Subject: [Nfd-dev] Examples of setting up NFD networks
Message-ID: <D11550A9.1BB364%jburke@remap.ucla.edu>


Hi folks,

I am curious where the best place to look is for (or where one could eventually contribute some) examples of actually settings up networks with NFD, even just simple ones using static routes.    There is a brief mention of nfdc in the install.html but I am looking for a little more of a guidebook for an operator that briefly introduces all of the tools, explains how to set up a small multi-node network and test connectivity, maybe even introduces strategy.  Does such a thing exist?

Thanks,

Jeff


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

From jdd at wustl.edu  Fri Feb 27 07:20:19 2015
From: jdd at wustl.edu (Dehart, John)
Date: Fri, 27 Feb 2015 15:20:19 +0000
Subject: [Nfd-dev] Examples of setting up NFD networks
In-Reply-To: <D11550A9.1BB364%jburke@remap.ucla.edu>
References: <D11550A9.1BB364%jburke@remap.ucla.edu>
Message-ID: <ABE8BFD5-00D3-4E7E-B0B5-EFBF39A20C63@wustl.edu>


Jeff,

I have two repos that I use.

This is where I keep all the configuration scripts and files for the NDN Testbed:

https://github.com/WU-ARL/ndn-ops

This is a performance test for nfd that we developed on ONL:

https://github.com/WU-ARL/NFD_Performance_Testing_on_ONL

Neither of them is tutorial in nature. An experienced NDN/nfd user could probably take them and make sense
of them but a new user starting from scratch might be lost.

I know Chengyu and Junxiao have each used the performance test repo.

We are also in the process of developing a topology for ONL that closely matches the
topology of the NDN Testbed and uses VMs for end hosts so we can do tests of demonstrations.

John


On Feb 27, 2015, at 12:37 AM, Burke, Jeff <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>> wrote:


Hi folks,

I am curious where the best place to look is for (or where one could eventually contribute some) examples of actually settings up networks with NFD, even just simple ones using static routes.    There is a brief mention of nfdc in the install.html but I am looking for a little more of a guidebook for an operator that briefly introduces all of the tools, explains how to set up a small multi-node network and test connectivity, maybe even introduces strategy.  Does such a thing exist?

Thanks,

Jeff


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

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

From shijunxiao at email.arizona.edu  Fri Feb 27 07:24:49 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Fri, 27 Feb 2015 08:24:49 -0700
Subject: [Nfd-dev] Examples of setting up NFD networks
In-Reply-To: <D11550A9.1BB364%jburke@remap.ucla.edu>
References: <D11550A9.1BB364%jburke@remap.ucla.edu>
Message-ID: <CAOFH+OZOsHYnCo7jgV8_4rMGKqHH5Gb5wVtYjJPOD0XoK9frAw@mail.gmail.com>

Hi Jeff

yoursunny.com published a blog post last year about how to create a
two-node network and complete a ping:
http://yoursunny.com/t/2014/nfd-connect/

Yours, Junxiao
On Feb 26, 2015 11:37 PM, "Burke, Jeff" <jburke at remap.ucla.edu> wrote:

>
>  Hi folks,
>
>  I am curious where the best place to look is for (or where one could
> eventually contribute some) examples of actually settings up networks with
> NFD, even just simple ones using static routes.    There is a brief mention
> of nfdc in the install.html but I am looking for a little more of a
> guidebook for an operator that briefly introduces all of the tools,
> explains how to set up a small multi-node network and test connectivity,
> maybe even introduces strategy.  Does such a thing exist?
>
>  Thanks,
>
>  Jeff
>
>
>
> _______________________________________________
> 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/20150227/a7c02618/attachment.html>

From jdd at wustl.edu  Fri Feb 27 08:54:17 2015
From: jdd at wustl.edu (Dehart, John)
Date: Fri, 27 Feb 2015 16:54:17 +0000
Subject: [Nfd-dev] Examples of setting up NFD networks
In-Reply-To: <D11550A9.1BB364%jburke@remap.ucla.edu>
References: <D11550A9.1BB364%jburke@remap.ucla.edu>
Message-ID: <72E81791-D1F7-4734-B0B3-1E8D295ECF68@wustl.edu>


Jeff,

Would it make sense to put together something on the NDN Wiki?

https://ndnpub.caida.org/bin/view/NDN/WebHome

I just went through some of the pages there and there is a lot that is out of date.

John

On Feb 27, 2015, at 12:37 AM, Burke, Jeff <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>> wrote:


Hi folks,

I am curious where the best place to look is for (or where one could eventually contribute some) examples of actually settings up networks with NFD, even just simple ones using static routes.    There is a brief mention of nfdc in the install.html but I am looking for a little more of a guidebook for an operator that briefly introduces all of the tools, explains how to set up a small multi-node network and test connectivity, maybe even introduces strategy.  Does such a thing exist?

Thanks,

Jeff


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

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

From jburke at remap.UCLA.EDU  Fri Feb 27 08:57:45 2015
From: jburke at remap.UCLA.EDU (Burke, Jeff)
Date: Fri, 27 Feb 2015 16:57:45 +0000
Subject: [Nfd-dev] Examples of setting up NFD networks
In-Reply-To: <72E81791-D1F7-4734-B0B3-1E8D295ECF68@wustl.edu>
Message-ID: <D115E1E5.1BBD6E%jburke@remap.ucla.edu>

John,
I was thinking of public resources, so perhaps on the NFD wiki?
Jeff

From: "Dehart, John" <jdd at wustl.edu<mailto:jdd at wustl.edu>>
Date: Fri, 27 Feb 2015 16:54:17 +0000
To: Jeff Burke <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>>
Cc: "nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>" <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: Re: [Nfd-dev] Examples of setting up NFD networks


Jeff,

Would it make sense to put together something on the NDN Wiki?

https://ndnpub.caida.org/bin/view/NDN/WebHome

I just went through some of the pages there and there is a lot that is out of date.

John

On Feb 27, 2015, at 12:37 AM, Burke, Jeff <jburke at remap.ucla.edu<mailto:jburke at remap.ucla.edu>> wrote:


Hi folks,

I am curious where the best place to look is for (or where one could eventually contribute some) examples of actually settings up networkswith NFD, even just simple ones using static routes.    There is a brief mention of nfdc in the install.html but I am looking for a little more of a guidebook for an operator that briefly introduces all of the tools, explains how to set up a small multi-node network and test connectivity, maybe even introduces strategy.  Does such a thing exist?

Thanks,

Jeff


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

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

From shijunxiao at email.arizona.edu  Fri Feb 27 09:00:42 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Fri, 27 Feb 2015 10:00:42 -0700
Subject: [Nfd-dev] Examples of setting up NFD networks
In-Reply-To: <D115E1E5.1BBD6E%jburke@remap.ucla.edu>
References: <72E81791-D1F7-4734-B0B3-1E8D295ECF68@wustl.edu>
	<D115E1E5.1BBD6E%jburke@remap.ucla.edu>
Message-ID: <CAOFH+OafKQbaFA=qfhd2UkjB+B4k12Qr-1QCeyvxkJR7BA=0TA@mail.gmail.com>

Dear folks

I'd suggest posting experiences on personal blogs first.
Best articles are collected into named-data.net homepage. I already got two
articles published there.

Yours, Junxiao

On Fri, Feb 27, 2015 at 9:57 AM, Burke, Jeff <jburke at remap.ucla.edu> wrote:

>  John,
> I was thinking of public resources, so perhaps on the NFD wiki?
> Jeff
>
>   From: "Dehart, John" <jdd at wustl.edu>
> Date: Fri, 27 Feb 2015 16:54:17 +0000
> To: Jeff Burke <jburke at remap.ucla.edu>
> Cc: "nfd-dev at lists.cs.ucla.edu" <nfd-dev at lists.cs.ucla.edu>
> Subject: Re: [Nfd-dev] Examples of setting up NFD networks
>
>
>  Jeff,
>
>  Would it make sense to put together something on the NDN Wiki?
>
>  https://ndnpub.caida.org/bin/view/NDN/WebHome
>
>  I just went through some of the pages there and there is a lot that is
> out of date.
>
>  John
>
>  On Feb 27, 2015, at 12:37 AM, Burke, Jeff <jburke at remap.ucla.edu> wrote:
>
>
>  Hi folks,
>
>  I am curious where the best place to look is for (or where one could
> eventually contribute some) examples of actually settings up networkswith
> NFD, even just simple ones using static routes.    There is a brief mention
> of nfdc in the install.html but I am looking for a little more of a
> guidebook for an operator that briefly introduces all of the tools,
> explains how to set up a small multi-node network and test connectivity,
> maybe even introduces strategy.  Does such a thing exist?
>
>  Thanks,
>
>  Jeff
>
>
>  _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150227/13bb4150/attachment.html>

From shijunxiao at email.arizona.edu  Fri Feb 27 16:33:43 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Fri, 27 Feb 2015 17:33:43 -0700
Subject: [Nfd-dev] code-style: line width
Message-ID: <CAOFH+OYqGYpwnJVT57c9s0LL2Dh2Z7vMpTRJu9auzaXN4Up3Ng@mail.gmail.com>

Dear folks

ndn-cxx code style currently states that line width SHOULD be limited to
100 columns.
This matter has been disputed in several recent code reviews.
Sometimes I'm also struggling to satisfy this requirement.

I suggest amending the rule to set 130 columns as a hard limit.
132 columns is a common terminal width, but two columns should be reserved
for 'diff'.

What do others on this mailing list think?

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

From davide.pesavento at lip6.fr  Fri Feb 27 16:59:11 2015
From: davide.pesavento at lip6.fr (Davide Pesavento)
Date: Sat, 28 Feb 2015 01:59:11 +0100
Subject: [Nfd-dev] code-style: line width
In-Reply-To: <CAOFH+OYqGYpwnJVT57c9s0LL2Dh2Z7vMpTRJu9auzaXN4Up3Ng@mail.gmail.com>
References: <CAOFH+OYqGYpwnJVT57c9s0LL2Dh2Z7vMpTRJu9auzaXN4Up3Ng@mail.gmail.com>
Message-ID: <CADfzvvZj1Xaq70L7KoNvY25T4RDSp5+_eCgqnZn=rKazrVgaog@mail.gmail.com>

As a hard limit, 130 sounds acceptable to me. Although if you're doing
side-by-side diffs/merges, or editing in two vertically-split panes,
130 is way too much. Therefore I think we should still encourage
staying below 100 columns (or even 80), unless line wrapping in that
point makes the code really harder to read.

Best,
Davide

On Sat, Feb 28, 2015 at 1:33 AM, Junxiao Shi
<shijunxiao at email.arizona.edu> wrote:
> Dear folks
>
> ndn-cxx code style currently states that line width SHOULD be limited to 100
> columns.
> This matter has been disputed in several recent code reviews.
> Sometimes I'm also struggling to satisfy this requirement.
>
> I suggest amending the rule to set 130 columns as a hard limit.
> 132 columns is a common terminal width, but two columns should be reserved
> for 'diff'.
>
> What do others on this mailing list think?
>
> Yours, Junxiao
>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>


From yingdi at CS.UCLA.EDU  Fri Feb 27 17:28:50 2015
From: yingdi at CS.UCLA.EDU (Yingdi Yu)
Date: Fri, 27 Feb 2015 17:28:50 -0800
Subject: [Nfd-dev] code-style: line width
In-Reply-To: <CAOFH+OYqGYpwnJVT57c9s0LL2Dh2Z7vMpTRJu9auzaXN4Up3Ng@mail.gmail.com>
References: <CAOFH+OYqGYpwnJVT57c9s0LL2Dh2Z7vMpTRJu9auzaXN4Up3Ng@mail.gmail.com>
Message-ID: <46DC52A8-B3FC-4986-8319-BD70959CB79D@cs.ucla.edu>

Would that cause some inconvenience on gerrit code review?

Yingdi




> On Feb 27, 2015, at 4:33 PM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:
> 
> Dear folks
> 
> ndn-cxx code style currently states that line width SHOULD be limited to 100 columns.
> This matter has been disputed in several recent code reviews.
> Sometimes I'm also struggling to satisfy this requirement.
> 
> I suggest amending the rule to set 130 columns as a hard limit.
> 132 columns is a common terminal width, but two columns should be reserved for 'diff'.
> 
> What do others on this mailing list think?
> 
> Yours, Junxiao
> 
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

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

From shijunxiao at email.ARIZONA.EDU  Fri Feb 27 17:40:02 2015
From: shijunxiao at email.ARIZONA.EDU (Junxiao Shi)
Date: Fri, 27 Feb 2015 18:40:02 -0700
Subject: [Nfd-dev] code-style: line width
In-Reply-To: <46DC52A8-B3FC-4986-8319-BD70959CB79D@cs.ucla.edu>
References: <CAOFH+OYqGYpwnJVT57c9s0LL2Dh2Z7vMpTRJu9auzaXN4Up3Ng@mail.gmail.com>
	<46DC52A8-B3FC-4986-8319-BD70959CB79D@cs.ucla.edu>
Message-ID: <CAOFH+OZNxHKdGn_=hnBTjrc8KG3Ej88Wm5=nG1dUOJoaXYxQVA@mail.gmail.com>

Hi Yingdi

Yes, anything over 100 columns will cause minor inconvenience on Gerrit.
Gerrit old style wraps at 100 columns.
Gerrit new style doesn't work on a touchscreen so I can't use it at all.

Yours, Junxiao

On Feb 27, 2015 6:28 PM, "Yingdi Yu" <yingdi at cs.ucla.edu> wrote:
>
> Would that cause some inconvenience on gerrit code review?
>
> Yingdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150227/baeabaed/attachment.html>

From alexander.afanasyev at ucla.edu  Fri Feb 27 18:21:24 2015
From: alexander.afanasyev at ucla.edu (Alex Afanasyev)
Date: Fri, 27 Feb 2015 18:21:24 -0800
Subject: [Nfd-dev] code-style: line width
In-Reply-To: <CADfzvvZj1Xaq70L7KoNvY25T4RDSp5+_eCgqnZn=rKazrVgaog@mail.gmail.com>
References: <CAOFH+OYqGYpwnJVT57c9s0LL2Dh2Z7vMpTRJu9auzaXN4Up3Ng@mail.gmail.com>
	<CADfzvvZj1Xaq70L7KoNvY25T4RDSp5+_eCgqnZn=rKazrVgaog@mail.gmail.com>
Message-ID: <08FD476D-54DD-4A25-919D-E1AC58638D38@ucla.edu>

I personally, do not want to make changes for the the rule we have.  The current rule states:

  - Lines should be within a reasonable range. Lines longer than 100 columns should generally be avoided.

This rule was meant to be guideline and it still holds.  I would like to see lines to be mostly within 100 columns, as it is more convenient.  It doesn't preclude lines to be longer and doesn't require any justification to be put inside the code.  During the code review we can ask why line is longer or suggest to shorten it, but this is not something that worth having conversation for a long time (as we do now).

---
Alex

> On Feb 27, 2015, at 4:59 PM, Davide Pesavento <davide.pesavento at lip6.fr> wrote:
> 
> As a hard limit, 130 sounds acceptable to me. Although if you're doing
> side-by-side diffs/merges, or editing in two vertically-split panes,
> 130 is way too much. Therefore I think we should still encourage
> staying below 100 columns (or even 80), unless line wrapping in that
> point makes the code really harder to read.
> 
> Best,
> Davide
> 
> On Sat, Feb 28, 2015 at 1:33 AM, Junxiao Shi
> <shijunxiao at email.arizona.edu> wrote:
>> Dear folks
>> 
>> ndn-cxx code style currently states that line width SHOULD be limited to 100
>> columns.
>> This matter has been disputed in several recent code reviews.
>> Sometimes I'm also struggling to satisfy this requirement.
>> 
>> I suggest amending the rule to set 130 columns as a hard limit.
>> 132 columns is a common terminal width, but two columns should be reserved
>> for 'diff'.
>> 
>> What do others on this mailing list think?
>> 
>> Yours, Junxiao
>> 
>> 
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>> 
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

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

From shijunxiao at email.arizona.edu  Fri Feb 27 18:31:40 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Fri, 27 Feb 2015 19:31:40 -0700
Subject: [Nfd-dev] code-style: line width
In-Reply-To: <08FD476D-54DD-4A25-919D-E1AC58638D38@ucla.edu>
References: <CAOFH+OYqGYpwnJVT57c9s0LL2Dh2Z7vMpTRJu9auzaXN4Up3Ng@mail.gmail.com>
	<CADfzvvZj1Xaq70L7KoNvY25T4RDSp5+_eCgqnZn=rKazrVgaog@mail.gmail.com>
	<08FD476D-54DD-4A25-919D-E1AC58638D38@ucla.edu>
Message-ID: <CAOFH+OZhVUyrkJqCxq6oGVV8Kn1GO32qfoz3TVqEw0h2RGkpdQ@mail.gmail.com>

Dear folks

By doing so you are imposing implicit rules. It's bad to have any implicit
rule.

I suggest amending this rule as:

Line width generally should be within 100 columns, and must not exceed 130
columns.
Exception: An URI longer than 130 columns should be kept on one line so
that it can be copied in its entirety.

Yours, Junxiao
On Feb 27, 2015 7:21 PM, "Alex Afanasyev" <alexander.afanasyev at ucla.edu>
wrote:

> I personally, do not want to make changes for the the rule we have.  The
> current rule states:
>
>   - Lines should be within a reasonable range. Lines longer than 100
> columns should generally be avoided.
>
> This rule was meant to be guideline and it still holds.  I would like to
> see lines to be mostly within 100 columns, as it is more convenient.  It
> doesn't preclude lines to be longer and doesn't require any justification
> to be put inside the code.  During the code review we can ask why line is
> longer or suggest to shorten it, but this is not something that worth
> having conversation for a long time (as we do now).
>
> ---
> Alex
>
> > On Feb 27, 2015, at 4:59 PM, Davide Pesavento <davide.pesavento at lip6.fr>
> wrote:
> >
> > As a hard limit, 130 sounds acceptable to me. Although if you're doing
> > side-by-side diffs/merges, or editing in two vertically-split panes,
> > 130 is way too much. Therefore I think we should still encourage
> > staying below 100 columns (or even 80), unless line wrapping in that
> > point makes the code really harder to read.
> >
> > Best,
> > Davide
> >
> > On Sat, Feb 28, 2015 at 1:33 AM, Junxiao Shi
> > <shijunxiao at email.arizona.edu> wrote:
> >> Dear folks
> >>
> >> ndn-cxx code style currently states that line width SHOULD be limited
> to 100
> >> columns.
> >> This matter has been disputed in several recent code reviews.
> >> Sometimes I'm also struggling to satisfy this requirement.
> >>
> >> I suggest amending the rule to set 130 columns as a hard limit.
> >> 132 columns is a common terminal width, but two columns should be
> reserved
> >> for 'diff'.
> >>
> >> What do others on this mailing list think?
> >>
> >> Yours, Junxiao
> >>
> >>
> >> _______________________________________________
> >> Nfd-dev mailing list
> >> Nfd-dev at lists.cs.ucla.edu
> >> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
> >>
> > _______________________________________________
> > Nfd-dev mailing list
> > Nfd-dev at lists.cs.ucla.edu
> > http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150227/c97b4a20/attachment.html>

From lanwang at memphis.edu  Sat Feb 28 22:02:24 2015
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Sun, 1 Mar 2015 06:02:24 +0000
Subject: [Nfd-dev] strange results
Message-ID: <4F83561F-26DD-4D86-B8C2-AD97884E513D@memphis.edu>

Hi all,

We're seeing strange results from our latest experiments.  Below is an ndndump trace of one ndnping packet from UCLA to CAIDA.  We ran the experiments using mini-ndn.  I'm also attaching a png file that shows where the Interests and Data packets were forwarded (white is the original transmission of the Interest,  yellow and blue indicate retransmissions of this Interest with the same nonce by different routers).

[Lans-MacBook-Air:test-ucla-ping-cpu-alloc-withNLSRlog-timing/ls/faces-2] lanwang1% grep "/ndn/edu/caida/ping/251436634" */dump* | sort -t ":" -k 2 | more
ucla/dump.0ucla:1425075159.119036 From: 1.0.0.42, To: 1.0.0.41, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48
csu/dump.0csu:1425075159.119112 From: 1.0.0.42, To: 1.0.0.41, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48
csu/dump.4csu:1425075159.140391 From: 1.0.0.29, To: 1.0.0.30, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48
memphis/dump.1memphis:1425075159.140488 From: 1.0.0.29, To: 1.0.0.30, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48
ucla/dump.1ucla:1425075159.164108 From: 1.0.0.73, To: 1.0.0.74, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48
umich/dump.0umich:1425075159.164185 From: 1.0.0.73, To: 1.0.0.74, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48
umich/dump.2umich:1425075159.179542 From: 1.0.0.50, To: 1.0.0.49, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48
csu/dump.6csu:1425075159.179620 From: 1.0.0.50, To: 1.0.0.49, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48
memphis/dump.2memphis:1425075159.181041 From: 1.0.0.18, To: 1.0.0.17, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48
caida/dump.4caida:1425075159.181138 From: 1.0.0.18, To: 1.0.0.17, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48
caida/dump.4caida:1425075159.224372 From: 1.0.0.17, To: 1.0.0.18, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392
memphis/dump.2memphis:1425075159.224444 From: 1.0.0.17, To: 1.0.0.18, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392
memphis/dump.1memphis:1425075159.245821 From: 1.0.0.30, To: 1.0.0.29, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392
csu/dump.4csu:1425075159.245887 From: 1.0.0.30, To: 1.0.0.29, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392
csu/dump.0csu:1425075159.262268 From: 1.0.0.41, To: 1.0.0.42, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392
ucla/dump.0ucla:1425075159.262344 From: 1.0.0.41, To: 1.0.0.42, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392
umich/dump.4umich:1425075159.330700 From: 1.0.0.82, To: 1.0.0.81, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48
uiuc/dump.2uiuc:1425075159.330771 From: 1.0.0.82, To: 1.0.0.81, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48
uiuc/dump.0uiuc:1425075159.345166 From: 1.0.0.46, To: 1.0.0.45, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48
csu/dump.5csu:1425075159.345243 From: 1.0.0.46, To: 1.0.0.45, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48
csu/dump.5csu:1425075159.359534 From: 1.0.0.45, To: 1.0.0.46, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392
uiuc/dump.0uiuc:1425075159.359617 From: 1.0.0.45, To: 1.0.0.46, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392
uiuc/dump.2uiuc:1425075159.365972 From: 1.0.0.81, To: 1.0.0.82, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392
umich/dump.4umich:1425075159.366036 From: 1.0.0.81, To: 1.0.0.82, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392
umich/dump.0umich:1425075159.399394 From: 1.0.0.74, To: 1.0.0.73, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392
ucla/dump.1ucla:1425075159.399522 From: 1.0.0.74, To: 1.0.0.73, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392

Since all these Interests were duplicates of the original Interest, there should be only one copy of the Data packet going back to the ndnping client, but it seems that the Data came back in two paths:

- CAIDA -> Memphis -> CSU -> UCLA
- CAIDA -> Memphis -> CSU -> UIUC -> UMich -> UCLA

Seems that CSU was not doing duplicate Interest suppression correctly.   The Interest from UIUC to CSU received at time 1425075159.345243 should have been dropped because it's a duplicate of the earlier Interest from UCLA to CSU received at time 1425075159.119112, but it was not and instead brought data back.  The time difference between the two Interests is 226ms.  I'm not sure how the duplicate suppression is implemented.  Someone more familiar with the forwarding pipeline please help explain the above trace.  Thanks.

Lan
[cid:59468F57-8C20-45FA-AD6A-C6E51220647E]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150301/9a82011f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ucla-ip.png
Type: image/png
Size: 216133 bytes
Desc: ucla-ip.png
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150301/9a82011f/attachment.png>

From shijunxiao at email.arizona.edu  Sat Feb 28 22:08:27 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Sat, 28 Feb 2015 23:08:27 -0700
Subject: [Nfd-dev] ndn-cxx feature deprecation: Block::fromBuffer overloads
	with output parameter
Message-ID: <CAOFH+Oa0jMifEmvASD74dTS8ZRC-A7-GB6y1PN9zM=asD1S3pQ@mail.gmail.com>

Dear folks

The following items are deprecated in ndn-cxx:

   - bool Block::fromBuffer(const ConstBufferPtr&, size_t, Block&)
   - bool Block::fromBuffer(const uint8_t*, size_t, Block&)

If you have code that uses any of those features, please migrate to the new
syntax as described in Doxygen.

I will add DEPRECATED macro onto those items soon, but that Change won't
merge until after Mar 08 12:00 UTC.
This means compiler will produce a warning whenever they are used. If your
project uses "-Werror" flag, this would become an error.
Try compiling your projects with http://gerrit.named-data.net/1822 to see
what happens.

Those deprecated items will be deleted in v0.5.

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

From lanwang at memphis.edu  Sat Feb 28 22:28:13 2015
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Sun, 1 Mar 2015 06:28:13 +0000
Subject: [Nfd-dev] strange results
In-Reply-To: <4F83561F-26DD-4D86-B8C2-AD97884E513D@memphis.edu>
References: <4F83561F-26DD-4D86-B8C2-AD97884E513D@memphis.edu>
Message-ID: <4A7C4BA3-B5C3-456A-B1CA-24891D28996A@memphis.edu>

In case you are wondering why this is a problem.  Look at the UMich node.  It first forwarded the Interest to CSU, but that one didn't bring back the data (perhaps it was correctly suppressed).  However, its second Interest to UIUC did bring back data (which should not have happened).  So from that point on, it's going to use UIUC instead of the better path CSU to forward Interest to CAIDA.  We did observe this problem.

Lan

On Mar 1, 2015, at 12:02 AM, Lan Wang (lanwang) <lanwang at memphis.edu<mailto:lanwang at memphis.edu>> wrote:

Hi all,

We're seeing strange results from our latest experiments.  Below is an ndndump trace of one ndnping packet from UCLA to CAIDA.  We ran the experiments using mini-ndn.  I'm also attaching a png file that shows where the Interests and Data packets were forwarded (white is the original transmission of the Interest,  yellow and blue indicate retransmissions of this Interest with the same nonce by different routers).

[Lans-MacBook-Air:test-ucla-ping-cpu-alloc-withNLSRlog-timing/ls/faces-2] lanwang1% grep "/ndn/edu/caida/ping/251436634" */dump* | sort -t ":" -k 2 | more
ucla/dump.0ucla:1425075159.119036 From: 1.0.0.42, To: 1.0.0.41, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48
csu/dump.0csu:1425075159.119112 From: 1.0.0.42, To: 1.0.0.41, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48
csu/dump.4csu:1425075159.140391 From: 1.0.0.29, To: 1.0.0.30, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48
memphis/dump.1memphis:1425075159.140488 From: 1.0.0.29, To: 1.0.0.30, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48
ucla/dump.1ucla:1425075159.164108 From: 1.0.0.73, To: 1.0.0.74, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48
umich/dump.0umich:1425075159.164185 From: 1.0.0.73, To: 1.0.0.74, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48
umich/dump.2umich:1425075159.179542 From: 1.0.0.50, To: 1.0.0.49, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48
csu/dump.6csu:1425075159.179620 From: 1.0.0.50, To: 1.0.0.49, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48
memphis/dump.2memphis:1425075159.181041 From: 1.0.0.18, To: 1.0.0.17, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48
caida/dump.4caida:1425075159.181138 From: 1.0.0.18, To: 1.0.0.17, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48
caida/dump.4caida:1425075159.224372 From: 1.0.0.17, To: 1.0.0.18, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392
memphis/dump.2memphis:1425075159.224444 From: 1.0.0.17, To: 1.0.0.18, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392
memphis/dump.1memphis:1425075159.245821 From: 1.0.0.30, To: 1.0.0.29, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392
csu/dump.4csu:1425075159.245887 From: 1.0.0.30, To: 1.0.0.29, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392
csu/dump.0csu:1425075159.262268 From: 1.0.0.41, To: 1.0.0.42, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392
ucla/dump.0ucla:1425075159.262344 From: 1.0.0.41, To: 1.0.0.42, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392
umich/dump.4umich:1425075159.330700 From: 1.0.0.82, To: 1.0.0.81, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48
uiuc/dump.2uiuc:1425075159.330771 From: 1.0.0.82, To: 1.0.0.81, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48
uiuc/dump.0uiuc:1425075159.345166 From: 1.0.0.46, To: 1.0.0.45, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48
csu/dump.5csu:1425075159.345243 From: 1.0.0.46, To: 1.0.0.45, Tunnel Type: UDP, INTEREST: /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size: 48
csu/dump.5csu:1425075159.359534 From: 1.0.0.45, To: 1.0.0.46, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392
uiuc/dump.0uiuc:1425075159.359617 From: 1.0.0.45, To: 1.0.0.46, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392
uiuc/dump.2uiuc:1425075159.365972 From: 1.0.0.81, To: 1.0.0.82, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392
umich/dump.4umich:1425075159.366036 From: 1.0.0.81, To: 1.0.0.82, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392
umich/dump.0umich:1425075159.399394 From: 1.0.0.74, To: 1.0.0.73, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392
ucla/dump.1ucla:1425075159.399522 From: 1.0.0.74, To: 1.0.0.73, Tunnel Type: UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392

Since all these Interests were duplicates of the original Interest, there should be only one copy of the Data packet going back to the ndnping client, but it seems that the Data came back in two paths:

- CAIDA -> Memphis -> CSU -> UCLA
- CAIDA -> Memphis -> CSU -> UIUC -> UMich -> UCLA

Seems that CSU was not doing duplicate Interest suppression correctly.   The Interest from UIUC to CSU received at time 1425075159.345243 should have been dropped because it's a duplicate of the earlier Interest from UCLA to CSU received at time 1425075159.119112, but it was not and instead brought data back.  The time difference between the two Interests is 226ms.  I'm not sure how the duplicate suppression is implemented.  Someone more familiar with the forwarding pipeline please help explain the above trace.  Thanks.

Lan
<ucla-ip.png>
_______________________________________________
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/20150301/097affa2/attachment.html>

From shijunxiao at email.arizona.edu  Sat Feb 28 22:53:48 2015
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Sat, 28 Feb 2015 23:53:48 -0700
Subject: [Nfd-dev] strange results
In-Reply-To: <4F83561F-26DD-4D86-B8C2-AD97884E513D@memphis.edu>
References: <4F83561F-26DD-4D86-B8C2-AD97884E513D@memphis.edu>
Message-ID: <CAOFH+OahGbdRAB4eGGd=wUSR07eOAERXD+idjW+uak16N4L6jw@mail.gmail.com>

Hi Lan

Trace of CSU node has:

   1. 5159.119 interestFrom UCLA
   2. 5159.140 interestTo MEMPHIS
   3. 5159.179 interestFrom UMICH
   4. 5159.245887 dataFrom MEMPHIS
   5. 5159.262 dataTo UCLA
   6. 5159.345243 interestFrom UIUC
   7. 5159.359 dataTo UIUC


Here's what happens:

5159.119 upon receiving packet 1, new PIT entry is created with in-record
of UCLA face
5159.140 Interest is forwarded to MEMPHIS as packet 2; out-record of
MEMPHIS face is created
5159.179 packet 3 arrives, but it's suppressed due to duplicate Nonce in
PIT entry
5159.245887 packet 4 arrives and satisfies the PIT entry; straggler timer
is set to erase the PIT entry at 5159.345887
5159.262 Data is returned to UCLA as packet 5, but not UMICH because packet
2 was suppressed; in-records and out-record of MEMPHIS face are deleted;
Nonce is not inserted to DeadNonceList because there's no risk of looping
(see spec for exact condition)
5159.345243 packet 6 arrives and cancels the straggler timer; it hits
ContentStore and is not forwarded
5159.345887 PIT entry won't be deleted now because straggler timer was
cancelled by packet 6
5159.359 Data from ContentStore is returned to UIUC as packet 7


The problematic step is: "in-records and out-record of MEMPHIS face are
deleted".
Originally, PIT entry has a NonceList data structure to detect duplicate
Nonces. Deleting in-records won't affect duplicate Nonce detection.
When DeadNonceList is introduced, the PIT NonceList is dropped, and PIT
entry would report a duplicate Nonce only if any in-record or out-record
contains a duplicate Nonce.
This assumes that in-records are retained before straggler timer expires,
but forwarding pipelines are not able to fulfill this assumption.

This issue is tracked as Bug 2592
<http://redmine.named-data.net/issues/2592>.
Root cause is found, but I need to think about the design.

Yours, Junxiao

On Sat, Feb 28, 2015 at 11:02 PM, Lan Wang (lanwang) <lanwang at memphis.edu>
wrote:

>  csu/dump.0csu:1425075159.119112 From: 1.0.0.42, To: 1.0.0.41, Tunnel
> Type: UDP, INTEREST:
> /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size:
> 48
> csu/dump.4csu:1425075159.140391 From: 1.0.0.29, To: 1.0.0.30, Tunnel Type:
> UDP, INTEREST:
> /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size:
> 48
> csu/dump.6csu:1425075159.179620 From: 1.0.0.50, To: 1.0.0.49, Tunnel Type:
> UDP, INTEREST:
> /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size:
> 48
> csu/dump.4csu:1425075159.245887 From: 1.0.0.30, To: 1.0.0.29, Tunnel Type:
> UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392
> csu/dump.0csu:1425075159.262268 From: 1.0.0.41, To: 1.0.0.42, Tunnel Type:
> UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392
> csu/dump.5csu:1425075159.345243 From: 1.0.0.46, To: 1.0.0.45, Tunnel Type:
> UDP, INTEREST:
> /ndn/edu/caida/ping/251436634?ndn.MustBeFresh=1&ndn.Nonce=251436634, size:
> 48
> csu/dump.5csu:1425075159.359534 From: 1.0.0.45, To: 1.0.0.46, Tunnel Type:
> UDP, DATA: /ndn/edu/caida/ping/251436634, size: 392
>
>  Seems that CSU was not doing duplicate Interest suppression correctly.
> The Interest from UIUC to CSU received at time 1425075159.345243 should
> have been dropped because it's a duplicate of the earlier Interest from
> UCLA to CSU received at time 1425075159.119112, but it was not and instead
> brought data back.  The time difference between the two Interests is
> 226ms.  I'm not sure how the duplicate suppression is implemented.  Someone
> more familiar with the forwarding pipeline please help explain the above
> trace.  Thanks.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150228/03be6fa7/attachment.html>