From shijunxiao at email.arizona.edu  Wed Jun  1 07:47:01 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Wed, 1 Jun 2016 07:47:01 -0700
Subject: [Nfd-dev] ndncon test producers
In-Reply-To: <F0C00179-348F-4BE7-A242-3FA9B49D3DD3@email.arizona.edu>
References: <941B7F63-F6FF-4BAD-B2B0-E33EA638F38C@remap.ucla.edu>
	<CAOFH+ObWoj+mO+Rm7QbxYvaOewOkxoOzJU2oE5deSoWKikFwDQ@mail.gmail.com>
	<6b2efb0b-1901-4b63-94e1-e6410f9461e8@EMHUB6.ad.ucla.edu>
	<F0C00179-348F-4BE7-A242-3FA9B49D3DD3@email.arizona.edu>
Message-ID: <47880D80-0BA1-489F-ADC6-010F36E9D969@email.arizona.edu>

Hi Peter

I notice that the test producer ?freeculture? is using a prefix registration that will stop working at any minute.
Its prefix is /ndn/edu/ucla/remap/ndnrtc/user/freeculture, but NFD automatic prefix propagation won?t propagate this prefix registration.

You can install your own certificate onto the producer machine, and then change the producer?s prefix to /ndn/edu/ucla/remap/peter/ndnrtc/user/freeculture.

Yours, Junxiao


From jdd at wustl.edu  Wed Jun  1 08:47:42 2016
From: jdd at wustl.edu (Dehart, John)
Date: Wed, 1 Jun 2016 15:47:42 +0000
Subject: [Nfd-dev] ndncon test producers
In-Reply-To: <47880D80-0BA1-489F-ADC6-010F36E9D969@email.arizona.edu>
References: <941B7F63-F6FF-4BAD-B2B0-E33EA638F38C@remap.ucla.edu>
	<CAOFH+ObWoj+mO+Rm7QbxYvaOewOkxoOzJU2oE5deSoWKikFwDQ@mail.gmail.com>
	<6b2efb0b-1901-4b63-94e1-e6410f9461e8@EMHUB6.ad.ucla.edu>
	<F0C00179-348F-4BE7-A242-3FA9B49D3DD3@email.arizona.edu>
	<47880D80-0BA1-489F-ADC6-010F36E9D969@email.arizona.edu>
Message-ID: <5F008E96-F78C-425E-BFA8-FF9D3EA97F27@wustl.edu>


Junxiao,

I guess it will stop working when nfd restarts, right?

When I changed the nfd-autoreg config, I just restarted it but not nfd.
So, any current FIB entries from the old autoreg config will remain for now.

John

> On Jun 1, 2016, at 9:47 AM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:
> 
> Hi Peter
> 
> I notice that the test producer ?freeculture? is using a prefix registration that will stop working at any minute.
> Its prefix is /ndn/edu/ucla/remap/ndnrtc/user/freeculture, but NFD automatic prefix propagation won?t propagate this prefix registration.
> 
> You can install your own certificate onto the producer machine, and then change the producer?s prefix to /ndn/edu/ucla/remap/peter/ndnrtc/user/freeculture.
> 
> Yours, Junxiao
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev




From yudiandreanp at live.com  Wed Jun  1 10:59:16 2016
From: yudiandreanp at live.com (Yudi Andrean)
Date: Wed, 1 Jun 2016 17:59:16 +0000
Subject: [Nfd-dev] [NFD-Android] Auto prefix propagate
Message-ID: <HK2PR06MB1218A750788F6372391D8D8BA1470@HK2PR06MB1218.apcprd06.prod.outlook.com>

Dear devs,


Auto-prefix propagation has been around for a while now. Has it been enabled on Android NFD? If yes, how can I configure and customize it?

Thanks

---

Regards,

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

From aa at CS.UCLA.EDU  Wed Jun  1 11:16:45 2016
From: aa at CS.UCLA.EDU (Alex Afanasyev)
Date: Wed, 1 Jun 2016 14:16:45 -0400
Subject: [Nfd-dev] [NFD-Android] Auto prefix propagate
In-Reply-To: <HK2PR06MB1218A750788F6372391D8D8BA1470@HK2PR06MB1218.apcprd06.prod.outlook.com>
References: <HK2PR06MB1218A750788F6372391D8D8BA1470@HK2PR06MB1218.apcprd06.prod.outlook.com>
Message-ID: <B3050A5C-8CF9-436F-AFCA-4D180DBF99E1@cs.ucla.edu>

Hi Yudi,

The code is part of the NFD-Android, but there is a "small" missing piece: configuration of identities to use for this.  There is a work in progress, but due to limited man power it is not yet merged.  It would be terrific if you can help (I can send you more details).

--
Alex

> On Jun 1, 2016, at 1:59 PM, Yudi Andrean <yudiandreanp at live.com> wrote:
> 
> Dear devs,
> 
> Auto-prefix propagation has been around for a while now. Has it been enabled on Android NFD? If yes, how can I configure and customize it?
> Thanks
> ---
> Regards,
> Yudi
> 

-------------- 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/20160601/b26d29ea/attachment.bin>

From yudiandreanp at live.com  Wed Jun  1 11:50:50 2016
From: yudiandreanp at live.com (Yudi Andrean)
Date: Wed, 1 Jun 2016 18:50:50 +0000
Subject: [Nfd-dev] [NFD-Android] Auto prefix propagate
In-Reply-To: <B3050A5C-8CF9-436F-AFCA-4D180DBF99E1@cs.ucla.edu>
References: <HK2PR06MB1218A750788F6372391D8D8BA1470@HK2PR06MB1218.apcprd06.prod.outlook.com>
	<B3050A5C-8CF9-436F-AFCA-4D180DBF99E1@cs.ucla.edu>
Message-ID: <HK2PR06MB12185B84D85152BA6B8E2C27A1470@HK2PR06MB1218.apcprd06.prod.outlook.com>

Alex,

Sure, I'd love to. Seeing it working would be nice. You can mail me the details.

---
Yudi


On 2 Jun 2016, at 01:17, Alex Afanasyev <aa at cs.ucla.edu<mailto:aa at cs.ucla.edu>> wrote:

Hi Yudi,

The code is part of the NFD-Android, but there is a "small" missing piece: configuration of identities to use for this.  There is a work in progress, but due to limited man power it is not yet merged.  It would be terrific if you can help (I can send you more details).

--
Alex

 On Jun 1, 2016, at 1:59 PM, Yudi Andrean <yudiandreanp at live.com> wrote:

 Dear devs,

 Auto-prefix propagation has been around for a while now. Has it been enabled on Android NFD? If yes, how can I configure and customize it?
 Thanks
 ---
 Regards,
 Yudi


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

From tteixeira at engin.umass.edu  Wed Jun  1 14:20:22 2016
From: tteixeira at engin.umass.edu (Thiago Teixeira)
Date: Wed, 1 Jun 2016 21:20:22 +0000
Subject: [Nfd-dev] nfd-start yield nothing after fresh installation
Message-ID: <41E7DF15B39B5C46BF24C9545D39304C2AD9B696@oit-ex2010-mb1>

Hi all,

I installed the NFD 0.4.1-21 binaries on two Ubuntu 14-64 bits and everything went well. The two machines are on the same subnet 10.10.1.0/24.
When I run $ nfd-start I get the following message: NFD is already running...

So I run $ nfdc register /ndn udp://10.10.1.1 and I should get the Successful... message, but I get nothing.
nfd-status yields nothing too.
I tried nfd-stop > nfd-start and nothing shows up.

I searched on the mailing list and couldn't find anything.

Do you have any suggestions or tests to do?

Thanks,
Thiago


PS: There's a typo in the building documentation instructions. It should be ./waf doxygen instead of doxgyen
http://named-data.net/doc/NFD/current/INSTALL.html#building-documentation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160601/7fd0af63/attachment.html>

From aa at CS.UCLA.EDU  Thu Jun  2 08:12:41 2016
From: aa at CS.UCLA.EDU (Alex Afanasyev)
Date: Thu, 2 Jun 2016 08:12:41 -0700
Subject: [Nfd-dev] nfd-start yield nothing after fresh installation
In-Reply-To: <41E7DF15B39B5C46BF24C9545D39304C2AD9B696@oit-ex2010-mb1>
References: <41E7DF15B39B5C46BF24C9545D39304C2AD9B696@oit-ex2010-mb1>
Message-ID: <1EC0AFC9-4658-4846-8554-92B3E91C48A0@cs.ucla.edu>

Hi Thiago,

I have observed this once on 14.04 amazon AWS vm.  However, I couldn't reproduce the problem in different 14.04 environment and puzzled on what's going on.

Are you using AWS or just straight linux box/other vm?

---
Alex

> On Jun 1, 2016, at 2:20 PM, Thiago Teixeira <tteixeira at engin.umass.edu> wrote:
> 
> Hi all,
>  
> I installed the NFD 0.4.1-21 binaries on two Ubuntu 14-64 bits and everything went well. The two machines are on the same subnet 10.10.1.0/24.
> When I run $ nfd-start I get the following message: NFD is already running?
>  
> So I run $ nfdc register /ndn udp://10.10.1.1 and I should get the Successful? message, but I get nothing.
> nfd-status yields nothing too.
> I tried nfd-stop > nfd-start and nothing shows up.
>  
> I searched on the mailing list and couldn?t find anything.
>  
> Do you have any suggestions or tests to do?
>  
> Thanks,
> Thiago
>  
> PS: There?s a typo in the building documentation instructions. It should be ./waf doxygen instead of doxgyen
> http://named-data.net/doc/NFD/current/INSTALL.html#building-documentation
> _______________________________________________
> 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/20160602/74446e5a/attachment.html>

From tteixeira at engin.umass.edu  Thu Jun  2 08:20:32 2016
From: tteixeira at engin.umass.edu (Thiago Teixeira)
Date: Thu, 2 Jun 2016 15:20:32 +0000
Subject: [Nfd-dev] nfd-start yield nothing after fresh installation
In-Reply-To: <1EC0AFC9-4658-4846-8554-92B3E91C48A0@cs.ucla.edu>
References: <41E7DF15B39B5C46BF24C9545D39304C2AD9B696@oit-ex2010-mb1>
	<1EC0AFC9-4658-4846-8554-92B3E91C48A0@cs.ucla.edu>
Message-ID: <41E7DF15B39B5C46BF24C9545D39304C2AD9B940@oit-ex2010-mb1>

Hi Alex,

Thanks for your quick reply.
I am using a xen vm on GENI.

Rgds,
Thiago

From: Alex Afanasyev [mailto:aa at cs.ucla.edu]
Sent: Thursday, June 2, 2016 11:13 AM
To: Thiago Teixeira <tteixeira at engin.umass.edu>
Cc: nfd-dev at lists.cs.ucla.edu
Subject: Re: [Nfd-dev] nfd-start yield nothing after fresh installation

Hi Thiago,

I have observed this once on 14.04 amazon AWS vm.  However, I couldn't reproduce the problem in different 14.04 environment and puzzled on what's going on.

Are you using AWS or just straight linux box/other vm?

---
Alex

On Jun 1, 2016, at 2:20 PM, Thiago Teixeira <tteixeira at engin.umass.edu<mailto:tteixeira at engin.umass.edu>> wrote:
Hi all,

I installed the NFD 0.4.1-21 binaries on two Ubuntu 14-64 bits and everything went well. The two machines are on the same subnet 10.10.1.0/24.
When I run $ nfd-start I get the following message: NFD is already running?

So I run $ nfdc register /ndn udp://10.10.1.1 and I should get the Successful? message, but I get nothing.
nfd-status yields nothing too.
I tried nfd-stop > nfd-start and nothing shows up.

I searched on the mailing list and couldn?t find anything.

Do you have any suggestions or tests to do?

Thanks,
Thiago


PS: There?s a typo in the building documentation instructions. It should be ./waf doxygen instead of doxgyen
http://named-data.net/doc/NFD/current/INSTALL.html#building-documentation
_______________________________________________
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/20160602/8be31544/attachment.html>

From shijunxiao at email.arizona.edu  Thu Jun  2 09:37:55 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Thu, 2 Jun 2016 09:37:55 -0700
Subject: [Nfd-dev] [ndn] NDN Seminar: Practical Congestion Control for
 NDN
In-Reply-To: <A84C3ECF-B38B-4397-9434-D77F7F39102B@remap.ucla.edu>
References: <05BCCCCC-4400-4305-8AE5-DE894BF1A7F1@cs.ucla.edu>
	<430E1CDF-ED12-45C9-BD97-125049FE475E@cs.ucla.edu>
	<2A94D772-4EE7-42C0-B030-C0A53E9E164E@cs.ucla.edu>
	<AE1669BA-A316-49C9-A0D7-D73A1CC43680@cs.ucla.edu>
	<574d1575.c451620a.7e7be.ffff9da5@mx.google.com>
	<AA42FA39-A8A8-4039-8A24-C4BD2D9050D4@cs.ucla.edu>
	<48B3ADE0-B913-466B-8A28-D1D8AF2D12D7@email.arizona.edu>
	<1adb5db8-f384-4127-8afc-3d2b710860d7@EMHUB5.ad.ucla.edu>
	<68A7E1B1-EAFD-441B-8568-AD55070ECAE2@email.arizona.edu>
	<24F5D101-226B-40F5-B26E-86E4E96CF9D6@wustl.edu>
	<1B24FB64-4355-41D8-92E1-E01AD44A3391@email.arizona.edu>
	<A84C3ECF-B38B-4397-9434-D77F7F39102B@remap.ucla.edu>
Message-ID: <575060e4.6589420a.5d44e.ffff9be7@mx.google.com>

Hi Peter

NFD-RIB prefers the shortest identity available, because it can register the largest possible namespace toward the end host. This has nothing to do with which identity is the default.
Your KeyChain contains an identity named ndn:/, so that NFD-RIB is trying to register ndn:/ toward your end host, with the certificate associated with this identity. That certificate is almost certainly not trusted by the testbed, thus you won?t get a successful registration.
If you change NFD-RIB loglevel to TRACE, you should be able to see the error.

You need to execute ndnsec delete ndn:/ and then restart NFD.
If necessary, you can backup the private key and certificates of that identity before deleting it.

Yours, Junxiao

From: Gusev, Peter
Sent: Thursday, June 2, 2016 09:27
To: Junxiao Shi
Cc: Dehart, John
Subject: Re: [ndn] NDN Seminar: Practical Congestion Control for NDN

hi Junxiao, 

We weren?t able to make me discoverable on ndncon while connected to REMAP hub.?
Can you please give any advices on troubleshooting this? It seems that we tried everything we could?

My NFD is v0.4.0 build from sources. Certificate installed is default:

$ ndnsec list
* /ndn/edu/ucla/remap/peter
? /
? /peetonn
? /ndn/edu/ucla/remap
? /ndn/edu/ucla/remap/zhehao
? /ndn/edu/ucla/remap/peter/ndncon

I ran ndn-autoconfig?and here?s the grep from NFD log:

$ grep AutoPrefix /tmp/nfd.log
1464817688.388236 INFO: [AutoPrefixPropagator] Load auto_prefix_propagate section in rib section
1464817688.388581 INFO: [AutoPrefixPropagator] Load auto_prefix_propagate section in rib section
1464817688.507553 INFO: [AutoPrefixPropagator] local registration only for /localhost/nfd/rib
1464817696.807139 INFO: [AutoPrefixPropagator] no hub connected to propagate /
1464817701.880132 INFO: [AutoPrefixPropagator] prefix has already been propagated: /
1464817701.957961 INFO: [AutoPrefixPropagator] this is a prefix registered by some hub: /localhop/nfd
1464817701.958131 INFO: [AutoPrefixPropagator] redo 1 propagations when new Hub connectivity is built.
1464817708.727323 INFO: [AutoPrefixPropagator] prefix has already been propagated: /
1464817708.834888 INFO: [AutoPrefixPropagator] prefix has already been propagated: /
1464817709.189442 INFO: [AutoPrefixPropagator] prefix has already been propagated: /
1464817727.020028 INFO: [AutoPrefixPropagator] should be kept for another RIB entry: /ndn

Thanks,?

--?
Peter Gusev

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

Software Engineer/Programmer Analyst?@ REMAP UCLA

Video streaming/ICN?networks/Creative?Development

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

From peter at remap.ucla.edu  Thu Jun  2 09:43:07 2016
From: peter at remap.ucla.edu (Gusev, Peter)
Date: Thu, 2 Jun 2016 16:43:07 +0000
Subject: [Nfd-dev] [ndn] NDN Seminar: Practical Congestion Control for
 NDN
In-Reply-To: <575060e4.6589420a.5d44e.ffff9be7@mx.google.com>
References: <05BCCCCC-4400-4305-8AE5-DE894BF1A7F1@cs.ucla.edu>
	<430E1CDF-ED12-45C9-BD97-125049FE475E@cs.ucla.edu>
	<2A94D772-4EE7-42C0-B030-C0A53E9E164E@cs.ucla.edu>
	<AE1669BA-A316-49C9-A0D7-D73A1CC43680@cs.ucla.edu>
	<574d1575.c451620a.7e7be.ffff9da5@mx.google.com>
	<AA42FA39-A8A8-4039-8A24-C4BD2D9050D4@cs.ucla.edu>
	<48B3ADE0-B913-466B-8A28-D1D8AF2D12D7@email.arizona.edu>
	<1adb5db8-f384-4127-8afc-3d2b710860d7@EMHUB5.ad.ucla.edu>
	<68A7E1B1-EAFD-441B-8568-AD55070ECAE2@email.arizona.edu>
	<24F5D101-226B-40F5-B26E-86E4E96CF9D6@wustl.edu>
	<1B24FB64-4355-41D8-92E1-E01AD44A3391@email.arizona.edu>
	<A84C3ECF-B38B-4397-9434-D77F7F39102B@remap.ucla.edu>
	<575060e4.6589420a.5d44e.ffff9be7@mx.google.com>
Message-ID: <3BAA616A-29A6-4AE9-B8F6-29A53A27828E@remap.ucla.edu>

hi Junxiao,

I deleted this identity, restarted nfd, ndn-autoconfig and ndncon. Do you see me now?

$ grep AutoPrefix /tmp/nfd.log
1464885670.282895 INFO: [AutoPrefixPropagator] Load auto_prefix_propagate section in rib section
1464885670.283290 INFO: [AutoPrefixPropagator] Load auto_prefix_propagate section in rib section
1464885670.400656 INFO: [AutoPrefixPropagator] local registration only for /localhost/nfd/rib
1464885680.576684 INFO: [AutoPrefixPropagator] no signing identity available for: /localhop/ndn-autoconf/hub
1464885685.094809 INFO: [AutoPrefixPropagator] no signing identity available for: /ndn
1464885685.173265 INFO: [AutoPrefixPropagator] this is a prefix registered by some hub: /localhop/nfd
1464885685.173435 INFO: [AutoPrefixPropagator] redo 0 propagations when new Hub connectivity is built.
1464885691.396367 INFO: [AutoPrefixPropagator] no signing identity available for: /ndn/broadcast/ndnrtc/chatrooms
1464885691.502863 INFO: [AutoPrefixPropagator] no signing identity available for: /ndn/broadcast/ndnrtc/users


Thanks,

--
Peter Gusev

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

Software Engineer/Programmer Analyst @ REMAP UCLA

Video streaming/ICN networks/Creative Development

On Jun 2, 2016, at 9:37 AM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:

Hi Peter

NFD-RIB prefers the shortest identity available, because it can register the largest possible namespace toward the end host. This has nothing to do with which identity is the default.
Your KeyChain contains an identity named ndn:/, so that NFD-RIB is trying to register ndn:/ toward your end host, with the certificate associated with this identity. That certificate is almost certainly not trusted by the testbed, thus you won?t get a successful registration.
If you change NFD-RIB loglevel to TRACE, you should be able to see the error.

You need to execute ndnsec delete ndn:/ and then restart NFD.
If necessary, you can backup the private key and certificates of that identity before deleting it.

Yours, Junxiao

From: Gusev, Peter<mailto:peter at remap.ucla.edu>
Sent: Thursday, June 2, 2016 09:27
To: Junxiao Shi<mailto:shijunxiao at email.arizona.edu>
Cc: Dehart, John<mailto:jdd at wustl.edu>
Subject: Re: [ndn] NDN Seminar: Practical Congestion Control for NDN

hi Junxiao,

We weren?t able to make me discoverable on ndncon while connected to REMAP hub.
Can you please give any advices on troubleshooting this? It seems that we tried everything we could?

My NFD is v0.4.0 build from sources. Certificate installed is default:

$ ndnsec list
* /ndn/edu/ucla/remap/peter
  /
  /peetonn
  /ndn/edu/ucla/remap
  /ndn/edu/ucla/remap/zhehao
  /ndn/edu/ucla/remap/peter/ndncon

I ran ndn-autoconfig and here?s the grep from NFD log:

$ grep AutoPrefix /tmp/nfd.log
1464817688.388236 INFO: [AutoPrefixPropagator] Load auto_prefix_propagate section in rib section
1464817688.388581 INFO: [AutoPrefixPropagator] Load auto_prefix_propagate section in rib section
1464817688.507553 INFO: [AutoPrefixPropagator] local registration only for /localhost/nfd/rib
1464817696.807139 INFO: [AutoPrefixPropagator] no hub connected to propagate /
1464817701.880132 INFO: [AutoPrefixPropagator] prefix has already been propagated: /
1464817701.957961 INFO: [AutoPrefixPropagator] this is a prefix registered by some hub: /localhop/nfd
1464817701.958131 INFO: [AutoPrefixPropagator] redo 1 propagations when new Hub connectivity is built.
1464817708.727323 INFO: [AutoPrefixPropagator] prefix has already been propagated: /
1464817708.834888 INFO: [AutoPrefixPropagator] prefix has already been propagated: /
1464817709.189442 INFO: [AutoPrefixPropagator] prefix has already been propagated: /
1464817727.020028 INFO: [AutoPrefixPropagator] should be kept for another RIB entry: /ndn

Thanks,

--
Peter Gusev

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

Software Engineer/Programmer Analyst @ REMAP UCLA

Video streaming/ICN networks/Creative Development

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

From nfd-call-notification at mail1.yoursunny.com  Thu Jun  2 10:00:02 2016
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Thu, 2 Jun 2016 10:00:02 -0700
Subject: [Nfd-dev] NFD call 20160602
Message-ID: <201606021700.u52H02QK006729@lectura.cs.arizona.edu>

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

From shijunxiao at email.arizona.edu  Thu Jun  2 10:33:44 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Thu, 2 Jun 2016 10:33:44 -0700
Subject: [Nfd-dev] [ndn] NDN Seminar: Practical Congestion Control for
 NDN
In-Reply-To: <00cebc36-26b2-488e-868e-d651a65b466e@emhub4.ad.ucla.edu>
References: <05BCCCCC-4400-4305-8AE5-DE894BF1A7F1@cs.ucla.edu>
	<430E1CDF-ED12-45C9-BD97-125049FE475E@cs.ucla.edu>
	<2A94D772-4EE7-42C0-B030-C0A53E9E164E@cs.ucla.edu>
	<AE1669BA-A316-49C9-A0D7-D73A1CC43680@cs.ucla.edu>
	<574d1575.c451620a.7e7be.ffff9da5@mx.google.com>
	<AA42FA39-A8A8-4039-8A24-C4BD2D9050D4@cs.ucla.edu>
	<48B3ADE0-B913-466B-8A28-D1D8AF2D12D7@email.arizona.edu>
	<1adb5db8-f384-4127-8afc-3d2b710860d7@EMHUB5.ad.ucla.edu>
	<68A7E1B1-EAFD-441B-8568-AD55070ECAE2@email.arizona.edu>
	<24F5D101-226B-40F5-B26E-86E4E96CF9D6@wustl.edu>
	<1B24FB64-4355-41D8-92E1-E01AD44A3391@email.arizona.edu>
	<A84C3ECF-B38B-4397-9434-D77F7F39102B@remap.ucla.edu>
	<575060e4.6589420a.5d44e.ffff9be7@mx.google.com>
	<00cebc36-26b2-488e-868e-d651a65b466e@emhub4.ad.ucla.edu>
Message-ID: <57506df9.c4c8620a.55e04.488d@mx.google.com>

Hi Peter

You also need to ndnsec delete ndn:/ndn/edu/ucla/remap . I missed that one earilier.
If there?s still problem:
? paste the output of ndnsec list -c
? in nfd.conf of the end host, set AutoPrefixPropagator loglevel to TRACE, and look at NFD logs
? you don?t need to change anything on the router: there?s no useful log over there

Yours, Junxiao

From: Gusev, Peter
Sent: Thursday, June 2, 2016 09:43
To: Junxiao Shi
Cc: <nfd-dev at lists.cs.ucla.edu>
Subject: Re: [ndn] NDN Seminar: Practical Congestion Control for NDN

hi Junxiao, 

I deleted this identity, restarted nfd, ndn-autoconfig and ndncon. Do you see me now?

$?grep AutoPrefix /tmp/nfd.log
1464885670.282895 INFO: [AutoPrefixPropagator] Load auto_prefix_propagate section in rib section
1464885670.283290 INFO: [AutoPrefixPropagator] Load auto_prefix_propagate section in rib section
1464885670.400656 INFO: [AutoPrefixPropagator] local registration only for /localhost/nfd/rib
1464885680.576684 INFO: [AutoPrefixPropagator] no signing identity available for: /localhop/ndn-autoconf/hub
1464885685.094809 INFO: [AutoPrefixPropagator] no signing identity available for: /ndn
1464885685.173265 INFO: [AutoPrefixPropagator] this is a prefix registered by some hub: /localhop/nfd
1464885685.173435 INFO: [AutoPrefixPropagator] redo 0 propagations when new Hub connectivity is built.
1464885691.396367 INFO: [AutoPrefixPropagator] no signing identity available for: /ndn/broadcast/ndnrtc/chatrooms
1464885691.502863 INFO: [AutoPrefixPropagator] no signing identity available for: /ndn/broadcast/ndnrtc/users


Thanks,?

--?
Peter Gusev

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

Software Engineer/Programmer Analyst?@ REMAP UCLA

Video streaming/ICN?networks/Creative?Development

On Jun 2, 2016, at 9:37 AM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:

Hi Peter
?
NFD-RIB prefers the shortest identity available, because it can register the largest possible namespace toward the end host. This has nothing to do with which identity is the default.
Your KeyChain contains an identity named ndn:/, so that NFD-RIB is trying to register ndn:/ toward your end host, with the certificate associated with this identity. That certificate is almost certainly not trusted by the testbed, thus you won?t get a successful registration.
If you change NFD-RIB loglevel to TRACE, you should be able to see the error.
?
You need to execute?ndnsec delete ndn:/?and then restart NFD.
If necessary, you can backup the private key and certificates of that identity before deleting it.
?
Yours, Junxiao
?
From:?Gusev, Peter
Sent:?Thursday, June 2, 2016 09:27
To:?Junxiao Shi
Cc:?Dehart, John
Subject:?Re: [ndn] NDN Seminar: Practical Congestion Control for NDN
?
hi Junxiao,?
?
We weren?t able to make me discoverable on?ndncon?while connected to REMAP hub.?
Can you please give any advices on troubleshooting this? It seems that we tried everything we could?
?
My NFD is v0.4.0 build from sources. Certificate installed is default:
?
$ ndnsec list
* /ndn/edu/ucla/remap/peter
? /
? /peetonn
? /ndn/edu/ucla/remap
? /ndn/edu/ucla/remap/zhehao
? /ndn/edu/ucla/remap/peter/ndncon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160602/655c97ad/attachment.html>

From shijunxiao at email.arizona.edu  Thu Jun  2 12:05:23 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Thu, 2 Jun 2016 12:05:23 -0700
Subject: [Nfd-dev] [ndn] NDN Seminar: Practical Congestion Control for
 NDN
In-Reply-To: <6c75cadf-f1cf-4c22-aeaf-617d102e4e9b@EMHUB5.ad.ucla.edu>
References: <05BCCCCC-4400-4305-8AE5-DE894BF1A7F1@cs.ucla.edu>
	<430E1CDF-ED12-45C9-BD97-125049FE475E@cs.ucla.edu>
	<2A94D772-4EE7-42C0-B030-C0A53E9E164E@cs.ucla.edu>
	<AE1669BA-A316-49C9-A0D7-D73A1CC43680@cs.ucla.edu>
	<574d1575.c451620a.7e7be.ffff9da5@mx.google.com>
	<AA42FA39-A8A8-4039-8A24-C4BD2D9050D4@cs.ucla.edu>
	<48B3ADE0-B913-466B-8A28-D1D8AF2D12D7@email.arizona.edu>
	<1adb5db8-f384-4127-8afc-3d2b710860d7@EMHUB5.ad.ucla.edu>
	<68A7E1B1-EAFD-441B-8568-AD55070ECAE2@email.arizona.edu>
	<24F5D101-226B-40F5-B26E-86E4E96CF9D6@wustl.edu>
	<1B24FB64-4355-41D8-92E1-E01AD44A3391@email.arizona.edu>
	<A84C3ECF-B38B-4397-9434-D77F7F39102B@remap.ucla.edu>
	<A2CC6739-5421-420A-980E-76A0E6BE617E@wustl.edu>
	<FCFC34D7-1B50-4E4F-84E0-AA9B521D84AA@remap.ucla.edu>
	<DA2B72F9-D885-4226-A319-56BB06DEEF2E@wustl.edu>
	<A959E4EF-D6AE-4507-905C-4425FC732C0E@remap.ucla.edu>
	<BC70558F-D6AF-4B48-B27D-AE8F396B3895@wustl.edu>
	<23D42CE8-3C2B-4FFD-AF0E-073CE9083549@remap.ucla.edu>
	<864D1969-3A81-4015-B533-C81064A41A7E@wustl.edu>
	<E78AAD90-536C-4166-B4E9-09F8A937EB23@wustl.edu>
	<DE2095E2-8C6D-43A8-8AF0-7D90D51ED085@remap.ucla.edu>
	<7FBAC07E-BB34-4884-93A7-C0181059522C@wustl.edu>
	<AB89F0D5-1968-4530-A1C2-FB946BCB2F51@wustl.edu>
	<228C3BBD-7859-41FF-B151-0F237CF742F5@remap.ucla.edu>
	<6c75cadf-f1cf-4c22-aeaf-617d102e4e9b@EMHUB5.ad.ucla.edu>
Message-ID: <10E77B45-9387-47C1-A7A4-2CD624738900@email.arizona.edu>

Hi Peter

This is an unsupported configuration. Certificates can only be requested through ndncert web app, and it?s always tied to your email.

Yours, Junxiao

> On Jun 2, 2016, at 12:02 PM, Gusev, Peter <peter at remap.ucla.edu> wrote:
> 
> hi Junxiao,
> 
> I generated certs for freeculture and confbridge and signed them on REMAP hub like this:
> 
> $ ndnsec-certgen -N confbridge -p /ndn/edu/ucla/remap -r confbridge.pub
> 
> I installed them on corresponding machines, however it seems not working yet.
> Is the above command correct?
> 
> Thanks, 
> 
> -- 
> Peter Gusev
> 
> peter at remap.ucla.edu <mailto:peter at remap.ucla.edu>
> +1 213 5872748
> peetonn_ (skype)
> 
> Software Engineer/Programmer Analyst @ REMAP UCLA
> 
> Video streaming/ICN networks/Creative Development
> 
>> On Jun 2, 2016, at 11:13 AM, Peter Gusev <peter at remap.ucla.edu <mailto:peter at remap.ucla.edu>> wrote:
>> 
>> no, i?m not publishing.
>> 
>> 
>> Junxiao, I?m generating a certificate for confbridge. But I?m not sure I?ll make it in time for the Seminar.
>> 
>> Thanks, 
>> 
>> -- 
>> Peter Gusev
>> 
>> peter at remap.ucla.edu <mailto:peter at remap.ucla.edu>
>> +1 213 5872748
>> peetonn_ (skype)
>> 
>> Software Engineer/Programmer Analyst @ REMAP UCLA
>> 
>> Video streaming/ICN networks/Creative Development

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

From shijunxiao at email.arizona.edu  Thu Jun  2 15:55:20 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Thu, 2 Jun 2016 15:55:20 -0700
Subject: [Nfd-dev] 1-to-Many NDN-RTC test and hub strategy
In-Reply-To: <059000c3-9a62-47cc-a372-b06a1415a4df@emhub4.ad.ucla.edu>
References: <CAOFH+OZL6JLoQZwenACp2a32ruucRbauPM_HuVTTxvzV+0LE0g@mail.gmail.com>
	<5CDE7BF2-2533-407C-A546-3C2A3241C3F7@remap.ucla.edu>
	<059000c3-9a62-47cc-a372-b06a1415a4df@emhub4.ad.ucla.edu>
Message-ID: <CAOFH+ObxW9Ye4ymzavbPvwc8mcjzDtCMsPRrSc12maq+8RRQXw@mail.gmail.com>

Hi Peter

Thanks for the trace.
This indicates an implementation bug in forwarding pipelines.
http://redmine.named-data.net/issues/3642
I'll review relevant code and try to get this fixed in two weeks.

#3642 note-1 also identifies two secondary issues in ndncon or ndn-cpp.
You can try to confirm these and report them to relevant issue trackers
separately.

Yours, Junxiao

On Tue, May 31, 2016 at 11:49 AM, Gusev, Peter <peter at remap.ucla.edu> wrote:

> Hi Junxiao,
>
> Please, find attached the outputs you requested (client1 is a producer).
>
> Thanks,
>
>
>
> --
> Peter Gusev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160602/3a08f745/attachment.html>

From peter at remap.UCLA.edu  Thu Jun  2 15:56:46 2016
From: peter at remap.UCLA.edu (Gusev, Peter)
Date: Thu, 2 Jun 2016 22:56:46 +0000
Subject: [Nfd-dev] 1-to-Many NDN-RTC test and hub strategy
In-Reply-To: <CAOFH+ObxW9Ye4ymzavbPvwc8mcjzDtCMsPRrSc12maq+8RRQXw@mail.gmail.com>
References: <CAOFH+OZL6JLoQZwenACp2a32ruucRbauPM_HuVTTxvzV+0LE0g@mail.gmail.com>
	<5CDE7BF2-2533-407C-A546-3C2A3241C3F7@remap.ucla.edu>
	<059000c3-9a62-47cc-a372-b06a1415a4df@emhub4.ad.ucla.edu>
	<CAOFH+ObxW9Ye4ymzavbPvwc8mcjzDtCMsPRrSc12maq+8RRQXw@mail.gmail.com>
Message-ID: <01438DE5-8AAF-42E9-BF2E-05B553035E9C@remap.ucla.edu>

Thanks, Junxiao,

--
Peter Gusev

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

Software Engineer/Programmer Analyst @ REMAP UCLA

Video streaming/ICN networks/Creative Development

On Jun 2, 2016, at 3:55 PM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:

Hi Peter

Thanks for the trace.
This indicates an implementation bug in forwarding pipelines. http://redmine.named-data.net/issues/3642
I'll review relevant code and try to get this fixed in two weeks.

#3642 note-1 also identifies two secondary issues in ndncon or ndn-cpp.
You can try to confirm these and report them to relevant issue trackers separately.

Yours, Junxiao

On Tue, May 31, 2016 at 11:49 AM, Gusev, Peter <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>> wrote:
Hi Junxiao,

Please, find attached the outputs you requested (client1 is a producer).

Thanks,



--
Peter Gusev


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

From shijunxiao at email.arizona.edu  Fri Jun  3 07:00:41 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Fri, 3 Jun 2016 07:00:41 -0700
Subject: [Nfd-dev] nfd-start yield nothing after fresh installation
In-Reply-To: <41E7DF15B39B5C46BF24C9545D39304C2AD9B696@oit-ex2010-mb1>
References: <41E7DF15B39B5C46BF24C9545D39304C2AD9B696@oit-ex2010-mb1>
Message-ID: <57518d8b.d618620a.6432e.37b4@mx.google.com>

Hi Thiago

I suspect there?s a library ABI mismatch. It?s most likely to happen if ndn-cxx and NFD are not installed together.
You may check this possibility with:
1. find where is your NFD binary with which nfd
2. check whether libraries are linked correctly with ldd /usr/bin/nfd (use the nfd binary path found in step1)

Yours, Junxiao

From: Thiago Teixeira
Sent: Thursday, June 2, 2016 03:30
To: nfd-dev at lists.cs.ucla.edu
Subject: [Nfd-dev] nfd-start yield nothing after fresh installation

Hi all,

I installed the NFD 0.4.1-21 binaries on two Ubuntu 14-64 bits and everything went well. The two machines are on the same subnet 10.10.1.0/24.
When I run $ nfd-start I get the following message: NFD is already running?

So I run $ nfdc register /ndn udp://10.10.1.1 and I should get the Successful? message, but I get nothing.
nfd-status yields nothing too.
I tried nfd-stop > nfd-start and nothing shows up.

I searched on the mailing list and couldn?t find anything.

Do you have any suggestions or tests to do?

Thanks,
Thiago

PS: There?s a typo in the building documentation instructions. It should be ./waf doxygen instead of doxgyen
http://named-data.net/doc/NFD/current/INSTALL.html#building-documentation

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

From shijunxiao at email.arizona.edu  Fri Jun  3 07:11:40 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Fri, 3 Jun 2016 07:11:40 -0700
Subject: [Nfd-dev] [ndn] NDN Seminar: Practical Congestion Control for
 NDN
In-Reply-To: <23D42CE8-3C2B-4FFD-AF0E-073CE9083549@remap.ucla.edu>
References: <05BCCCCC-4400-4305-8AE5-DE894BF1A7F1@cs.ucla.edu>
	<430E1CDF-ED12-45C9-BD97-125049FE475E@cs.ucla.edu>
	<2A94D772-4EE7-42C0-B030-C0A53E9E164E@cs.ucla.edu>
	<AE1669BA-A316-49C9-A0D7-D73A1CC43680@cs.ucla.edu>
	<574d1575.c451620a.7e7be.ffff9da5@mx.google.com>
	<AA42FA39-A8A8-4039-8A24-C4BD2D9050D4@cs.ucla.edu>
	<48B3ADE0-B913-466B-8A28-D1D8AF2D12D7@email.arizona.edu>
	<1adb5db8-f384-4127-8afc-3d2b710860d7@EMHUB5.ad.ucla.edu>
	<68A7E1B1-EAFD-441B-8568-AD55070ECAE2@email.arizona.edu>
	<24F5D101-226B-40F5-B26E-86E4E96CF9D6@wustl.edu>
	<1B24FB64-4355-41D8-92E1-E01AD44A3391@email.arizona.edu>
	<A84C3ECF-B38B-4397-9434-D77F7F39102B@remap.ucla.edu>
	<A2CC6739-5421-420A-980E-76A0E6BE617E@wustl.edu>
	<FCFC34D7-1B50-4E4F-84E0-AA9B521D84AA@remap.ucla.edu>
	<DA2B72F9-D885-4226-A319-56BB06DEEF2E@wustl.edu>
	<A959E4EF-D6AE-4507-905C-4425FC732C0E@remap.ucla.edu>
	<BC70558F-D6AF-4B48-B27D-AE8F396B3895@wustl.edu>
	<23D42CE8-3C2B-4FFD-AF0E-073CE9083549@remap.ucla.edu>
Message-ID: <57519027.8c3f620a.bdaef.49e0@mx.google.com>

Hi Peter

Repeat:
? paste the output of ndnsec list -c
? in nfd.conf of the end host, set AutoPrefixPropagator loglevel to TRACE, and look at NFD logs
? you don?t need to change anything on the router: there?s no useful log over there

You are missing ?-c? when obtaining ndnsec output, and AutoPrefixPropagator loglevel seems to be at INFO, so these outputs don?t contain useful information.

Yours, Junxiao


From: Gusev, Peter
Sent: Thursday, June 2, 2016 10:51
To: Dehart, John
Cc: arizona_operator
Subject: Re: [ndn] NDN Seminar: Practical Congestion Control for NDN

Junxiao, tried it:

$ ndnsec list?
* /ndn/edu/ucla/remap/peter
? /peetonn
? /ndn/edu/ucla/remap/zhehao
? /ndn/edu/ucla/remap/peter/ndncon


$?grep AutoPrefixPropagator /tmp/nfd.log?

1464889719.657679 INFO: [AutoPrefixPropagator] Load auto_prefix_propagate section in rib section
1464889719.658038 INFO: [AutoPrefixPropagator] Load auto_prefix_propagate section in rib section
1464889719.734308 INFO: [AutoPrefixPropagator] local registration only for /localhost/nfd/rib
1464889740.790335 INFO: [AutoPrefixPropagator] no signing identity available for: /localhop/ndn-autoconf/hub
1464889745.692269 INFO: [AutoPrefixPropagator] no signing identity available for: /ndn
1464889745.737547 INFO: [AutoPrefixPropagator] this is a prefix registered by some hub: /localhop/nfd
1464889745.737721 INFO: [AutoPrefixPropagator] redo 0 propagations when new Hub connectivity is built.
1464889798.203894 INFO: [AutoPrefixPropagator] no signing identity available for: /localhop/ndn-autoconf/hub


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

From tteixeira at engin.umass.edu  Fri Jun  3 11:50:17 2016
From: tteixeira at engin.umass.edu (Thiago Teixeira)
Date: Fri, 3 Jun 2016 18:50:17 +0000
Subject: [Nfd-dev] nfd-start yield nothing after fresh installation
In-Reply-To: <57518d8b.d618620a.6432e.37b4@mx.google.com>
References: <41E7DF15B39B5C46BF24C9545D39304C2AD9B696@oit-ex2010-mb1>
	<57518d8b.d618620a.6432e.37b4@mx.google.com>
Message-ID: <41E7DF15B39B5C46BF24C9545D39304C2AD9BD3C@oit-ex2010-mb1>

Hi Junxiao,

Thanks for your email. Please find the output below. Is that what I should expect?

$ which nfd
/usr/local/bin/nfd

$ ldd /usr/local/bin/nfd
                linux-vdso.so.1 =>  (0x00007fff62dfe000)
                libboost_system.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_system.so.1.54.0 (0x00007f36cb9e9000)
                libboost_program_options.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_program_options.so.1.54.0 (0x00007f36cb77b000)
                libboost_thread.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.54.0 (0x00007f36cb564000)
                libboost_log.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_log.so.1.54.0 (0x00007f36cb2a0000)
                libndn-cxx.so.0.4.1 => /usr/local/lib/libndn-cxx.so.0.4.1 (0x00007f36cad97000)
                libboost_filesystem.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.54.0 (0x00007f36cab80000)
                libcrypto++.so.9 => /usr/lib/libcrypto++.so.9 (0x00007f36ca4b5000)
                libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f36ca297000)
                libpcap.so.0.8 => /usr/lib/x86_64-linux-gnu/libpcap.so.0.8 (0x00007f36ca058000)
                libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f36c9d54000)
                libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f36c9a4e000)
                libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f36c9837000)
                libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f36c9472000)
                librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f36c926a000)
                /lib64/ld-linux-x86-64.so.2 (0x00007f36cbbfb000)
                libboost_regex.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_regex.so.1.54.0 (0x00007f36c8f62000)
                libboost_chrono.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_chrono.so.1.54.0 (0x00007f36c8d5b000)
                libboost_random.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_random.so.1.54.0 (0x00007f36c8b57000)
                libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x00007f36c889e000)
                libicuuc.so.52 => /usr/lib/x86_64-linux-gnu/libicuuc.so.52 (0x00007f36c8525000)
                libicui18n.so.52 => /usr/lib/x86_64-linux-gnu/libicui18n.so.52 (0x00007f36c811d000)
                libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f36c7f19000)
                libicudata.so.52 => /usr/lib/x86_64-linux-gnu/libicudata.so.52 (0x00007f36c66ab000)

Rgds,
Thiago

From: Junxiao Shi [mailto:shijunxiao at email.arizona.edu]
Sent: Friday, June 3, 2016 10:01 AM
To: Thiago Teixeira <tteixeira at engin.umass.edu>; nfd-dev at lists.cs.ucla.edu
Subject: RE: [Nfd-dev] nfd-start yield nothing after fresh installation

Hi Thiago

I suspect there?s a library ABI mismatch. It?s most likely to happen if ndn-cxx and NFD are not installed together.
You may check this possibility with:

1.       find where is your NFD binary with which nfd

2.       check whether libraries are linked correctly with ldd /usr/bin/nfd (use the nfd binary path found in step1)

Yours, Junxiao

From: Thiago Teixeira<mailto:tteixeira at engin.umass.edu>
Sent: Thursday, June 2, 2016 03:30
To: nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>
Subject: [Nfd-dev] nfd-start yield nothing after fresh installation

Hi all,

I installed the NFD 0.4.1-21 binaries on two Ubuntu 14-64 bits and everything went well. The two machines are on the same subnet 10.10.1.0/24.
When I run $ nfd-start I get the following message: NFD is already running?

So I run $ nfdc register /ndn udp://10.10.1.1 and I should get the Successful? message, but I get nothing.
nfd-status yields nothing too.
I tried nfd-stop > nfd-start and nothing shows up.

I searched on the mailing list and couldn?t find anything.

Do you have any suggestions or tests to do?

Thanks,
Thiago


PS: There?s a typo in the building documentation instructions. It should be ./waf doxygen instead of doxgyen
http://named-data.net/doc/NFD/current/INSTALL.html#building-documentation

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

From shijunxiao at email.arizona.edu  Fri Jun  3 12:14:32 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Fri, 3 Jun 2016 12:14:32 -0700
Subject: [Nfd-dev] nfd-start yield nothing after fresh installation
In-Reply-To: <CAOFH+OY1W13badAfz9AWVeGE3GVCRM-qn7kCKk9YNmYsrQyzFg@mail.gmail.com>
References: <41E7DF15B39B5C46BF24C9545D39304C2AD9B696@oit-ex2010-mb1>
	<57518d8b.d618620a.6432e.37b4@mx.google.com>
	<41E7DF15B39B5C46BF24C9545D39304C2AD9BD3C@oit-ex2010-mb1>
	<CAOFH+OY1W13badAfz9AWVeGE3GVCRM-qn7kCKk9YNmYsrQyzFg@mail.gmail.com>
Message-ID: <CAOFH+OYm_zg8HUymxARizzFvz91BxKqrjX4L9mR643zUptRacw@mail.gmail.com>

There's no obvious error in this output.
If ndn-cxx and NFD are compiled at the same time (either from a newly
cloned repository, or ./waf distclean has been execute before compiling
NFD), this shall eliminate library ABI mismatch problem.
On Jun 3, 2016 11:50 AM, "Thiago Teixeira" <tteixeira at engin.umass.edu>
wrote:

Hi Junxiao,



Thanks for your email. Please find the output below. Is that what I should
expect?



$ which nfd

/usr/local/bin/nfd

$ ldd /usr/local/bin/nfd

                linux-vdso.so.1 =>  (0x00007fff62dfe000)

                libboost_system.so.1.54.0 =>
/usr/lib/x86_64-linux-gnu/libboost_system.so.1.54.0 (0x00007f36cb9e9000)

                libboost_program_options.so.1.54.0 =>
/usr/lib/x86_64-linux-gnu/libboost_program_options.so.1.54.0
(0x00007f36cb77b000)

                libboost_thread.so.1.54.0 =>
/usr/lib/x86_64-linux-gnu/libboost_thread.so.1.54.0 (0x00007f36cb564000)

                libboost_log.so.1.54.0 =>
/usr/lib/x86_64-linux-gnu/libboost_log.so.1.54.0 (0x00007f36cb2a0000)

                libndn-cxx.so.0.4.1 => /usr/local/lib/libndn-cxx.so.0.4.1
(0x00007f36cad97000)

                libboost_filesystem.so.1.54.0 =>
/usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.54.0 (0x00007f36cab80000)

                libcrypto++.so.9 => /usr/lib/libcrypto++.so.9
(0x00007f36ca4b5000)

                libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007f36ca297000)

                libpcap.so.0.8 => /usr/lib/x86_64-linux-gnu/libpcap.so.0.8
(0x00007f36ca058000)

                libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(0x00007f36c9d54000)

                libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
(0x00007f36c9a4e000)

                libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x00007f36c9837000)

                libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
(0x00007f36c9472000)

                librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1
(0x00007f36c926a000)

                /lib64/ld-linux-x86-64.so.2 (0x00007f36cbbfb000)

                libboost_regex.so.1.54.0 =>
/usr/lib/x86_64-linux-gnu/libboost_regex.so.1.54.0 (0x00007f36c8f62000)

                libboost_chrono.so.1.54.0 =>
/usr/lib/x86_64-linux-gnu/libboost_chrono.so.1.54.0 (0x00007f36c8d5b000)

                libboost_random.so.1.54.0 =>
/usr/lib/x86_64-linux-gnu/libboost_random.so.1.54.0 (0x00007f36c8b57000)

                libsqlite3.so.0 =>
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x00007f36c889e000)

                libicuuc.so.52 => /usr/lib/x86_64-linux-gnu/libicuuc.so.52
(0x00007f36c8525000)

                libicui18n.so.52 =>
/usr/lib/x86_64-linux-gnu/libicui18n.so.52 (0x00007f36c811d000)

                libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
(0x00007f36c7f19000)

                libicudata.so.52 =>
/usr/lib/x86_64-linux-gnu/libicudata.so.52 (0x00007f36c66ab000)



Rgds,

Thiago



*From:* Junxiao Shi [mailto:shijunxiao at email.arizona.edu]
*Sent:* Friday, June 3, 2016 10:01 AM
*To:* Thiago Teixeira <tteixeira at engin.umass.edu>; nfd-dev at lists.cs.ucla.edu
*Subject:* RE: [Nfd-dev] nfd-start yield nothing after fresh installation



Hi Thiago



I suspect there?s a library ABI mismatch. It?s most likely to happen if
ndn-cxx and NFD are not installed together.

You may check this possibility with:

1.       find where is your NFD binary with which nfd

2.       check whether libraries are linked correctly with ldd /usr/bin/nfd
(use the nfd binary path found in step1)



Yours, Junxiao



*From: *Thiago Teixeira <tteixeira at engin.umass.edu>
*Sent: *Thursday, June 2, 2016 03:30
*To: *nfd-dev at lists.cs.ucla.edu
*Subject: *[Nfd-dev] nfd-start yield nothing after fresh installation



Hi all,



I installed the NFD 0.4.1-21 binaries on two Ubuntu 14-64 bits and
everything went well. The two machines are on the same subnet 10.10.1.0/24.

When I run *$ nfd-start* I get the following message: *NFD is already
running?*



So I run *$ nfdc register /ndn udp://10.10.1.1 <http://10.10.1.1>* and I
should get the *Successful?* message, but I get nothing.

*nfd-status* yields nothing too.

I tried *nfd-stop* > *nfd-start* and nothing shows up.



I searched on the mailing list and couldn?t find anything.



Do you have any suggestions or tests to do?



Thanks,

Thiago



PS: There?s a typo in the building documentation instructions. It should be
./waf doxygen instead of doxgyen

http://named-data.net/doc/NFD/current/INSTALL.html#building-documentation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160603/78d088d5/attachment.html>

From tteixeira at engin.umass.edu  Mon Jun  6 08:16:13 2016
From: tteixeira at engin.umass.edu (Thiago Teixeira)
Date: Mon, 6 Jun 2016 15:16:13 +0000
Subject: [Nfd-dev] nfd-start yield nothing after fresh installation
In-Reply-To: <CAOFH+OYm_zg8HUymxARizzFvz91BxKqrjX4L9mR643zUptRacw@mail.gmail.com>
References: <41E7DF15B39B5C46BF24C9545D39304C2AD9B696@oit-ex2010-mb1>
	<57518d8b.d618620a.6432e.37b4@mx.google.com>
	<41E7DF15B39B5C46BF24C9545D39304C2AD9BD3C@oit-ex2010-mb1>
	<CAOFH+OY1W13badAfz9AWVeGE3GVCRM-qn7kCKk9YNmYsrQyzFg@mail.gmail.com>
	<CAOFH+OYm_zg8HUymxARizzFvz91BxKqrjX4L9mR643zUptRacw@mail.gmail.com>
Message-ID: <41E7DF15B39B5C46BF24C9545D39304C2AD9C36D@oit-ex2010-mb1>

Hi Junxiao,

I installed NFD and ndn-cxx on three new Ubuntu 14.04 LTS VMs using the following:

?         Installed pre-requisites

?         Clone ndn-cxx and NFD repos

?         On ndn-cxx directory:

o   ./waf configure ?with-examples

o   ./waf

o   sudo ./waf install

o   sudo ldconfig

?         On NFD directory:

o   ./waf configure

o   ./waf

o   sudo ./waf install

On two of the three VMs, when I run $ nfd-status it works. On the third one it yielded nothing.
So I ran $ ./waf distclean on NFD directory and repeated configure, waf, install.

nfd-status still yields nothing. Do you have any other suggestion?

Thanks for your help,
Thiago


From: Junxiao Shi [mailto:shijunxiao at email.arizona.edu]
Sent: Friday, June 3, 2016 3:15 PM
To: Thiago Teixeira <tteixeira at engin.umass.edu>
Cc: <nfd-dev at lists.cs.ucla.edu> <nfd-dev at lists.cs.ucla.edu>
Subject: RE: [Nfd-dev] nfd-start yield nothing after fresh installation


There's no obvious error in this output.
If ndn-cxx and NFD are compiled at the same time (either from a newly cloned repository, or ./waf distclean has been execute before compiling NFD), this shall eliminate library ABI mismatch problem.
On Jun 3, 2016 11:50 AM, "Thiago Teixeira" <tteixeira at engin.umass.edu<mailto:tteixeira at engin.umass.edu>> wrote:
Hi Junxiao,

Thanks for your email. Please find the output below. Is that what I should expect?

$ which nfd
/usr/local/bin/nfd
$ ldd /usr/local/bin/nfd
                linux-vdso.so.1 =>  (0x00007fff62dfe000)
                libboost_system.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_system.so.1.54.0 (0x00007f36cb9e9000)
                libboost_program_options.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_program_options.so.1.54.0 (0x00007f36cb77b000)
                libboost_thread.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.54.0 (0x00007f36cb564000)
                libboost_log.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_log.so.1.54.0 (0x00007f36cb2a0000)
                libndn-cxx.so.0.4.1 => /usr/local/lib/libndn-cxx.so.0.4.1 (0x00007f36cad97000)
                libboost_filesystem.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.54.0 (0x00007f36cab80000)
                libcrypto++.so.9 => /usr/lib/libcrypto++.so.9 (0x00007f36ca4b5000)
                libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f36ca297000)
                libpcap.so.0.8 => /usr/lib/x86_64-linux-gnu/libpcap.so.0.8 (0x00007f36ca058000)
                libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f36c9d54000)
                libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f36c9a4e000)
                libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f36c9837000)
                libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f36c9472000)
                librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f36c926a000)
                /lib64/ld-linux-x86-64.so.2 (0x00007f36cbbfb000)
                libboost_regex.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_regex.so.1.54.0 (0x00007f36c8f62000)
                libboost_chrono.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_chrono.so.1.54.0 (0x00007f36c8d5b000)
                libboost_random.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_random.so.1.54.0 (0x00007f36c8b57000)
                libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x00007f36c889e000)
                libicuuc.so.52 => /usr/lib/x86_64-linux-gnu/libicuuc.so.52 (0x00007f36c8525000)
                libicui18n.so.52 => /usr/lib/x86_64-linux-gnu/libicui18n.so.52 (0x00007f36c811d000)
                libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f36c7f19000)
                libicudata.so.52 => /usr/lib/x86_64-linux-gnu/libicudata.so.52 (0x00007f36c66ab000)

Rgds,
Thiago

From: Junxiao Shi [mailto:shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>]
Sent: Friday, June 3, 2016 10:01 AM
To: Thiago Teixeira <tteixeira at engin.umass.edu<mailto:tteixeira at engin.umass.edu>>; nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>
Subject: RE: [Nfd-dev] nfd-start yield nothing after fresh installation

Hi Thiago

I suspect there?s a library ABI mismatch. It?s most likely to happen if ndn-cxx and NFD are not installed together.
You may check this possibility with:

1.       find where is your NFD binary with which nfd

2.       check whether libraries are linked correctly with ldd /usr/bin/nfd (use the nfd binary path found in step1)

Yours, Junxiao

From: Thiago Teixeira<mailto:tteixeira at engin.umass.edu>
Sent: Thursday, June 2, 2016 03:30
To: nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>
Subject: [Nfd-dev] nfd-start yield nothing after fresh installation

Hi all,

I installed the NFD 0.4.1-21 binaries on two Ubuntu 14-64 bits and everything went well. The two machines are on the same subnet 10.10.1.0/24<http://10.10.1.0/24>.
When I run $ nfd-start I get the following message: NFD is already running?

So I run $ nfdc register /ndn udp://10.10.1.1<http://10.10.1.1> and I should get the Successful? message, but I get nothing.
nfd-status yields nothing too.
I tried nfd-stop > nfd-start and nothing shows up.

I searched on the mailing list and couldn?t find anything.

Do you have any suggestions or tests to do?

Thanks,
Thiago


PS: There?s a typo in the building documentation instructions. It should be ./waf doxygen instead of doxgyen
http://named-data.net/doc/NFD/current/INSTALL.html#building-documentation

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

From shijunxiao at email.arizona.edu  Mon Jun  6 19:07:01 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Mon, 6 Jun 2016 19:07:01 -0700
Subject: [Nfd-dev] ndnsec import asks for passphrase twice
Message-ID: <CAOFH+OYZW6EY-tPwN-qaxk2y2dLm43vaOHVGrWAMfxJz4opMXw@mail.gmail.com>

Dear folks

ndnsec import command is used to import a previously exported private key.
The private key is protected by a passphrase so the operator is prompted to
enter it.
I notice that this command, similar to ndnsec export, asks for the
passphrase twice.

vagrant at m0212:~$ ndnsec import -p mykey.ndnkey
Passphrase for the private key:
Confirm:

Is there a particular design rationale behind this, or is it a UX bug?

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

From nfd-call-notification at mail1.yoursunny.com  Tue Jun  7 10:00:02 2016
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Tue, 7 Jun 2016 10:00:02 -0700
Subject: [Nfd-dev] NFD call 20160607
Message-ID: <201606071700.u57H021O020205@lectura.cs.arizona.edu>

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

From aa at CS.UCLA.EDU  Tue Jun  7 10:52:56 2016
From: aa at CS.UCLA.EDU (Alex Afanasyev)
Date: Tue, 7 Jun 2016 10:52:56 -0700
Subject: [Nfd-dev] ndnsec import asks for passphrase twice
In-Reply-To: <CAOFH+OYZW6EY-tPwN-qaxk2y2dLm43vaOHVGrWAMfxJz4opMXw@mail.gmail.com>
References: <CAOFH+OYZW6EY-tPwN-qaxk2y2dLm43vaOHVGrWAMfxJz4opMXw@mail.gmail.com>
Message-ID: <1BB8D467-CEA1-48C6-8C3F-7AC920A19B36@cs.ucla.edu>


> On Jun 6, 2016, at 7:07 PM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:
> 
> Dear folks
> 
> ndnsec import command is used to import a previously exported private key.
> The private key is protected by a passphrase so the operator is prompted to enter it.
> I notice that this command, similar to ndnsec export, asks for the passphrase twice.
> 
> vagrant at m0212:~$ ndnsec import -p mykey.ndnkey
> Passphrase for the private key:
> Confirm:
> 
> Is there a particular design rationale behind this, or is it a UX bug?

I also noticed this.  It is a UX bug.

---
Alex

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160607/587e8c11/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/20160607/587e8c11/attachment.bin>

From lixia at CS.UCLA.EDU  Tue Jun  7 17:34:47 2016
From: lixia at CS.UCLA.EDU (Lixia Zhang)
Date: Tue, 7 Jun 2016 17:34:47 -0700
Subject: [Nfd-dev] ndnsec import asks for passphrase twice
In-Reply-To: <1BB8D467-CEA1-48C6-8C3F-7AC920A19B36@cs.ucla.edu>
References: <CAOFH+OYZW6EY-tPwN-qaxk2y2dLm43vaOHVGrWAMfxJz4opMXw@mail.gmail.com>
	<1BB8D467-CEA1-48C6-8C3F-7AC920A19B36@cs.ucla.edu>
Message-ID: <BEFC35B8-2E5E-41BE-B626-97CB664EC524@cs.ucla.edu>


> On Jun 7, 2016, at 10:52 AM, Alex Afanasyev <aa at CS.UCLA.EDU> wrote:
> 
> 
>> On Jun 6, 2016, at 7:07 PM, Junxiao Shi <shijunxiao at email.arizona.edu <mailto:shijunxiao at email.arizona.edu>> wrote:
>> 
>> Dear folks
>> 
>> ndnsec import command is used to import a previously exported private key.
>> The private key is protected by a passphrase so the operator is prompted to enter it.
>> I notice that this command, similar to ndnsec export, asks for the passphrase twice.
>> 
>> vagrant at m0212:~$ ndnsec import -p mykey.ndnkey
>> Passphrase for the private key:
>> Confirm:
>> 
>> Is there a particular design rationale behind this, or is it a UX bug?
> 
> I also noticed this.  It is a UX bug.

then I wonder whether there anything that can be done?

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

From shijunxiao at email.arizona.edu  Tue Jun  7 17:39:02 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Tue, 7 Jun 2016 17:39:02 -0700
Subject: [Nfd-dev] ndnsec import asks for passphrase twice
In-Reply-To: <1BB8D467-CEA1-48C6-8C3F-7AC920A19B36@cs.ucla.edu>
References: <CAOFH+OYZW6EY-tPwN-qaxk2y2dLm43vaOHVGrWAMfxJz4opMXw@mail.gmail.com>
	<1BB8D467-CEA1-48C6-8C3F-7AC920A19B36@cs.ucla.edu>
Message-ID: <57576927.1100620a.9541d.ffff9e48@mx.google.com>

Thanks for confirmed.
I have reported this as ndn-cxx Bug 3644.



From: Alex Afanasyev
Sent: Tuesday, June 7, 2016 10:53
To: Junxiao Shi
Cc: nfd-dev at lists.cs.ucla.edu; ndn-sec at lists.cs.ucla.edu
Subject: Re: [Nfd-dev] ndnsec import asks for passphrase twice


On Jun 6, 2016, at 7:07 PM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:

Dear folks

ndnsec import command is used to import a previously exported private key.
The private key is protected by a passphrase so the operator is prompted to enter it.
I notice that this command, similar to ndnsec export, asks for the passphrase twice.

vagrant at m0212:~$ ndnsec import -p mykey.ndnkey
Passphrase for the private key:
Confirm:

Is there a particular design rationale behind this, or is it a UX bug?

I also noticed this. ?It is a UX bug.

---
Alex


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

From aa at CS.UCLA.EDU  Wed Jun  8 10:44:40 2016
From: aa at CS.UCLA.EDU (Alex Afanasyev)
Date: Wed, 8 Jun 2016 10:44:40 -0700
Subject: [Nfd-dev] [CFP] 1st IEEE Workshop on Named Data Networking for
 Challenged Communication Environments (NDN-CCE'2016)
Message-ID: <506C0A1C-A595-4449-9B05-B9054E074F2D@cs.ucla.edu>

=========================================================
CALL FOR PAPERS
1st IEEE Workshop on Named Data Networking for Challenged
Communication Environments (NDN-CCE'2016)

Washington, DC, December 8th 2016

http://www2.mitre.org/public/ndn-cce/
=========================================================

Army tactical networks, first responder communication networks, and
interplanetary networks are several examples of challenging
communication environments that are typically referred to as DIL
(disrupted, intermittently connected, and low bandwidth).
Nevertheless, applications that operate in such environments generate
mission critical data that must be disseminated promptly and reliably,
despite the challenging nature of the communication environment.

Many years of research efforts have been invested into IP-based
communication networks to achieve the above goals, but only resulted
in limited success. The root cause of the difficulties is a
fundamental mismatch between the IP-based communication model and the
challenged environments. The former assumes communications through
established stable infrastructures. It requires the creation and
maintenance of end-to-end connectivity between senders and receivers,
while neither the infrastructure nor end-to-end connectivity exists in
the latter.  The key to solving the problem is to identify a new
communication model that makes effective use of the heterogeneous
network resources of challenged environments, removes dependency on
infrastructure components, and emphasizes data dissemination in lieu
end-to-end connectivity.

Information-Centric Networking (ICN) and Named Data Networking (NDN),
as the most prominent realization of the ICN vision, have emerged in
recent years as promising directions to address the above stated
challenges. By its name, this new networking model focuses on
information (named data) retrieval, instead of reachability between
nodes and locations. Therefore, it can circumvent the lack of
persistent connectivity in challenged environments by focusing on
moving data instead of end-to-end connectivity, utilizing any
connectivity, as it comes into existence, to move data hop-by-hop
towards requesting parties.

This workshop aims to provide a timely venue for all interested
parties to exchange their ideas and initial results in applying the
NDN paradigm to: address the communication needs of mission critical
applications in challenged environments, explore different design
options, and identify design tradeoffs. Topics of interest includes:

- NDN routing for challenged communication environments Supporting
- high assurance NDN applications in challenged communication
- environments Real deployment and case studies of NDN in challenged
- communication environments QoS-aware NDN functionalities for
- challenged communication environments Efficient and effective NDN
- caching policies for challenged communication environments Modeling,
- analysis and characterization of NDN functionalities in challenged
- communication network

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

Submission Deadline:     July 1, 2016, 11:59pm
Acceptance Notification: September 1, 2016
Camera-Ready Submission: October 1, 2016
=========================================================

Sincerely,
  Tamer Refaei (The MITRE Corporation) and Alex Afanasyev (UCLA)
  NDN-CCE Workshop Co-Chairs

-------------- 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/20160608/8ebd0199/attachment.bin>

From tteixeira at engin.umass.edu  Wed Jun  8 14:30:40 2016
From: tteixeira at engin.umass.edu (Thiago Teixeira)
Date: Wed, 8 Jun 2016 21:30:40 +0000
Subject: [Nfd-dev] nfd-start yield nothing after fresh installation
References: <41E7DF15B39B5C46BF24C9545D39304C2AD9B696@oit-ex2010-mb1>
	<57518d8b.d618620a.6432e.37b4@mx.google.com>
	<41E7DF15B39B5C46BF24C9545D39304C2AD9BD3C@oit-ex2010-mb1>
	<CAOFH+OY1W13badAfz9AWVeGE3GVCRM-qn7kCKk9YNmYsrQyzFg@mail.gmail.com>
	<CAOFH+OYm_zg8HUymxARizzFvz91BxKqrjX4L9mR643zUptRacw@mail.gmail.com> 
Message-ID: <41E7DF15B39B5C46BF24C9545D39304C2AD9C9DA@oit-ex2010-mb1>

Hi all,

I created a topology with two nodes, Ubuntu 14.04 LTS on GENI.
After installing ndn-cxx and NFD with maintainer?s version, I start the NFD on both nodes.

When I run ?nfdc register /ndn udp://<IP of other node>? it gives me nothing.
I?ve tried nfd-autoreg:
AUTOREG prefixes:
  /ndn
ALL-FACES-AUTOREG prefixes:
Whitelisted networks:
  0.0.0.0 <-> 255.255.255.255
  :: <-> ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff

nfd-status yields nothing.

I can run the simple application locally (./build/examples/producer and ?/consumer), but I can?t run from the remote node to the local node.

Any advices?

Thanks,
Thiago



From: Thiago Teixeira
Sent: Monday, June 6, 2016 11:16 AM
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] nfd-start yield nothing after fresh installation

Hi Junxiao,

I installed NFD and ndn-cxx on three new Ubuntu 14.04 LTS VMs using the following:

?         Installed pre-requisites

?         Clone ndn-cxx and NFD repos

?         On ndn-cxx directory:

o   ./waf configure ?with-examples

o   ./waf

o   sudo ./waf install

o   sudo ldconfig

?         On NFD directory:

o   ./waf configure

o   ./waf

o   sudo ./waf install

On two of the three VMs, when I run $ nfd-status it works. On the third one it yielded nothing.
So I ran $ ./waf distclean on NFD directory and repeated configure, waf, install.

nfd-status still yields nothing. Do you have any other suggestion?

Thanks for your help,
Thiago


From: Junxiao Shi [mailto:shijunxiao at email.arizona.edu]
Sent: Friday, June 3, 2016 3:15 PM
To: Thiago Teixeira <tteixeira at engin.umass.edu<mailto:tteixeira at engin.umass.edu>>
Cc: <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>> <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: RE: [Nfd-dev] nfd-start yield nothing after fresh installation


There's no obvious error in this output.
If ndn-cxx and NFD are compiled at the same time (either from a newly cloned repository, or ./waf distclean has been execute before compiling NFD), this shall eliminate library ABI mismatch problem.
On Jun 3, 2016 11:50 AM, "Thiago Teixeira" <tteixeira at engin.umass.edu<mailto:tteixeira at engin.umass.edu>> wrote:
Hi Junxiao,

Thanks for your email. Please find the output below. Is that what I should expect?

$ which nfd
/usr/local/bin/nfd
$ ldd /usr/local/bin/nfd
                linux-vdso.so.1 =>  (0x00007fff62dfe000)
                libboost_system.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_system.so.1.54.0 (0x00007f36cb9e9000)
                libboost_program_options.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_program_options.so.1.54.0 (0x00007f36cb77b000)
                libboost_thread.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.54.0 (0x00007f36cb564000)
                libboost_log.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_log.so.1.54.0 (0x00007f36cb2a0000)
                libndn-cxx.so.0.4.1 => /usr/local/lib/libndn-cxx.so.0.4.1 (0x00007f36cad97000)
                libboost_filesystem.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.54.0 (0x00007f36cab80000)
                libcrypto++.so.9 => /usr/lib/libcrypto++.so.9 (0x00007f36ca4b5000)
                libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f36ca297000)
                libpcap.so.0.8 => /usr/lib/x86_64-linux-gnu/libpcap.so.0.8 (0x00007f36ca058000)
                libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f36c9d54000)
                libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f36c9a4e000)
                libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f36c9837000)
                libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f36c9472000)
                librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f36c926a000)
                /lib64/ld-linux-x86-64.so.2 (0x00007f36cbbfb000)
                libboost_regex.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_regex.so.1.54.0 (0x00007f36c8f62000)
                libboost_chrono.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_chrono.so.1.54.0 (0x00007f36c8d5b000)
                libboost_random.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_random.so.1.54.0 (0x00007f36c8b57000)
                libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x00007f36c889e000)
                libicuuc.so.52 => /usr/lib/x86_64-linux-gnu/libicuuc.so.52 (0x00007f36c8525000)
                libicui18n.so.52 => /usr/lib/x86_64-linux-gnu/libicui18n.so.52 (0x00007f36c811d000)
                libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f36c7f19000)
                libicudata.so.52 => /usr/lib/x86_64-linux-gnu/libicudata.so.52 (0x00007f36c66ab000)

Rgds,
Thiago

From: Junxiao Shi [mailto:shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>]
Sent: Friday, June 3, 2016 10:01 AM
To: Thiago Teixeira <tteixeira at engin.umass.edu<mailto:tteixeira at engin.umass.edu>>; nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>
Subject: RE: [Nfd-dev] nfd-start yield nothing after fresh installation

Hi Thiago

I suspect there?s a library ABI mismatch. It?s most likely to happen if ndn-cxx and NFD are not installed together.
You may check this possibility with:

1.       find where is your NFD binary with which nfd

2.       check whether libraries are linked correctly with ldd /usr/bin/nfd (use the nfd binary path found in step1)

Yours, Junxiao

From: Thiago Teixeira<mailto:tteixeira at engin.umass.edu>
Sent: Thursday, June 2, 2016 03:30
To: nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>
Subject: [Nfd-dev] nfd-start yield nothing after fresh installation

Hi all,

I installed the NFD 0.4.1-21 binaries on two Ubuntu 14-64 bits and everything went well. The two machines are on the same subnet 10.10.1.0/24<http://10.10.1.0/24>.
When I run $ nfd-start I get the following message: NFD is already running?

So I run $ nfdc register /ndn udp://10.10.1.1<http://10.10.1.1> and I should get the Successful? message, but I get nothing.
nfd-status yields nothing too.
I tried nfd-stop > nfd-start and nothing shows up.

I searched on the mailing list and couldn?t find anything.

Do you have any suggestions or tests to do?

Thanks,
Thiago


PS: There?s a typo in the building documentation instructions. It should be ./waf doxygen instead of doxgyen
http://named-data.net/doc/NFD/current/INSTALL.html#building-documentation

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

From Navdeep.Uniyal at neclab.eu  Thu Jun  9 08:20:36 2016
From: Navdeep.Uniyal at neclab.eu (Navdeep Uniyal)
Date: Thu, 9 Jun 2016 15:20:36 +0000
Subject: [Nfd-dev] Video tool for NDN
Message-ID: <15421E67B274CD4AB5F6AEA46A684C3708AC9C6A@PALLENE.office.hd>

Hi all,

Is there any tool to generate and play video over NDN in order to experiment the forwarding strategies. Please help if there is any available.


Best Regards,
Navdeep Uniyal

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

From nfd-call-notification at mail1.yoursunny.com  Thu Jun  9 10:00:02 2016
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Thu, 9 Jun 2016 10:00:02 -0700
Subject: [Nfd-dev] NFD call 20160609
Message-ID: <201606091700.u59H02lV016441@lectura.cs.arizona.edu>

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

From shijunxiao at email.arizona.edu  Thu Jun  9 10:32:31 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Thu, 9 Jun 2016 10:32:31 -0700
Subject: [Nfd-dev] [Ndn-interest] Video tool for NDN
In-Reply-To: <15421E67B274CD4AB5F6AEA46A684C3708AC9C6A@PALLENE.office.hd>
References: <15421E67B274CD4AB5F6AEA46A684C3708AC9C6A@PALLENE.office.hd>
Message-ID: <CAOFH+OYwKTdir3izA3bB9gc3txzgjBLTnsfP-2GD5nFmry0WOA@mail.gmail.com>

Hi Navdeep

Search for ndn-rtc library, and NdnCon application. Both are OSX only,
unfortunately.

Yours, Junxiao
On Jun 9, 2016 8:21 AM, "Navdeep Uniyal" <Navdeep.Uniyal at neclab.eu> wrote:

> Hi all,
>
>
>
> Is there any tool to generate and play video over NDN in order to
> experiment the forwarding strategies. Please help if there is any available.
>
>
>
>
>
> Best Regards,
>
> Navdeep Uniyal
>
>
>
> _______________________________________________
> 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/20160609/1096dcec/attachment.html>

From shijunxiao at email.arizona.edu  Mon Jun 13 09:31:18 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Mon, 13 Jun 2016 09:31:18 -0700
Subject: [Nfd-dev] 1-to-Many NDN-RTC test and hub strategy
In-Reply-To: <CAOFH+ObxW9Ye4ymzavbPvwc8mcjzDtCMsPRrSc12maq+8RRQXw@mail.gmail.com>
References: <CAOFH+OZL6JLoQZwenACp2a32ruucRbauPM_HuVTTxvzV+0LE0g@mail.gmail.com>
	<5CDE7BF2-2533-407C-A546-3C2A3241C3F7@remap.ucla.edu>
	<059000c3-9a62-47cc-a372-b06a1415a4df@emhub4.ad.ucla.edu>
	<CAOFH+ObxW9Ye4ymzavbPvwc8mcjzDtCMsPRrSc12maq+8RRQXw@mail.gmail.com>
Message-ID: <CAOFH+OaFiuu52Hjx113vDUc9jCLTgiHJ40NB_rAe5=St+Q42FA@mail.gmail.com>

Hi Peter

A patch has been made a week ago <http://gerrit.named-data.net/2876>.
Can you test it according to #3642-9
<http://redmine.named-data.net/issues/3642#note-9>, and post the result on
Redmine?


I also request a code review for this patch from anyone who knows NFD
forwarding.

Yours, Junxiao

On Thu, Jun 2, 2016 at 3:55 PM, Junxiao Shi <shijunxiao at email.arizona.edu>
wrote:

> Hi Peter
>
> Thanks for the trace.
> This indicates an implementation bug in forwarding pipelines.
> http://redmine.named-data.net/issues/3642
> I'll review relevant code and try to get this fixed in two weeks.
>
> #3642 note-1 also identifies two secondary issues in ndncon or ndn-cpp.
> You can try to confirm these and report them to relevant issue trackers
> separately.
>
> Yours, Junxiao
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160613/0c002fd4/attachment.html>

From shijunxiao at email.arizona.edu  Mon Jun 13 11:01:14 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Mon, 13 Jun 2016 11:01:14 -0700
Subject: [Nfd-dev] 1-to-Many NDN-RTC test and hub strategy
In-Reply-To: <5C988871-3C4A-4943-96BF-F37A4C66EF1C@remap.ucla.edu>
References: <CAOFH+OZL6JLoQZwenACp2a32ruucRbauPM_HuVTTxvzV+0LE0g@mail.gmail.com>
	<5CDE7BF2-2533-407C-A546-3C2A3241C3F7@remap.ucla.edu>
	<059000c3-9a62-47cc-a372-b06a1415a4df@emhub4.ad.ucla.edu>
	<CAOFH+ObxW9Ye4ymzavbPvwc8mcjzDtCMsPRrSc12maq+8RRQXw@mail.gmail.com>
	<CAOFH+OaFiuu52Hjx113vDUc9jCLTgiHJ40NB_rAe5=St+Q42FA@mail.gmail.com>
	<5C988871-3C4A-4943-96BF-F37A4C66EF1C@remap.ucla.edu>
Message-ID: <575ef4e9.184f620a.c0da6.ffffb61d@mx.google.com>

Hi Peter

You may check out a commit from Gerrit by following step 1-3 on the procedure given in http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2015-June/001147.html
Afterwards, do a ./waf distclean, and recompile.

Yours, Junxiao

From: Gusev, Peter
Sent: Monday, June 13, 2016 10:34
To: Junxiao Shi
Subject: Re: [Nfd-dev] 1-to-Many NDN-RTC test and hub strategy

Hi Junxiao, 

I have little experience with gerrit. Can you please give me exact steps on how to merge these changes into my NFD git repo?

Thanks,?

--?
Peter Gusev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160613/56bc35ff/attachment.html>

From peter at remap.UCLA.edu  Mon Jun 13 12:22:12 2016
From: peter at remap.UCLA.edu (Gusev, Peter)
Date: Mon, 13 Jun 2016 19:22:12 +0000
Subject: [Nfd-dev] [ndn] NDN Seminar: Practical Congestion Control for
 NDN
In-Reply-To: <10E77B45-9387-47C1-A7A4-2CD624738900@email.arizona.edu>
References: <05BCCCCC-4400-4305-8AE5-DE894BF1A7F1@cs.ucla.edu>
	<430E1CDF-ED12-45C9-BD97-125049FE475E@cs.ucla.edu>
	<2A94D772-4EE7-42C0-B030-C0A53E9E164E@cs.ucla.edu>
	<AE1669BA-A316-49C9-A0D7-D73A1CC43680@cs.ucla.edu>
	<574d1575.c451620a.7e7be.ffff9da5@mx.google.com>
	<AA42FA39-A8A8-4039-8A24-C4BD2D9050D4@cs.ucla.edu>
	<48B3ADE0-B913-466B-8A28-D1D8AF2D12D7@email.arizona.edu>
	<1adb5db8-f384-4127-8afc-3d2b710860d7@EMHUB5.ad.ucla.edu>
	<68A7E1B1-EAFD-441B-8568-AD55070ECAE2@email.arizona.edu>
	<24F5D101-226B-40F5-B26E-86E4E96CF9D6@wustl.edu>
	<1B24FB64-4355-41D8-92E1-E01AD44A3391@email.arizona.edu>
	<A84C3ECF-B38B-4397-9434-D77F7F39102B@remap.ucla.edu>
	<A2CC6739-5421-420A-980E-76A0E6BE617E@wustl.edu>
	<FCFC34D7-1B50-4E4F-84E0-AA9B521D84AA@remap.ucla.edu>
	<DA2B72F9-D885-4226-A319-56BB06DEEF2E@wustl.edu>
	<A959E4EF-D6AE-4507-905C-4425FC732C0E@remap.ucla.edu>
	<BC70558F-D6AF-4B48-B27D-AE8F396B3895@wustl.edu>
	<23D42CE8-3C2B-4FFD-AF0E-073CE9083549@remap.ucla.edu>
	<864D1969-3A81-4015-B533-C81064A41A7E@wustl.edu>
	<E78AAD90-536C-4166-B4E9-09F8A937EB23@wustl.edu>
	<DE2095E2-8C6D-43A8-8AF0-7D90D51ED085@remap.ucla.edu>
	<7FBAC07E-BB34-4884-93A7-C0181059522C@wustl.edu>
	<AB89F0D5-1968-4530-A1C2-FB946BCB2F51@wustl.edu>
	<228C3BBD-7859-41FF-B151-0F237CF742F5@remap.ucla.edu>
	<6c75cadf-f1cf-4c22-aeaf-617d102e4e9b@EMHUB5.ad.ucla.edu>
	<10E77B45-9387-47C1-A7A4-2CD624738900@email.arizona.edu>
Message-ID: <F7B7BE37-D017-471C-8CA3-162F4A038F7B@remap.ucla.edu>

Hi Junxiao,

I generated a cert request on freeculture like this:

	$ ndnsec-keygen /ndn/edu/ucla/remap/peter/freeculture > freeculture.pub

Then, I signed it on my machine:

	$ ndnsec-certgen -N freeculture -p /ndn/edu/ucla/remap/peter -r freeculture.pub > freeculture.signed

I sent freeculture.signed back to freeculture machine, as long as my certificate (previously dumped):

	$ ndnsec-cert-dump /ndn/edu/ucla/remap/peter > peter.cert

Finally, I installed both certificates on freeculture machine:

$ ndnsec-install-cert peter.cert
$ ndnsec-install-cert freeculture.signed

Both ended successfully. I then switched default identity to /ndn/edu/ucla/remap/peter/freeculture on freeculture machine:

$ ndnsec set-default /ndn/edu/ucla/remap/peter/freeculture

However, I don?t see connectivity to the testbed after running ndn-autoconfig. 

Was the above sequence correct?

Thanks, 

-- 
Peter Gusev

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

Software Engineer/Programmer Analyst @ REMAP UCLA

Video streaming/ICN networks/Creative Development

> On Jun 2, 2016, at 12:05 PM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:
> 
> Hi Peter
> 
> This is an unsupported configuration. Certificates can only be requested through ndncert web app, and it?s always tied to your email.
> 
> Yours, Junxiao
> 
>> On Jun 2, 2016, at 12:02 PM, Gusev, Peter <peter at remap.ucla.edu> wrote:
>> 
>> hi Junxiao,
>> 
>> I generated certs for freeculture and confbridge and signed them on REMAP hub like this:
>> 
>> $ ndnsec-certgen -N confbridge -p /ndn/edu/ucla/remap -r confbridge.pub
>> 
>> I installed them on corresponding machines, however it seems not working yet.
>> Is the above command correct?
>> 
>> Thanks, 
>> 
>> -- 
>> Peter Gusev
>> 
>> peter at remap.ucla.edu
>> +1 213 5872748
>> peetonn_ (skype)
>> 
>> Software Engineer/Programmer Analyst @ REMAP UCLA
>> 
>> Video streaming/ICN networks/Creative Development
>> 
>>> On Jun 2, 2016, at 11:13 AM, Peter Gusev <peter at remap.ucla.edu> wrote:
>>> 
>>> no, i?m not publishing.
>>> 
>>> 
>>> Junxiao, I?m generating a certificate for confbridge. But I?m not sure I?ll make it in time for the Seminar.
>>> 
>>> Thanks, 
>>> 
>>> -- 
>>> Peter Gusev
>>> 
>>> peter at remap.ucla.edu
>>> +1 213 5872748
>>> peetonn_ (skype)
>>> 
>>> Software Engineer/Programmer Analyst @ REMAP UCLA
>>> 
>>> Video streaming/ICN networks/Creative Development
> 




From shijunxiao at email.arizona.edu  Mon Jun 13 21:53:32 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Mon, 13 Jun 2016 21:53:32 -0700
Subject: [Nfd-dev] [ndn] NDN Seminar: Practical Congestion Control for
 NDN
In-Reply-To: <9b807ce7-8878-4d80-a3d7-48618899ff1f@emhub4.ad.ucla.edu>
References: <05BCCCCC-4400-4305-8AE5-DE894BF1A7F1@cs.ucla.edu>
	<430E1CDF-ED12-45C9-BD97-125049FE475E@cs.ucla.edu>
	<2A94D772-4EE7-42C0-B030-C0A53E9E164E@cs.ucla.edu>
	<AE1669BA-A316-49C9-A0D7-D73A1CC43680@cs.ucla.edu>
	<574d1575.c451620a.7e7be.ffff9da5@mx.google.com>
	<AA42FA39-A8A8-4039-8A24-C4BD2D9050D4@cs.ucla.edu>
	<48B3ADE0-B913-466B-8A28-D1D8AF2D12D7@email.arizona.edu>
	<1adb5db8-f384-4127-8afc-3d2b710860d7@EMHUB5.ad.ucla.edu>
	<68A7E1B1-EAFD-441B-8568-AD55070ECAE2@email.arizona.edu>
	<24F5D101-226B-40F5-B26E-86E4E96CF9D6@wustl.edu>
	<1B24FB64-4355-41D8-92E1-E01AD44A3391@email.arizona.edu>
	<A84C3ECF-B38B-4397-9434-D77F7F39102B@remap.ucla.edu>
	<A2CC6739-5421-420A-980E-76A0E6BE617E@wustl.edu>
	<FCFC34D7-1B50-4E4F-84E0-AA9B521D84AA@remap.ucla.edu>
	<DA2B72F9-D885-4226-A319-56BB06DEEF2E@wustl.edu>
	<A959E4EF-D6AE-4507-905C-4425FC732C0E@remap.ucla.edu>
	<BC70558F-D6AF-4B48-B27D-AE8F396B3895@wustl.edu>
	<23D42CE8-3C2B-4FFD-AF0E-073CE9083549@remap.ucla.edu>
	<864D1969-3A81-4015-B533-C81064A41A7E@wustl.edu>
	<E78AAD90-536C-4166-B4E9-09F8A937EB23@wustl.edu>
	<DE2095E2-8C6D-43A8-8AF0-7D90D51ED085@remap.ucla.edu>
	<7FBAC07E-BB34-4884-93A7-C0181059522C@wustl.edu>
	<AB89F0D5-1968-4530-A1C2-FB946BCB2F51@wustl.edu>
	<228C3BBD-7859-41FF-B151-0F237CF742F5@remap.ucla.edu>
	<6c75cadf-f1cf-4c22-aeaf-617d102e4e9b@EMHUB5.ad.ucla.edu>
	<10E77B45-9387-47C1-A7A4-2CD624738900@email.arizona.edu>
	<9b807ce7-8878-4d80-a3d7-48618899ff1f@emhub4.ad.ucla.edu>
Message-ID: <CAOFH+ObpY8gpvomnanZRF+dFGbToiiWyM4vr_PWnFQbjyP2A2g@mail.gmail.com>

These sequence are incorrect. You cannot use any certificate other than the
one directly requested from ndncert.
On Jun 13, 2016 12:22 PM, "Gusev, Peter" <peter at remap.ucla.edu> wrote:

> Hi Junxiao,
>
> I generated a cert request on freeculture like this:
>
>         $ ndnsec-keygen /ndn/edu/ucla/remap/peter/freeculture >
> freeculture.pub
>
> Then, I signed it on my machine:
>
>         $ ndnsec-certgen -N freeculture -p /ndn/edu/ucla/remap/peter -r
> freeculture.pub > freeculture.signed
>
> I sent freeculture.signed back to freeculture machine, as long as my
> certificate (previously dumped):
>
>         $ ndnsec-cert-dump /ndn/edu/ucla/remap/peter > peter.cert
>
> Finally, I installed both certificates on freeculture machine:
>
> $ ndnsec-install-cert peter.cert
> $ ndnsec-install-cert freeculture.signed
>
> Both ended successfully. I then switched default identity to
> /ndn/edu/ucla/remap/peter/freeculture on freeculture machine:
>
> $ ndnsec set-default /ndn/edu/ucla/remap/peter/freeculture
>
> However, I don?t see connectivity to the testbed after running
> ndn-autoconfig.
>
> Was the above sequence correct?
>
> Thanks,
>
> --
> Peter Gusev
>
> peter at remap.ucla.edu
> +1 213 5872748
> peetonn_ (skype)
>
> Software Engineer/Programmer Analyst @ REMAP UCLA
>
> Video streaming/ICN networks/Creative Development
>
> > On Jun 2, 2016, at 12:05 PM, Junxiao Shi <shijunxiao at email.arizona.edu>
> wrote:
> >
> > Hi Peter
> >
> > This is an unsupported configuration. Certificates can only be requested
> through ndncert web app, and it?s always tied to your email.
> >
> > Yours, Junxiao
> >
> >> On Jun 2, 2016, at 12:02 PM, Gusev, Peter <peter at remap.ucla.edu> wrote:
> >>
> >> hi Junxiao,
> >>
> >> I generated certs for freeculture and confbridge and signed them on
> REMAP hub like this:
> >>
> >> $ ndnsec-certgen -N confbridge -p /ndn/edu/ucla/remap -r confbridge.pub
> >>
> >> I installed them on corresponding machines, however it seems not
> working yet.
> >> Is the above command correct?
> >>
> >> Thanks,
> >>
> >> --
> >> Peter Gusev
> >>
> >> peter at remap.ucla.edu
> >> +1 213 5872748
> >> peetonn_ (skype)
> >>
> >> Software Engineer/Programmer Analyst @ REMAP UCLA
> >>
> >> Video streaming/ICN networks/Creative Development
> >>
> >>> On Jun 2, 2016, at 11:13 AM, Peter Gusev <peter at remap.ucla.edu> wrote:
> >>>
> >>> no, i?m not publishing.
> >>>
> >>>
> >>> Junxiao, I?m generating a certificate for confbridge. But I?m not sure
> I?ll make it in time for the Seminar.
> >>>
> >>> Thanks,
> >>>
> >>> --
> >>> Peter Gusev
> >>>
> >>> peter at remap.ucla.edu
> >>> +1 213 5872748
> >>> peetonn_ (skype)
> >>>
> >>> Software Engineer/Programmer Analyst @ REMAP UCLA
> >>>
> >>> Video streaming/ICN networks/Creative Development
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160613/bb8c57e7/attachment.html>

From nfd-call-notification at mail1.yoursunny.com  Tue Jun 14 10:00:03 2016
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Tue, 14 Jun 2016 10:00:03 -0700
Subject: [Nfd-dev] NFD call 20160614
Message-ID: <201606141700.u5EH03SQ015004@lectura.cs.arizona.edu>

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

From agawande at memphis.edu  Tue Jun 14 11:13:34 2016
From: agawande at memphis.edu (Ashlesh Gawande (agawande))
Date: Tue, 14 Jun 2016 18:13:34 +0000
Subject: [Nfd-dev] nfd-start yield nothing after fresh installation
In-Reply-To: <41E7DF15B39B5C46BF24C9545D39304C2AD9C9DA@oit-ex2010-mb1>
References: <41E7DF15B39B5C46BF24C9545D39304C2AD9B696@oit-ex2010-mb1>
	<57518d8b.d618620a.6432e.37b4@mx.google.com>
	<41E7DF15B39B5C46BF24C9545D39304C2AD9BD3C@oit-ex2010-mb1>
	<CAOFH+OY1W13badAfz9AWVeGE3GVCRM-qn7kCKk9YNmYsrQyzFg@mail.gmail.com>
	<CAOFH+OYm_zg8HUymxARizzFvz91BxKqrjX4L9mR643zUptRacw@mail.gmail.com>
	,<41E7DF15B39B5C46BF24C9545D39304C2AD9C9DA@oit-ex2010-mb1>
Message-ID: <BN3PR04MB2196A2F6D371D888F5F082BAD9540@BN3PR04MB2196.namprd04.prod.outlook.com>

I was having the same problem in Ubuntu 14.04. nfd-status does not work but I can run NLSR.

nfd-status would not even display an error connecting to the forwarder if NFD was not running.

The only option that worked was nfd-status -h.


I have NFD installed from source in two machines Ubuntu 14.04 and Ubuntu 15.10 (both are VMs).


I did a git pull and updated NFD on both to latest. nfd-status stopped working only on Ubuntu 14.04.

(ndn-cxx version was updated and installed before NFD)


I went back one by one until finally nfd-status worked with this commit:

https://github.com/named-data/NFD/commit/ace83ac9384da037a36695888e829d7337ce36b0


[https://avatars3.githubusercontent.com/u/14133144?v=3&s=200]<https://github.com/named-data/NFD/commit/ace83ac9384da037a36695888e829d7337ce36b0>

tools: display Nack counters in nfd-status ? named-data/NFD at ace83ac<https://github.com/named-data/NFD/commit/ace83ac9384da037a36695888e829d7337ce36b0>
github.com
refs #3569 Change-Id: I59e76d421502417a13efbf088284d278da07bae4


Ashlesh

________________________________
From: Nfd-dev <nfd-dev-bounces at lists.cs.ucla.edu> on behalf of Thiago Teixeira <tteixeira at engin.umass.edu>
Sent: Wednesday, June 8, 2016 4:30:40 PM
To: <nfd-dev at lists.cs.ucla.edu>
Subject: Re: [Nfd-dev] nfd-start yield nothing after fresh installation

Hi all,

I created a topology with two nodes, Ubuntu 14.04 LTS on GENI.
After installing ndn-cxx and NFD with maintainer?s version, I start the NFD on both nodes.

When I run ?nfdc register /ndn udp://<IP of other node>? it gives me nothing.
I?ve tried nfd-autoreg:
AUTOREG prefixes:
  /ndn
ALL-FACES-AUTOREG prefixes:
Whitelisted networks:
  0.0.0.0 <-> 255.255.255.255
  :: <-> ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff

nfd-status yields nothing.

I can run the simple application locally (./build/examples/producer and ?/consumer), but I can?t run from the remote node to the local node.

Any advices?

Thanks,
Thiago



From: Thiago Teixeira
Sent: Monday, June 6, 2016 11:16 AM
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] nfd-start yield nothing after fresh installation

Hi Junxiao,

I installed NFD and ndn-cxx on three new Ubuntu 14.04 LTS VMs using the following:

?         Installed pre-requisites

?         Clone ndn-cxx and NFD repos

?         On ndn-cxx directory:

o   ./waf configure ?with-examples

o   ./waf

o   sudo ./waf install

o   sudo ldconfig

?         On NFD directory:

o   ./waf configure

o   ./waf

o   sudo ./waf install

On two of the three VMs, when I run $ nfd-status it works. On the third one it yielded nothing.
So I ran $ ./waf distclean on NFD directory and repeated configure, waf, install.

nfd-status still yields nothing. Do you have any other suggestion?

Thanks for your help,
Thiago


From: Junxiao Shi [mailto:shijunxiao at email.arizona.edu]
Sent: Friday, June 3, 2016 3:15 PM
To: Thiago Teixeira <tteixeira at engin.umass.edu<mailto:tteixeira at engin.umass.edu>>
Cc: <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>> <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>
Subject: RE: [Nfd-dev] nfd-start yield nothing after fresh installation


There's no obvious error in this output.
If ndn-cxx and NFD are compiled at the same time (either from a newly cloned repository, or ./waf distclean has been execute before compiling NFD), this shall eliminate library ABI mismatch problem.
On Jun 3, 2016 11:50 AM, "Thiago Teixeira" <tteixeira at engin.umass.edu<mailto:tteixeira at engin.umass.edu>> wrote:
Hi Junxiao,

Thanks for your email. Please find the output below. Is that what I should expect?

$ which nfd
/usr/local/bin/nfd
$ ldd /usr/local/bin/nfd
                linux-vdso.so.1 =>  (0x00007fff62dfe000)
                libboost_system.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_system.so.1.54.0 (0x00007f36cb9e9000)
                libboost_program_options.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_program_options.so.1.54.0 (0x00007f36cb77b000)
                libboost_thread.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.54.0 (0x00007f36cb564000)
                libboost_log.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_log.so.1.54.0 (0x00007f36cb2a0000)
                libndn-cxx.so.0.4.1 => /usr/local/lib/libndn-cxx.so.0.4.1 (0x00007f36cad97000)
                libboost_filesystem.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.54.0 (0x00007f36cab80000)
                libcrypto++.so.9 => /usr/lib/libcrypto++.so.9 (0x00007f36ca4b5000)
                libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f36ca297000)
                libpcap.so.0.8 => /usr/lib/x86_64-linux-gnu/libpcap.so.0.8 (0x00007f36ca058000)
                libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f36c9d54000)
                libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f36c9a4e000)
                libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f36c9837000)
                libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f36c9472000)
                librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f36c926a000)
                /lib64/ld-linux-x86-64.so.2 (0x00007f36cbbfb000)
                libboost_regex.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_regex.so.1.54.0 (0x00007f36c8f62000)
                libboost_chrono.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_chrono.so.1.54.0 (0x00007f36c8d5b000)
                libboost_random.so.1.54.0 => /usr/lib/x86_64-linux-gnu/libboost_random.so.1.54.0 (0x00007f36c8b57000)
                libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x00007f36c889e000)
                libicuuc.so.52 => /usr/lib/x86_64-linux-gnu/libicuuc.so.52 (0x00007f36c8525000)
                libicui18n.so.52 => /usr/lib/x86_64-linux-gnu/libicui18n.so.52 (0x00007f36c811d000)
                libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f36c7f19000)
                libicudata.so.52 => /usr/lib/x86_64-linux-gnu/libicudata.so.52 (0x00007f36c66ab000)

Rgds,
Thiago

From: Junxiao Shi [mailto:shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>]
Sent: Friday, June 3, 2016 10:01 AM
To: Thiago Teixeira <tteixeira at engin.umass.edu<mailto:tteixeira at engin.umass.edu>>; nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>
Subject: RE: [Nfd-dev] nfd-start yield nothing after fresh installation

Hi Thiago

I suspect there?s a library ABI mismatch. It?s most likely to happen if ndn-cxx and NFD are not installed together.
You may check this possibility with:

1.       find where is your NFD binary with which nfd

2.       check whether libraries are linked correctly with ldd /usr/bin/nfd (use the nfd binary path found in step1)

Yours, Junxiao

From: Thiago Teixeira<mailto:tteixeira at engin.umass.edu>
Sent: Thursday, June 2, 2016 03:30
To: nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>
Subject: [Nfd-dev] nfd-start yield nothing after fresh installation

Hi all,

I installed the NFD 0.4.1-21 binaries on two Ubuntu 14-64 bits and everything went well. The two machines are on the same subnet 10.10.1.0/24<http://10.10.1.0/24>.
When I run $ nfd-start I get the following message: NFD is already running?

So I run $ nfdc register /ndn udp://10.10.1.1<http://10.10.1.1> and I should get the Successful? message, but I get nothing.
nfd-status yields nothing too.
I tried nfd-stop > nfd-start and nothing shows up.

I searched on the mailing list and couldn?t find anything.

Do you have any suggestions or tests to do?

Thanks,
Thiago


PS: There?s a typo in the building documentation instructions. It should be ./waf doxygen instead of doxgyen
http://named-data.net/doc/NFD/current/INSTALL.html#building-documentation

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

From peter at remap.ucla.edu  Tue Jun 14 13:45:56 2016
From: peter at remap.ucla.edu (Gusev, Peter)
Date: Tue, 14 Jun 2016 20:45:56 +0000
Subject: [Nfd-dev] 1-to-Many NDN-RTC test and hub strategy
In-Reply-To: <575ef4e9.184f620a.c0da6.ffffb61d@mx.google.com>
References: <CAOFH+OZL6JLoQZwenACp2a32ruucRbauPM_HuVTTxvzV+0LE0g@mail.gmail.com>
	<5CDE7BF2-2533-407C-A546-3C2A3241C3F7@remap.ucla.edu>
	<059000c3-9a62-47cc-a372-b06a1415a4df@emhub4.ad.ucla.edu>
	<CAOFH+ObxW9Ye4ymzavbPvwc8mcjzDtCMsPRrSc12maq+8RRQXw@mail.gmail.com>
	<CAOFH+OaFiuu52Hjx113vDUc9jCLTgiHJ40NB_rAe5=St+Q42FA@mail.gmail.com>
	<5C988871-3C4A-4943-96BF-F37A4C66EF1C@remap.ucla.edu>
	<575ef4e9.184f620a.c0da6.ffffb61d@mx.google.com>
Message-ID: <50AE3474-9161-4EDE-B175-C182C7FFAC34@remap.ucla.edu>

Thanks, Junxiao,

I?ve got the changes:

$ git clone http://gerrit.named-data.net/NFD && cd NFD
$ git fetch http://gerrit.named-data.net/NFD refs/changes/76/2876/2 && git checkout FETCH_HEAD
$ git submodule init && git submodule update
$ ./waf configure && ./waf
$ sudo ./waf install

compiled NFD:

$ nfd --version
0.4.1-24-g7280b4f

However, nfd-status doesn?t output anything for me, is this normal?

$ nfd-start
1465935605.510651 INFO: [StrategyChoice] setDefaultStrategy /localhost/nfd/strategy/best-route/%FD%04
1465935605.510897 INFO: [InternalForwarderTransport] [id=0,local=internal://,remote=internal://] Creating transport
1465935605.510932 INFO: [FaceTable] Added face id=1 remote=internal:// local=internal://
1465935605.511518 WARNING: [CommandValidator] Wildcard identity is intended for demo purpose only and SHOULD NOT be used in production environment
1465935605.511524 INFO: [CommandValidator] Giving privilege "faces" to identity wildcard
1465935605.511527 INFO: [CommandValidator] Giving privilege "fib" to identity wildcard
1465935605.511530 INFO: [CommandValidator] Giving privilege "strategy-choice" to identity wildcard
1465935605.511758 INFO: [StrategyChoice] changeStrategy(/ndn/broadcast) from /localhost/nfd/strategy/best-route/%FD%04 to /localhost/nfd/strategy/multicast/%FD%01
1465935605.511774 INFO: [StrategyChoice] changeStrategy(/localhost) from /localhost/nfd/strategy/best-route/%FD%04 to /localhost/nfd/strategy/multicast/%FD%01
1465935605.511788 INFO: [StrategyChoice] changeStrategy(/localhost/nfd) from /localhost/nfd/strategy/multicast/%FD%01 to /localhost/nfd/strategy/best-route/%FD%04
1465935605.511798 INFO: [TablesConfigSection] Setting CS max packets to 65536
1465935605.512313 INFO: [MulticastUdpTransport] [id=0,local=udp4://172.17.0.2:56363,remote=udp4://224.0.23.170:56363] Creating transport
1465935605.512322 INFO: [FaceTable] Added face id=256 remote=udp4://224.0.23.170:56363 local=udp4://172.17.0.2:56363
1465935605.512363 INFO: [EthernetTransport] [id=0,local=dev://eth0,remote=ether://[01:00:5e:00:17:aa]] Creating transport
1465935605.512949 INFO: [FaceTable] Added face id=257 remote=ether://[01:00:5e:00:17:aa] local=dev://eth0
1465935605.513038 WARNING: [CommandValidator] Wildcard identity is intended for demo purpose only and SHOULD NOT be used in production environment
1465935605.513047 INFO: [CommandValidator] Giving privilege "faces" to identity wildcard
1465935605.513103 INFO: [CommandValidator] Giving privilege "fib" to identity wildcard
1465935605.513140 INFO: [CommandValidator] Giving privilege "strategy-choice" to identity wildcard
1465935605.513313 INFO: [InternalForwarderTransport] [id=0,local=null://,remote=null://] Creating transport
1465935605.513325 INFO: [FaceTable] Added face id=255 remote=null:// local=null://
1465935605.516135 INFO: [InternalForwarderTransport] [id=0,local=contentstore://,remote=contentstore://] Creating transport
1465935605.516144 INFO: [FaceTable] Added face id=254 remote=contentstore:// local=contentstore://
1465935605.522935 INFO: [PrivilegeHelper] dropped to effective uid=0 gid=0
1465935605.524431 INFO: [AutoPrefixPropagator] Load auto_prefix_propagate section in rib section
1465935605.524910 INFO: [AutoPrefixPropagator] Load auto_prefix_propagate section in rib section
1465935605.525198 INFO: [RibManager] Listening on: /localhost/nfd/rib
1465935605.528298 INFO: [RibManager] Start monitoring face create/destroy events
1465935605.531024 INFO: [UnixStreamTransport] [id=0,local=unix:///run/nfd.sock,remote=fd://26] Creating transport
1465935605.531041 INFO: [FaceTable] Added face id=258 remote=fd://26 local=unix:///run/nfd.sock
1465935605.535805 INFO: [AutoPrefixPropagator] local registration only for /localhost/nfd/rib
$ nfd-status
$

Likewise, nfdc command doesn?t do anything.

Thanks,

--
Peter Gusev

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

Software Engineer/Programmer Analyst @ REMAP UCLA

Video streaming/ICN networks/Creative Development

On Jun 13, 2016, at 11:01 AM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:

Hi Peter

You may check out a commit from Gerrit by following step 1-3 on the procedure given in http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2015-June/001147.html
Afterwards, do a ./waf distclean, and recompile.

Yours, Junxiao

From: Gusev, Peter<mailto:peter at remap.ucla.edu>
Sent: Monday, June 13, 2016 10:34
To: Junxiao Shi<mailto:shijunxiao at email.arizona.edu>
Subject: Re: [Nfd-dev] 1-to-Many NDN-RTC test and hub strategy

Hi Junxiao,

I have little experience with gerrit. Can you please give me exact steps on how to merge these changes into my NFD git repo?

Thanks,

--
Peter Gusev

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

From shijunxiao at email.arizona.edu  Tue Jun 14 15:55:39 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Tue, 14 Jun 2016 15:55:39 -0700
Subject: [Nfd-dev] nfd-start yield nothing after fresh installation
In-Reply-To: <BN3PR04MB2196A2F6D371D888F5F082BAD9540@BN3PR04MB2196.namprd04.prod.outlook.com>
References: <41E7DF15B39B5C46BF24C9545D39304C2AD9B696@oit-ex2010-mb1>
	<57518d8b.d618620a.6432e.37b4@mx.google.com>
	<41E7DF15B39B5C46BF24C9545D39304C2AD9BD3C@oit-ex2010-mb1>
	<CAOFH+OY1W13badAfz9AWVeGE3GVCRM-qn7kCKk9YNmYsrQyzFg@mail.gmail.com>
	<CAOFH+OYm_zg8HUymxARizzFvz91BxKqrjX4L9mR643zUptRacw@mail.gmail.com>
	,<41E7DF15B39B5C46BF24C9545D39304C2AD9C9DA@oit-ex2010-mb1>
	<BN3PR04MB2196A2F6D371D888F5F082BAD9540@BN3PR04MB2196.namprd04.prod.outlook.com>
Message-ID: <57608b67.4335620a.e4599.1897@mx.google.com>

Hi Ashlesh

Thanks for your report and bisect.
I?ve reported this as Bug 3650.

Yours, Junxiao

From: Ashlesh Gawande (agawande)
Sent: Tuesday, June 14, 2016 11:13
To: Thiago Teixeira; <nfd-dev at lists.cs.ucla.edu>
Subject: Re: [Nfd-dev] nfd-start yield nothing after fresh installation

I was having the same problem in Ubuntu 14.04. nfd-status does not work but I can run NLSR.
nfd-status would not even display an error connecting to the forwarder if NFD was not running.
The only option that worked was nfd-status -h.

I have NFD installed from source in two machines Ubuntu 14.04 and Ubuntu 15.10 (both are VMs).

I did a git pull and updated NFD on both to latest. nfd-status stopped working only on Ubuntu 14.04.
(ndn-cxx version was updated and installed before NFD)

I went back one by one until finally nfd-status worked with?this commit:
https://github.com/named-data/NFD/commit/ace83ac9384da037a36695888e829d7337ce36b0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160614/9b129c03/attachment.html>

From shijunxiao at email.arizona.edu  Tue Jun 14 15:58:34 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Tue, 14 Jun 2016 15:58:34 -0700
Subject: [Nfd-dev] 1-to-Many NDN-RTC test and hub strategy
In-Reply-To: <749a31bb-6085-48f8-bb8e-41bef76bc9d1@EMHUB6.ad.ucla.edu>
References: <CAOFH+OZL6JLoQZwenACp2a32ruucRbauPM_HuVTTxvzV+0LE0g@mail.gmail.com>
	<5CDE7BF2-2533-407C-A546-3C2A3241C3F7@remap.ucla.edu>
	<059000c3-9a62-47cc-a372-b06a1415a4df@emhub4.ad.ucla.edu>
	<CAOFH+ObxW9Ye4ymzavbPvwc8mcjzDtCMsPRrSc12maq+8RRQXw@mail.gmail.com>
	<CAOFH+OaFiuu52Hjx113vDUc9jCLTgiHJ40NB_rAe5=St+Q42FA@mail.gmail.com>
	<5C988871-3C4A-4943-96BF-F37A4C66EF1C@remap.ucla.edu>
	<575ef4e9.184f620a.c0da6.ffffb61d@mx.google.com>
	<749a31bb-6085-48f8-bb8e-41bef76bc9d1@EMHUB6.ad.ucla.edu>
Message-ID: <57608c16.c89b420a.fc5e9.19a7@mx.google.com>

Hi Peter

Unfortunately you are being affected by Bug 3650.
It?s said that this bug does not affect Ubuntu 15.10. If possible, you can use Ubuntu 15.10 to perform the experiment.
Otherwise, since nfdc is not working, you have to wait for this bug to close.

Yours, Junxiao

From: Gusev, Peter
Sent: Tuesday, June 14, 2016 13:46
To: Junxiao Shi
Cc: <nfd-dev at lists.cs.ucla.edu>
Subject: Re: [Nfd-dev] 1-to-Many NDN-RTC test and hub strategy

Thanks, Junxiao, 

I?ve got the changes:

$ git clone http://gerrit.named-data.net/NFD?&& cd NFD
$ git fetch http://gerrit.named-data.net/NFD refs/changes/76/2876/2 && git checkout FETCH_HEAD
$ git submodule init && git submodule update
$ ./waf configure && ./waf
$ sudo ./waf install

compiled NFD:

$ nfd --version
0.4.1-24-g7280b4f

However, nfd-status doesn?t output anything for me, is this normal?

$ nfd-start
1465935605.510651 INFO: [StrategyChoice] setDefaultStrategy /localhost/nfd/strategy/best-route/%FD%04
1465935605.510897 INFO: [InternalForwarderTransport] [id=0,local=internal://,remote=internal://] Creating transport
1465935605.510932 INFO: [FaceTable] Added face id=1 remote=internal:// local=internal://
1465935605.511518 WARNING: [CommandValidator] Wildcard identity is intended for demo purpose only and SHOULD NOT be used in production environment
1465935605.511524 INFO: [CommandValidator] Giving privilege "faces" to identity wildcard
1465935605.511527 INFO: [CommandValidator] Giving privilege "fib" to identity wildcard
1465935605.511530 INFO: [CommandValidator] Giving privilege "strategy-choice" to identity wildcard
1465935605.511758 INFO: [StrategyChoice] changeStrategy(/ndn/broadcast) from /localhost/nfd/strategy/best-route/%FD%04 to /localhost/nfd/strategy/multicast/%FD%01
1465935605.511774 INFO: [StrategyChoice] changeStrategy(/localhost) from /localhost/nfd/strategy/best-route/%FD%04 to /localhost/nfd/strategy/multicast/%FD%01
1465935605.511788 INFO: [StrategyChoice] changeStrategy(/localhost/nfd) from /localhost/nfd/strategy/multicast/%FD%01 to /localhost/nfd/strategy/best-route/%FD%04
1465935605.511798 INFO: [TablesConfigSection] Setting CS max packets to 65536
1465935605.512313 INFO: [MulticastUdpTransport] [id=0,local=udp4://172.17.0.2:56363,remote=udp4://224.0.23.170:56363] Creating transport
1465935605.512322 INFO: [FaceTable] Added face id=256 remote=udp4://224.0.23.170:56363 local=udp4://172.17.0.2:56363
1465935605.512363 INFO: [EthernetTransport] [id=0,local=dev://eth0,remote=ether://[01:00:5e:00:17:aa]] Creating transport
1465935605.512949 INFO: [FaceTable] Added face id=257 remote=ether://[01:00:5e:00:17:aa] local=dev://eth0
1465935605.513038 WARNING: [CommandValidator] Wildcard identity is intended for demo purpose only and SHOULD NOT be used in production environment
1465935605.513047 INFO: [CommandValidator] Giving privilege "faces" to identity wildcard
1465935605.513103 INFO: [CommandValidator] Giving privilege "fib" to identity wildcard
1465935605.513140 INFO: [CommandValidator] Giving privilege "strategy-choice" to identity wildcard
1465935605.513313 INFO: [InternalForwarderTransport] [id=0,local=null://,remote=null://] Creating transport
1465935605.513325 INFO: [FaceTable] Added face id=255 remote=null:// local=null://
1465935605.516135 INFO: [InternalForwarderTransport] [id=0,local=contentstore://,remote=contentstore://] Creating transport
1465935605.516144 INFO: [FaceTable] Added face id=254 remote=contentstore:// local=contentstore://
1465935605.522935 INFO: [PrivilegeHelper] dropped to effective uid=0 gid=0
1465935605.524431 INFO: [AutoPrefixPropagator] Load auto_prefix_propagate section in rib section
1465935605.524910 INFO: [AutoPrefixPropagator] Load auto_prefix_propagate section in rib section
1465935605.525198 INFO: [RibManager] Listening on: /localhost/nfd/rib
1465935605.528298 INFO: [RibManager] Start monitoring face create/destroy events
1465935605.531024 INFO: [UnixStreamTransport] [id=0,local=unix:///run/nfd.sock,remote=fd://26] Creating transport
1465935605.531041 INFO: [FaceTable] Added face id=258 remote=fd://26 local=unix:///run/nfd.sock
1465935605.535805 INFO: [AutoPrefixPropagator] local registration only for /localhost/nfd/rib
$ nfd-status
$

Likewise, nfdc command doesn?t do anything.

Thanks,?

--?
Peter Gusev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160614/b552a74f/attachment.html>

From jburke at remap.ucla.edu  Wed Jun 15 03:34:43 2016
From: jburke at remap.ucla.edu (Burke, Jeff)
Date: Wed, 15 Jun 2016 10:34:43 +0000
Subject: [Nfd-dev] [ndn] NDN Seminar: Practical Congestion Control for
 NDN
In-Reply-To: <CAOFH+ObpY8gpvomnanZRF+dFGbToiiWyM4vr_PWnFQbjyP2A2g@mail.gmail.com>
References: <05BCCCCC-4400-4305-8AE5-DE894BF1A7F1@cs.ucla.edu>
	<430E1CDF-ED12-45C9-BD97-125049FE475E@cs.ucla.edu>
	<2A94D772-4EE7-42C0-B030-C0A53E9E164E@cs.ucla.edu>
	<AE1669BA-A316-49C9-A0D7-D73A1CC43680@cs.ucla.edu>
	<574d1575.c451620a.7e7be.ffff9da5@mx.google.com>
	<AA42FA39-A8A8-4039-8A24-C4BD2D9050D4@cs.ucla.edu>
	<48B3ADE0-B913-466B-8A28-D1D8AF2D12D7@email.arizona.edu>
	<1adb5db8-f384-4127-8afc-3d2b710860d7@EMHUB5.ad.ucla.edu>
	<68A7E1B1-EAFD-441B-8568-AD55070ECAE2@email.arizona.edu>
	<24F5D101-226B-40F5-B26E-86E4E96CF9D6@wustl.edu>
	<1B24FB64-4355-41D8-92E1-E01AD44A3391@email.arizona.edu>
	<A84C3ECF-B38B-4397-9434-D77F7F39102B@remap.ucla.edu>
	<A2CC6739-5421-420A-980E-76A0E6BE617E@wustl.edu>
	<FCFC34D7-1B50-4E4F-84E0-AA9B521D84AA@remap.ucla.edu>
	<DA2B72F9-D885-4226-A319-56BB06DEEF2E@wustl.edu>
	<A959E4EF-D6AE-4507-905C-4425FC732C0E@remap.ucla.edu>
	<BC70558F-D6AF-4B48-B27D-AE8F396B3895@wustl.edu>
	<23D42CE8-3C2B-4FFD-AF0E-073CE9083549@remap.ucla.edu>
	<864D1969-3A81-4015-B533-C81064A41A7E@wustl.edu>
	<E78AAD90-536C-4166-B4E9-09F8A937EB23@wustl.edu>
	<DE2095E2-8C6D-43A8-8AF0-7D90D51ED085@remap.ucla.edu>
	<7FBAC07E-BB34-4884-93A7-C0181059522C@wustl.edu>
	<AB89F0D5-1968-4530-A1C2-FB946BCB2F51@wustl.edu>
	<228C3BBD-7859-41FF-B151-0F237CF742F5@remap.ucla.edu>
	<6c75cadf-f1cf-4c22-aeaf-617d102e4e9b@EMHUB5.ad.ucla.edu>
	<10E77B45-9387-47C1-A7A4-2CD624738900@email.arizona.edu>
	<9b807ce7-8878-4d80-a3d7-48618899ff1f@emhub4.ad.ucla.edu>
	<CAOFH+ObpY8gpvomnanZRF+dFGbToiiWyM4vr_PWnFQbjyP2A2g@mail.gmail.com>
Message-ID: <DEA378D2-020B-47D9-8E96-A553254BEC10@remap.ucla.edu>

How / when are we going to be able to delegate in this way?
We have many machines that are not directly associated with a user cert.
Jeff

From: Nfd-dev <nfd-dev-bounces at lists.cs.ucla.edu> on behalf of Junxiao Shi <shijunxiao at email.arizona.edu>
Date: Monday, June 13, 2016 at 9:53 PM
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] NDN Seminar: Practical Congestion Control for NDN


These sequence are incorrect. You cannot use any certificate other than the one directly requested from ndncert.
On Jun 13, 2016 12:22 PM, "Gusev, Peter" <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>> wrote:
Hi Junxiao,

I generated a cert request on freeculture like this:

        $ ndnsec-keygen /ndn/edu/ucla/remap/peter/freeculture > freeculture.pub

Then, I signed it on my machine:

        $ ndnsec-certgen -N freeculture -p /ndn/edu/ucla/remap/peter -r freeculture.pub > freeculture.signed

I sent freeculture.signed back to freeculture machine, as long as my certificate (previously dumped):

        $ ndnsec-cert-dump /ndn/edu/ucla/remap/peter > peter.cert

Finally, I installed both certificates on freeculture machine:

$ ndnsec-install-cert peter.cert
$ ndnsec-install-cert freeculture.signed

Both ended successfully. I then switched default identity to /ndn/edu/ucla/remap/peter/freeculture on freeculture machine:

$ ndnsec set-default /ndn/edu/ucla/remap/peter/freeculture

However, I don?t see connectivity to the testbed after running ndn-autoconfig.

Was the above sequence correct?

Thanks,

--
Peter Gusev

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

Software Engineer/Programmer Analyst @ REMAP UCLA

Video streaming/ICN networks/Creative Development

> On Jun 2, 2016, at 12:05 PM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:
>
> Hi Peter
>
> This is an unsupported configuration. Certificates can only be requested through ndncert web app, and it?s always tied to your email.
>
> Yours, Junxiao
>
>> On Jun 2, 2016, at 12:02 PM, Gusev, Peter <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>> wrote:
>>
>> hi Junxiao,
>>
>> I generated certs for freeculture and confbridge and signed them on REMAP hub like this:
>>
>> $ ndnsec-certgen -N confbridge -p /ndn/edu/ucla/remap -r confbridge.pub
>>
>> I installed them on corresponding machines, however it seems not working yet.
>> Is the above command correct?
>>
>> Thanks,
>>
>> --
>> Peter Gusev
>>
>> peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>
>> +1 213 5872748<tel:%2B1%20213%205872748>
>> peetonn_ (skype)
>>
>> Software Engineer/Programmer Analyst @ REMAP UCLA
>>
>> Video streaming/ICN networks/Creative Development
>>
>>> On Jun 2, 2016, at 11:13 AM, Peter Gusev <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>> wrote:
>>>
>>> no, i?m not publishing.
>>>
>>>
>>> Junxiao, I?m generating a certificate for confbridge. But I?m not sure I?ll make it in time for the Seminar.
>>>
>>> Thanks,
>>>
>>> --
>>> Peter Gusev
>>>
>>> peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>
>>> +1 213 5872748<tel:%2B1%20213%205872748>
>>> peetonn_ (skype)
>>>
>>> Software Engineer/Programmer Analyst @ REMAP UCLA
>>>
>>> Video streaming/ICN networks/Creative Development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160615/9f8daeca/attachment.html>

From shijunxiao at email.arizona.edu  Wed Jun 15 04:38:47 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Wed, 15 Jun 2016 04:38:47 -0700
Subject: [Nfd-dev] delegate prefix registration
Message-ID: <CAOFH+OY14vZjLP-jPEDqN8-9-SDZtpaC7ny69wvt8ewh0asJ+w@mail.gmail.com>

Hi Jeff

As indicated in #3568 <http://redmine.named-data.net/issues/3568> issue
description, ndncert certificates will be required until #2766
<http://redmine.named-data.net/issues/2766> and related functions are
available.
#2766 itself is blocked by KeyChain refactoring, so it's unlikely to be
available in next 6 months.

For now, you have to request a user certificate for each and every machine.
You could use subaddressing (see RFC5233
<https://tools.ietf.org/html/rfc5233>) to request certificates for each
machine, such as peter+freeculture at remap.ucla.edu
peter+confbridge at remap.ucla.edu , instead of creating whole new mailboxes.
Note that although you can request multiple user certificates with the same
email address ( peter at remap.ucla.edu ) or copy the same user certificate
onto multiple machines, doing so would cause those machines to register the
same prefix on the router and rely on strategy to determine the correct
route, which can worsen forwarding performance.

I do have a method to create delegated certificates like what Peter is
trying to do, using only supported software.
The basic idea is to publish certificates on an always-on server, so that
testbed router can retrieve it.
I'll write a blog post about this soon.

Yours, Junxiao

On Wed, Jun 15, 2016 at 3:34 AM, Burke, Jeff <jburke at remap.ucla.edu> wrote:

> How / when are we going to be able to delegate in this way?
> We have many machines that are not directly associated with a user cert.
>
> Jeff
>
>
>
> *From: *Nfd-dev <nfd-dev-bounces at lists.cs.ucla.edu> on behalf of Junxiao
> Shi <shijunxiao at email.arizona.edu>
> *Date: *Monday, June 13, 2016 at 9:53 PM
> *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] NDN Seminar: Practical Congestion Control
> for NDN
>
>
>
> These sequence are incorrect. You cannot use any certificate other than
> the one directly requested from ndncert.
>
> On Jun 13, 2016 12:22 PM, "Gusev, Peter" <peter at remap.ucla.edu> wrote:
>
> Hi Junxiao,
>
> I generated a cert request on freeculture like this:
>
>         $ ndnsec-keygen /ndn/edu/ucla/remap/peter/freeculture >
> freeculture.pub
>
> Then, I signed it on my machine:
>
>         $ ndnsec-certgen -N freeculture -p /ndn/edu/ucla/remap/peter -r
> freeculture.pub > freeculture.signed
>
> I sent freeculture.signed back to freeculture machine, as long as my
> certificate (previously dumped):
>
>         $ ndnsec-cert-dump /ndn/edu/ucla/remap/peter > peter.cert
>
> Finally, I installed both certificates on freeculture machine:
>
> $ ndnsec-install-cert peter.cert
> $ ndnsec-install-cert freeculture.signed
>
> Both ended successfully. I then switched default identity to
> /ndn/edu/ucla/remap/peter/freeculture on freeculture machine:
>
> $ ndnsec set-default /ndn/edu/ucla/remap/peter/freeculture
>
> However, I don?t see connectivity to the testbed after running
> ndn-autoconfig.
>
> Was the above sequence correct?
>
> Thanks,
>
> --
> Peter Gusev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160615/716d9343/attachment.html>

From nfd-call-notification at mail1.yoursunny.com  Thu Jun 16 10:00:02 2016
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Thu, 16 Jun 2016 10:00:02 -0700
Subject: [Nfd-dev] NFD call 20160616
Message-ID: <201606161700.u5GH023e024857@lectura.cs.arizona.edu>

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

From shijunxiao at email.arizona.edu  Mon Jun 20 20:14:44 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Mon, 20 Jun 2016 20:14:44 -0700
Subject: [Nfd-dev] 1-to-Many NDN-RTC test and hub strategy
In-Reply-To: <CAOFH+OaFiuu52Hjx113vDUc9jCLTgiHJ40NB_rAe5=St+Q42FA@mail.gmail.com>
References: <CAOFH+OZL6JLoQZwenACp2a32ruucRbauPM_HuVTTxvzV+0LE0g@mail.gmail.com>
	<5CDE7BF2-2533-407C-A546-3C2A3241C3F7@remap.ucla.edu>
	<059000c3-9a62-47cc-a372-b06a1415a4df@emhub4.ad.ucla.edu>
	<CAOFH+ObxW9Ye4ymzavbPvwc8mcjzDtCMsPRrSc12maq+8RRQXw@mail.gmail.com>
	<CAOFH+OaFiuu52Hjx113vDUc9jCLTgiHJ40NB_rAe5=St+Q42FA@mail.gmail.com>
Message-ID: <CAOFH+OaQvR2-UkzGAk4shmsS=14VpAD9Vv5eR-kDiJEZOBCbuw@mail.gmail.com>

Hi Peter

Both #3642 and #3650 have been merged.
Can you re-test according to #3642-10
<http://redmine.named-data.net/issues/3642#note-10>, and post the result on
Redmine?

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

From nfd-call-notification at mail1.yoursunny.com  Tue Jun 21 10:00:03 2016
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Tue, 21 Jun 2016 10:00:03 -0700
Subject: [Nfd-dev] NFD call 20160621
Message-ID: <201606211700.u5LH03BB015353@lectura.cs.arizona.edu>

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

From peter at remap.UCLA.edu  Tue Jun 21 17:00:26 2016
From: peter at remap.UCLA.edu (Gusev, Peter)
Date: Wed, 22 Jun 2016 00:00:26 +0000
Subject: [Nfd-dev] 1-to-Many NDN-RTC test and hub strategy
In-Reply-To: <CAOFH+OaQvR2-UkzGAk4shmsS=14VpAD9Vv5eR-kDiJEZOBCbuw@mail.gmail.com>
References: <CAOFH+OZL6JLoQZwenACp2a32ruucRbauPM_HuVTTxvzV+0LE0g@mail.gmail.com>
	<5CDE7BF2-2533-407C-A546-3C2A3241C3F7@remap.ucla.edu>
	<059000c3-9a62-47cc-a372-b06a1415a4df@emhub4.ad.ucla.edu>
	<CAOFH+ObxW9Ye4ymzavbPvwc8mcjzDtCMsPRrSc12maq+8RRQXw@mail.gmail.com>
	<CAOFH+OaFiuu52Hjx113vDUc9jCLTgiHJ40NB_rAe5=St+Q42FA@mail.gmail.com>
	<CAOFH+OaQvR2-UkzGAk4shmsS=14VpAD9Vv5eR-kDiJEZOBCbuw@mail.gmail.com>
Message-ID: <50045441-F7BF-4E3D-A1BD-EBDFAC1AF145@remap.ucla.edu>

Thanks, Junxiao.

I can confirm that the problem wasn't reproduced on the latest commit from the master branch for 1-to-10 scenario.

Thanks,

--
Peter Gusev

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

Software Engineer/Programmer Analyst @ REMAP UCLA

Video streaming/ICN networks/Creative Development

On Jun 20, 2016, at 8:14 PM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:

Hi Peter

Both #3642 and #3650 have been merged.
Can you re-test according to #3642-10<http://redmine.named-data.net/issues/3642#note-10>, and post the result on Redmine?

Yours, Junxiao

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

From peter at remap.ucla.edu  Wed Jun 22 12:36:55 2016
From: peter at remap.ucla.edu (Gusev, Peter)
Date: Wed, 22 Jun 2016 19:36:55 +0000
Subject: [Nfd-dev] 1-to-Many NDN-RTC test and hub strategy
In-Reply-To: <50045441-F7BF-4E3D-A1BD-EBDFAC1AF145@remap.ucla.edu>
References: <CAOFH+OZL6JLoQZwenACp2a32ruucRbauPM_HuVTTxvzV+0LE0g@mail.gmail.com>
	<5CDE7BF2-2533-407C-A546-3C2A3241C3F7@remap.ucla.edu>
	<059000c3-9a62-47cc-a372-b06a1415a4df@emhub4.ad.ucla.edu>
	<CAOFH+ObxW9Ye4ymzavbPvwc8mcjzDtCMsPRrSc12maq+8RRQXw@mail.gmail.com>
	<CAOFH+OaFiuu52Hjx113vDUc9jCLTgiHJ40NB_rAe5=St+Q42FA@mail.gmail.com>
	<CAOFH+OaQvR2-UkzGAk4shmsS=14VpAD9Vv5eR-kDiJEZOBCbuw@mail.gmail.com>
	<50045441-F7BF-4E3D-A1BD-EBDFAC1AF145@remap.ucla.edu>
Message-ID: <7AB1ACAB-C6EE-4245-BB1C-79C4D846C1F5@remap.ucla.edu>

Hi Junxiao,

I ran more 1-to-10 tests recently (here are the results<http://ec2-52-90-158-238.compute-1.amazonaws.com:3000/dashboard/db/ndn-rtc-tests-test-run-overview?from=1466566688346&to=1466567022507&var-runtime=15m> of one out five tests) and observe an unusual behavior: consumers are not able to get data all simultaneously, instead - they join one-by-one. This can be seen from rebufferings graph<http://ec2-52-90-158-238.compute-1.amazonaws.com:3000/dashboard/db/ndn-rtc-tests-test-run-overview?from=1466566688346&to=1466567022507&var-runtime=15m&panelId=15&fullscreen> and incoming traffic graph<http://ec2-52-90-158-238.compute-1.amazonaws.com:3000/dashboard/db/ndn-rtc-tests-test-run-overview?from=1466566688346&to=1466567022507&panelId=20&fullscreen&var-runtime=15m>. I see that, consumers get timeouts for the initial interests.

Please, let me know what data do you need to analyze this (tcpdumps for hub is enough?).

Thanks,

--
Peter Gusev

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

Software Engineer/Programmer Analyst @ REMAP UCLA

Video streaming/ICN networks/Creative Development

On Jun 21, 2016, at 5:00 PM, Gusev, Peter <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>> wrote:

Thanks, Junxiao.

I can confirm that the problem wasn't reproduced on the latest commit from the master branch for 1-to-10 scenario.

Thanks,

--
Peter Gusev

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

Software Engineer/Programmer Analyst @ REMAP UCLA

Video streaming/ICN networks/Creative Development

On Jun 20, 2016, at 8:14 PM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:

Hi Peter

Both #3642 and #3650 have been merged.
Can you re-test according to #3642-10<http://redmine.named-data.net/issues/3642#note-10>, and post the result on Redmine?

Yours, Junxiao

_______________________________________________
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/20160622/e66ff510/attachment.html>

From lixia at CS.UCLA.EDU  Wed Jun 22 14:17:19 2016
From: lixia at CS.UCLA.EDU (Lixia Zhang)
Date: Wed, 22 Jun 2016 14:17:19 -0700
Subject: [Nfd-dev] Thursday 6/23 NFD call
Message-ID: <33AA7903-B47B-48AD-9E69-5CB2FEE46A6B@cs.ucla.edu>

My understanding is that this will be the last NFD call before Yingdi departs from UCLA (I do hope he would be able to tune in some future NFD calls, but probably not in the next month or so when he has to go through Facebook training etc).

So Yingdi, would you please join the call?  So that we can wrap up the status of all your part of the coding, and make a clear list of remaining issues, if any.

Beichuan, hope you can join as well.





From bzhang at cs.arizona.edu  Wed Jun 22 21:19:30 2016
From: bzhang at cs.arizona.edu (Beichuan Zhang)
Date: Thu, 23 Jun 2016 12:19:30 +0800
Subject: [Nfd-dev] Thursday 6/23 NFD call
In-Reply-To: <33AA7903-B47B-48AD-9E69-5CB2FEE46A6B@cs.ucla.edu>
References: <33AA7903-B47B-48AD-9E69-5CB2FEE46A6B@cs.ucla.edu>
Message-ID: <B4D6C154-344D-4977-BEF3-EEB774EC028E@cs.arizona.edu>

I can join tomorrow?s call. I probably won?t be able to say much though since I?m having a very bad sore throat. I couldn?t talk yesterday, hope it?ll be better tomorrow.

Beichuan

> On Jun 23, 2016, at 5:17 AM, Lixia Zhang <lixia at cs.ucla.edu> wrote:
> 
> My understanding is that this will be the last NFD call before Yingdi departs from UCLA (I do hope he would be able to tune in some future NFD calls, but probably not in the next month or so when he has to go through Facebook training etc).
> 
> So Yingdi, would you please join the call?  So that we can wrap up the status of all your part of the coding, and make a clear list of remaining issues, if any.
> 
> Beichuan, hope you can join as well.
> 
> 




From shijunxiao at email.arizona.edu  Thu Jun 23 04:57:48 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Thu, 23 Jun 2016 04:57:48 -0700
Subject: [Nfd-dev] Jenkins outage
In-Reply-To: <CAOFH+ObasNvDJqZx10JJ9tCRS=ejTeFtsvpYCC3Wa52rAV12_w@mail.gmail.com>
References: <CAOFH+OZfG=+MYBouxwacZ53U2dKWtaiKnG6pEx6mvVTjTrWhfw@mail.gmail.com>
	<CAOFH+ObasNvDJqZx10JJ9tCRS=ejTeFtsvpYCC3Wa52rAV12_w@mail.gmail.com>
Message-ID: <CAOFH+Obg955Pzwb7w73QeX8BryA_mk2d4z8FYJLnV-v9+JW8kw@mail.gmail.com>

Dear folks

There will be a power outage on Jun 23 0800-0900 Arizona time in our
building. The server hosting Jenkins will be shutdown.

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

From agawande at memphis.edu  Thu Jun 23 09:18:57 2016
From: agawande at memphis.edu (Ashlesh Gawande (agawande))
Date: Thu, 23 Jun 2016 16:18:57 +0000
Subject: [Nfd-dev] Jenkins outage
In-Reply-To: <CAOFH+Obg955Pzwb7w73QeX8BryA_mk2d4z8FYJLnV-v9+JW8kw@mail.gmail.com>
References: <CAOFH+OZfG=+MYBouxwacZ53U2dKWtaiKnG6pEx6mvVTjTrWhfw@mail.gmail.com>
	<CAOFH+ObasNvDJqZx10JJ9tCRS=ejTeFtsvpYCC3Wa52rAV12_w@mail.gmail.com>,
	<CAOFH+Obg955Pzwb7w73QeX8BryA_mk2d4z8FYJLnV-v9+JW8kw@mail.gmail.com>
Message-ID: <BN3PR04MB219614D8064398F6F492037BD92D0@BN3PR04MB2196.namprd04.prod.outlook.com>

Is this why redmine is down as well?


Ashlesh

________________________________
From: Nfd-dev <nfd-dev-bounces at lists.cs.ucla.edu> on behalf of Junxiao Shi <shijunxiao at email.arizona.edu>
Sent: Thursday, June 23, 2016 6:57:48 AM
To: <nfd-dev at lists.cs.ucla.edu>
Subject: [Nfd-dev] Jenkins outage


Dear folks

There will be a power outage on Jun 23 0800-0900 Arizona time in our building. The server hosting Jenkins will be shutdown.

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

From nfd-call-notification at mail1.yoursunny.com  Thu Jun 23 10:00:01 2016
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Thu, 23 Jun 2016 10:00:01 -0700
Subject: [Nfd-dev] NFD call 20160623
Message-ID: <201606231700.u5NH01Jo016721@lectura.cs.arizona.edu>

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

From aa at CS.UCLA.EDU  Thu Jun 23 10:22:03 2016
From: aa at CS.UCLA.EDU (Alex Afanasyev)
Date: Thu, 23 Jun 2016 10:22:03 -0700
Subject: [Nfd-dev] Jenkins outage
In-Reply-To: <BN3PR04MB219614D8064398F6F492037BD92D0@BN3PR04MB2196.namprd04.prod.outlook.com>
References: <CAOFH+OZfG=+MYBouxwacZ53U2dKWtaiKnG6pEx6mvVTjTrWhfw@mail.gmail.com>
	<CAOFH+ObasNvDJqZx10JJ9tCRS=ejTeFtsvpYCC3Wa52rAV12_w@mail.gmail.com>
	<CAOFH+Obg955Pzwb7w73QeX8BryA_mk2d4z8FYJLnV-v9+JW8kw@mail.gmail.com>
	<BN3PR04MB219614D8064398F6F492037BD92D0@BN3PR04MB2196.namprd04.prod.outlook.com>
Message-ID: <A77D7777-E1F6-4652-820C-3B1E4E632AE3@cs.ucla.edu>

Redmine is on another server, so it is a different problem.  (I checked and there was again some minor DDoS on the server.)  Should be working now.

---
Alex

> On Jun 23, 2016, at 9:18 AM, Ashlesh Gawande (agawande) <agawande at memphis.edu> wrote:
> 
> Is this why redmine is down as well?
> 
> Ashlesh
> From: Nfd-dev <nfd-dev-bounces at lists.cs.ucla.edu> on behalf of Junxiao Shi <shijunxiao at email.arizona.edu>
> Sent: Thursday, June 23, 2016 6:57:48 AM
> To: <nfd-dev at lists.cs.ucla.edu>
> Subject: [Nfd-dev] Jenkins outage
> 
> Dear folks
> There will be a power outage on Jun 23 0800-0900 Arizona time in our building. The server hosting Jenkins will be shutdown.
> Yours, Junxiao
> 
-------------- 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/20160623/a730548a/attachment.bin>

From yuyingdi at gmail.com  Thu Jun 23 11:56:39 2016
From: yuyingdi at gmail.com (Yingdi Yu)
Date: Thu, 23 Jun 2016 11:56:39 -0700
Subject: [Nfd-dev] Jenkins outage
In-Reply-To: <CAOFH+Obg955Pzwb7w73QeX8BryA_mk2d4z8FYJLnV-v9+JW8kw@mail.gmail.com>
References: <CAOFH+OZfG=+MYBouxwacZ53U2dKWtaiKnG6pEx6mvVTjTrWhfw@mail.gmail.com>
	<CAOFH+ObasNvDJqZx10JJ9tCRS=ejTeFtsvpYCC3Wa52rAV12_w@mail.gmail.com>
	<CAOFH+Obg955Pzwb7w73QeX8BryA_mk2d4z8FYJLnV-v9+JW8kw@mail.gmail.com>
Message-ID: <FF575E63-03F1-482E-94E6-ABF70F300F08@gmail.com>

Jenkins seems still unavailable for now?

Yingdi 

> On Jun 23, 2016, at 4:57 AM, Junxiao Shi <shijunxiao at email.arizona.edu> wrote:
> 
> Dear folks
> 
> There will be a power outage on Jun 23 0800-0900 Arizona time in our building. The server hosting Jenkins will be shutdown.
> 
> 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/20160623/f2655a8f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4109 bytes
Desc: not available
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160623/f2655a8f/attachment.bin>

From shijunxiao at email.arizona.edu  Thu Jun 23 17:14:27 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Thu, 23 Jun 2016 17:14:27 -0700
Subject: [Nfd-dev] Jenkins outage
In-Reply-To: <FF575E63-03F1-482E-94E6-ABF70F300F08@gmail.com>
References: <CAOFH+OZfG=+MYBouxwacZ53U2dKWtaiKnG6pEx6mvVTjTrWhfw@mail.gmail.com>
	<CAOFH+ObasNvDJqZx10JJ9tCRS=ejTeFtsvpYCC3Wa52rAV12_w@mail.gmail.com>
	<CAOFH+Obg955Pzwb7w73QeX8BryA_mk2d4z8FYJLnV-v9+JW8kw@mail.gmail.com>
	<FF575E63-03F1-482E-94E6-ABF70F300F08@gmail.com>
Message-ID: <576c7b65.0a6a620a.6348e.72e7@mx.google.com>

Dear folks

Host server is still offline.
I have opened a ticket with lab staff.

Yours, Junxiao

From: Yingdi Yu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160623/759ccd0d/attachment.html>

From Navdeep.Uniyal at neclab.eu  Fri Jun 24 00:28:10 2016
From: Navdeep.Uniyal at neclab.eu (Navdeep Uniyal)
Date: Fri, 24 Jun 2016 07:28:10 +0000
Subject: [Nfd-dev] VLC Plugin for NDN
Message-ID: <15421E67B274CD4AB5F6AEA46A684C3708AD19C9@PALLENE.office.hd>

Hi All,

Is there available any VLC plugin for running prerecorded videos on NDN for linux?

Best Regards,
Navdeep Uniyal

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

From shijunxiao at email.arizona.edu  Fri Jun 24 10:21:53 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Fri, 24 Jun 2016 10:21:53 -0700
Subject: [Nfd-dev] VLC Plugin for NDN
In-Reply-To: <15421E67B274CD4AB5F6AEA46A684C3708AD19C9@PALLENE.office.hd>
References: <15421E67B274CD4AB5F6AEA46A684C3708AD19C9@PALLENE.office.hd>
Message-ID: <CAOFH+Oabn2vxmMbR-kJwc3eu_jnUi3QZBBz6kWjLza4wBJjTYQ@mail.gmail.com>

Hi Navdeep

I haven't heard about an NDN plugin for VLC.
ndncatchunks
<https://github.com/named-data/ndn-tools/tree/master/tools/chunks> is a
tool to retrieve a file over NDN, and output on stdout. It might be
possible to retrieve a video file from NDNFS
<https://github.com/remap/ndnfs-port>, and feed the stdout to VLC.
However, you can only play the video from start, and cannot seek in it.

Yours, Junxiao

On Fri, Jun 24, 2016 at 12:28 AM, Navdeep Uniyal <Navdeep.Uniyal at neclab.eu>
wrote:

> Hi All,
>
>
>
> Is there available any VLC plugin for running prerecorded videos on NDN
> for linux?
>
>
>
> Best Regards,
>
> Navdeep Uniyal
>
>
>
> _______________________________________________
> 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/20160624/032c0fa6/attachment.html>

From shijunxiao at email.arizona.edu  Fri Jun 24 10:35:07 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Fri, 24 Jun 2016 10:35:07 -0700
Subject: [Nfd-dev] 1-to-Many NDN-RTC test and hub strategy
In-Reply-To: <2c95a909-1c80-42a7-9a24-86c6817b1dbb@EMHUB6.ad.ucla.edu>
References: <CAOFH+OZL6JLoQZwenACp2a32ruucRbauPM_HuVTTxvzV+0LE0g@mail.gmail.com>
	<5CDE7BF2-2533-407C-A546-3C2A3241C3F7@remap.ucla.edu>
	<059000c3-9a62-47cc-a372-b06a1415a4df@emhub4.ad.ucla.edu>
	<CAOFH+ObxW9Ye4ymzavbPvwc8mcjzDtCMsPRrSc12maq+8RRQXw@mail.gmail.com>
	<CAOFH+OaFiuu52Hjx113vDUc9jCLTgiHJ40NB_rAe5=St+Q42FA@mail.gmail.com>
	<CAOFH+OaQvR2-UkzGAk4shmsS=14VpAD9Vv5eR-kDiJEZOBCbuw@mail.gmail.com>
	<50045441-F7BF-4E3D-A1BD-EBDFAC1AF145@remap.ucla.edu>
	<2c95a909-1c80-42a7-9a24-86c6817b1dbb@EMHUB6.ad.ucla.edu>
Message-ID: <CAOFH+ObwDXrcub_i-32on3DiEHs1BcY3BzctbOiFd7QHBQXxag@mail.gmail.com>

Hi Peter

"consumers join one-by-one" is an application layer behavior. I don't know
what does that mean at network layer.
tcpdump at the router should be helpful as a start, however I can't say
what is "enough".

Yours, Junxiao

On Wed, Jun 22, 2016 at 12:36 PM, Gusev, Peter <peter at remap.ucla.edu> wrote:

> Hi Junxiao,
>
> I ran more 1-to-10 tests recently (here are the results
> <http://ec2-52-90-158-238.compute-1.amazonaws.com:3000/dashboard/db/ndn-rtc-tests-test-run-overview?from=1466566688346&to=1466567022507&var-runtime=15m> of
> one out five tests) and observe an unusual behavior: consumers are not able
> to get data all simultaneously, instead - they join one-by-one. This can be
> seen from rebufferings graph
> <http://ec2-52-90-158-238.compute-1.amazonaws.com:3000/dashboard/db/ndn-rtc-tests-test-run-overview?from=1466566688346&to=1466567022507&var-runtime=15m&panelId=15&fullscreen>
>  and incoming traffic graph
> <http://ec2-52-90-158-238.compute-1.amazonaws.com:3000/dashboard/db/ndn-rtc-tests-test-run-overview?from=1466566688346&to=1466567022507&panelId=20&fullscreen&var-runtime=15m>.
> I see that, consumers get timeouts for the initial interests.
>
> Please, let me know what data do you need to analyze this (tcpdumps for
> hub is enough?).
>
> Thanks,
>
> --
> Peter Gusev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160624/f321213b/attachment.html>

From luca.muscariello at gmail.com  Fri Jun 24 10:47:32 2016
From: luca.muscariello at gmail.com (Luca Muscariello)
Date: Fri, 24 Jun 2016 19:47:32 +0200
Subject: [Nfd-dev] VLC Plugin for NDN
In-Reply-To: <15421E67B274CD4AB5F6AEA46A684C3708AD19C9@PALLENE.office.hd>
References: <15421E67B274CD4AB5F6AEA46A684C3708AD19C9@PALLENE.office.hd>
Message-ID: <CAHx=1M7995qZGwcyMjDHKHYTvu973x5e099a0+EvCSPaCXC5oA@mail.gmail.com>

For what OS?

On Friday, 24 June 2016, Navdeep Uniyal <Navdeep.Uniyal at neclab.eu> wrote:

> Hi All,
>
>
>
> Is there available any VLC plugin for running prerecorded videos on NDN
> for linux?
>
>
>
> Best Regards,
>
> Navdeep Uniyal
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160624/24f9db60/attachment.html>

From peter at remap.ucla.edu  Fri Jun 24 14:16:34 2016
From: peter at remap.ucla.edu (Gusev, Peter)
Date: Fri, 24 Jun 2016 21:16:34 +0000
Subject: [Nfd-dev] 1-to-Many NDN-RTC test and hub strategy
In-Reply-To: <CAOFH+ObwDXrcub_i-32on3DiEHs1BcY3BzctbOiFd7QHBQXxag@mail.gmail.com>
References: <CAOFH+OZL6JLoQZwenACp2a32ruucRbauPM_HuVTTxvzV+0LE0g@mail.gmail.com>
	<5CDE7BF2-2533-407C-A546-3C2A3241C3F7@remap.ucla.edu>
	<059000c3-9a62-47cc-a372-b06a1415a4df@emhub4.ad.ucla.edu>
	<CAOFH+ObxW9Ye4ymzavbPvwc8mcjzDtCMsPRrSc12maq+8RRQXw@mail.gmail.com>
	<CAOFH+OaFiuu52Hjx113vDUc9jCLTgiHJ40NB_rAe5=St+Q42FA@mail.gmail.com>
	<CAOFH+OaQvR2-UkzGAk4shmsS=14VpAD9Vv5eR-kDiJEZOBCbuw@mail.gmail.com>
	<50045441-F7BF-4E3D-A1BD-EBDFAC1AF145@remap.ucla.edu>
	<2c95a909-1c80-42a7-9a24-86c6817b1dbb@EMHUB6.ad.ucla.edu>
	<CAOFH+ObwDXrcub_i-32on3DiEHs1BcY3BzctbOiFd7QHBQXxag@mail.gmail.com>
Message-ID: <392CEB99-F13B-4B8F-97A5-6D974553F5ED@remap.ucla.edu>

Attachment available until Jul 24, 2016
Hi Junxiao,

I?m sorry for not being clear.

What I meant is that all consumers start simultaneously and what I repeatedly observe, is that they are unable to catch up with the latest produced data in a synchronous manner, what is expected. Instead, chasing phase resolution happens one (or few) consumer(s) at a time. Consumers are identical and in the beginning express same interest - with rightmost child selector enabled.
Here <http://ec2-52-90-158-238.compute-1.amazonaws.com:3000/dashboard/db/ndn-rtc-test-real-time-metrics?panelId=4&fullscreen&from=1466801762500&to=1466801788564>  (login/pw: guest/ndnguest) you can see ?rebufferings stairs? - which indicate that consumer was not able to get any data, so it started over. It feels like NFD was answering one consumer (rightmost interest) at a time.

I attached pcap file for the first 1-1.5 minute of test.

Thanks,

Click to Download<https://www.icloud.com/attachment/?u=https%3A%2F%2Fcvws.icloud-content.com%2FB%2FAdRulud6r8_BY4vd72J_GQVNZHI-AeLSnnTgQcld-nvgVzN7Z_GtHJ9_%2F%24%7Bf%7D%3Fo%3DAgwqj8b1LMVHHqWZR-PPYNe7FzzAmKljnmnkr6belmoB%26v%3D1%26x%3D3%26a%3DBYwroCA2V-L8A32qNAEA_wHIAP8cA26V%26e%3D1469394993%26k%3D%24%7Buk%7D%26fl%3D%26r%3D99C31B47-7DEF-43CB-8B78-D0AE4F7374C1-1%26ckc%3Dcom.apple.largeattachment%26ckz%3DE0110155-E488-447F-B4BA-82EE81D675A1%26p%3D31%26s%3DpkkY7bUBQOFzVH8cMQBXiMArQ4s&uk=EcpJWzutnG_V_jNQnQGavg&f=capture.pcap.zip&sz=24784726>
capture.pcap.zip
24.8 MB

--
Peter Gusev

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

Software Engineer/Programmer Analyst @ REMAP UCLA

Video streaming/ICN networks/Creative Development

On Jun 24, 2016, at 10:35 AM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:

Hi Peter

"consumers join one-by-one" is an application layer behavior. I don't know what does that mean at network layer.
tcpdump at the router should be helpful as a start, however I can't say what is "enough".

Yours, Junxiao

On Wed, Jun 22, 2016 at 12:36 PM, Gusev, Peter <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>> wrote:
Hi Junxiao,

I ran more 1-to-10 tests recently (here are the results<http://ec2-52-90-158-238.compute-1.amazonaws.com:3000/dashboard/db/ndn-rtc-tests-test-run-overview?from=1466566688346&to=1466567022507&var-runtime=15m> of one out five tests) and observe an unusual behavior: consumers are not able to get data all simultaneously, instead - they join one-by-one. This can be seen from rebufferings graph<http://ec2-52-90-158-238.compute-1.amazonaws.com:3000/dashboard/db/ndn-rtc-tests-test-run-overview?from=1466566688346&to=1466567022507&var-runtime=15m&panelId=15&fullscreen> and incoming traffic graph<http://ec2-52-90-158-238.compute-1.amazonaws.com:3000/dashboard/db/ndn-rtc-tests-test-run-overview?from=1466566688346&to=1466567022507&panelId=20&fullscreen&var-runtime=15m>. I see that, consumers get timeouts for the initial interests.

Please, let me know what data do you need to analyze this (tcpdumps for hub is enough?).

Thanks,

--
Peter Gusev

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

From shijunxiao at email.arizona.edu  Sun Jun 26 17:07:43 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Sun, 26 Jun 2016 17:07:43 -0700
Subject: [Nfd-dev] 1-to-Many NDN-RTC test and hub strategy
In-Reply-To: <36062ebe-9ce9-432c-882b-21676fadf022@emhub4.ad.ucla.edu>
References: <CAOFH+OZL6JLoQZwenACp2a32ruucRbauPM_HuVTTxvzV+0LE0g@mail.gmail.com>
	<5CDE7BF2-2533-407C-A546-3C2A3241C3F7@remap.ucla.edu>
	<059000c3-9a62-47cc-a372-b06a1415a4df@emhub4.ad.ucla.edu>
	<CAOFH+ObxW9Ye4ymzavbPvwc8mcjzDtCMsPRrSc12maq+8RRQXw@mail.gmail.com>
	<CAOFH+OaFiuu52Hjx113vDUc9jCLTgiHJ40NB_rAe5=St+Q42FA@mail.gmail.com>
	<CAOFH+OaQvR2-UkzGAk4shmsS=14VpAD9Vv5eR-kDiJEZOBCbuw@mail.gmail.com>
	<50045441-F7BF-4E3D-A1BD-EBDFAC1AF145@remap.ucla.edu>
	<2c95a909-1c80-42a7-9a24-86c6817b1dbb@EMHUB6.ad.ucla.edu>
	<CAOFH+ObwDXrcub_i-32on3DiEHs1BcY3BzctbOiFd7QHBQXxag@mail.gmail.com>
	<36062ebe-9ce9-432c-882b-21676fadf022@emhub4.ad.ucla.edu>
Message-ID: <CAOFH+ObyH3Z3_GR0R80r0MgHjB+whPQJZEjWSgR7dmGda6D=1Q@mail.gmail.com>

Hi Peter

The trace is attached to https://redmine.named-data.net/issues/3642#note-12
for permanent record.
I can see a lot of Nack-Duplicates from the trace:
vagrant at m0212:~$ ndndump -r capture.pcap | grep -v 10.10.12.3 | sed -e
's/From: 10.10.12.//' -e 's/, To: 10.10.12./->/' -e 's/, Tunnel Type: UDP,
/ /' -e
's|/ndn/edu/ucla/remap/ndnrtc/user/client1/streams/camera/low/key|()|' |
grep 'Nonce=1732610923'
1466801763.692043 4->2 INTEREST:
()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801763.706693 7->2 INTEREST:
()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801763.706810 2->7 NACK: Duplicate,
()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801763.732589 6->2 INTEREST:
()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801763.732702 2->6 NACK: Duplicate,
()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801763.822424 12->2 INTEREST:
()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801763.822546 2->12 NACK: Duplicate,
()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801763.825780 9->2 INTEREST:
()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801763.825867 2->9 NACK: Duplicate,
()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801763.838540 10->2 INTEREST:
()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801763.838657 2->10 NACK: Duplicate,
()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801763.854087 5->2 INTEREST:
()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801763.854200 2->5 NACK: Duplicate,
()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801763.934206 11->2 INTEREST:
()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801763.934301 2->11 NACK: Duplicate,
()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801764.041182 8->2 INTEREST:
()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801764.041306 2->8 NACK: Duplicate,
()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801764.154624 13->2 INTEREST:
()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801764.154732 2->13 NACK: Duplicate,
()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923

Protocol requires Name+Nonce combination to be unique
<http://named-data.net/doc/ndn-tlv/interest.html#nonce>, but the same Nonce
is being used by consumer 4,7,6,12,9,10,5,11,8,13. As a result, all except
consumer 4 will not get Data.
Even if consumer 4 gets Data this time, if other consumers are still
generating the same stream of Nonces, the next Interest from consumer 4 may
arrive later than the duplicate Interest from other consumers, causing
consumer 4 to receive a Nack-Duplicate and therefore lose track of the
video stream.

This is either a bug in the library, or you are using the library
incorrectly. You may get more help on ndn-lib mailing list.

Yours, Junxiao

On Fri, Jun 24, 2016 at 2:16 PM, Gusev, Peter <peter at remap.ucla.edu> wrote:

>
> What I meant is that all consumers start simultaneously and what I
> repeatedly observe, is that they are unable to catch up with the latest
> produced data in a synchronous manner, what is expected. Instead, chasing
> phase resolution happens one (or few) consumer(s) at a time. Consumers are
> identical and in the beginning express same interest - with rightmost child
> selector enabled.
> Here
> <http://ec2-52-90-158-238.compute-1.amazonaws.com:3000/dashboard/db/ndn-rtc-test-real-time-metrics?panelId=4&fullscreen&from=1466801762500&to=1466801788564> (login/pw:
> guest/ndnguest) you can see ?rebufferings stairs? - which indicate that
> consumer was not able to get any data, so it started over. It feels like
> NFD was answering one consumer (rightmost interest) at a time.
>
> I attached pcap file for the first 1-1.5 minute of test.
>
>
>> I ran more 1-to-10 tests recently (here are the results
>> <http://ec2-52-90-158-238.compute-1.amazonaws.com:3000/dashboard/db/ndn-rtc-tests-test-run-overview?from=1466566688346&to=1466567022507&var-runtime=15m> of
>> one out five tests) and observe an unusual behavior: consumers are not able
>> to get data all simultaneously, instead - they join one-by-one. This can be
>> seen from rebufferings graph
>> <http://ec2-52-90-158-238.compute-1.amazonaws.com:3000/dashboard/db/ndn-rtc-tests-test-run-overview?from=1466566688346&to=1466567022507&var-runtime=15m&panelId=15&fullscreen>
>>  and incoming traffic graph
>> <http://ec2-52-90-158-238.compute-1.amazonaws.com:3000/dashboard/db/ndn-rtc-tests-test-run-overview?from=1466566688346&to=1466567022507&panelId=20&fullscreen&var-runtime=15m>.
>> I see that, consumers get timeouts for the initial interests.
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160626/6fa07438/attachment.html>

From shijunxiao at email.arizona.edu  Mon Jun 27 04:17:28 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Mon, 27 Jun 2016 04:17:28 -0700
Subject: [Nfd-dev] Let the World Reach Your NFD
Message-ID: <57710b4b.08d5620a.baedc.fffff0cf@mx.google.com>

Dear folks

If you are still trying to figure out how to get automated prefix propagation working, this article shall be useful for you.
https://yoursunny.com/t/2016/nfd-prefix/

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

From agawande at memphis.edu  Mon Jun 27 11:04:00 2016
From: agawande at memphis.edu (Ashlesh Gawande (agawande))
Date: Mon, 27 Jun 2016 18:04:00 +0000
Subject: [Nfd-dev] Help needed with debugging duplicate Nonce
Message-ID: <BN3PR04MB2196AE795C3741066D59A952D9210@BN3PR04MB2196.namprd04.prod.outlook.com>

Hi all


I was running a simple three node topology in Mini-NDN (no experiment, simply: sudo minindn topology_file):

                          a
                        /     \
                 10 /        \ 10
                     /           \
                    b----------c
                          10

a-eth0 (1.0.0.1)-b-eth0(1.0.0.2)
a-eth1(1.0.0.5)-c-eth0(1.0.0.6)
b-eth1(1.0.0.9)-c-eth1(1.0.0.10)

I have attached the topology file used.

ndn-cxx commit:  67cb75c7d8a61981cf21581702c955cc7d170642
NFD commit: 891f47bcfad45885408d1956657be5612620a12d
NLSR commit: af909fcc138ce18bd433edecc248ed2b60fc9737
ndn-tools commit: d2300731edd88593290ac0c33ed25d5b353b6634

I started tcpdump before NLSR starts on each node and then grepped for NACKs (all of them are duplicate NACKs).

Then I followed a particular Nonce (at random) to see how the duplicate NACK was generated:

Tcpdumps are attached in pcap format.
I just used ndndump -r to dump them to ndndump* files and grepped:

tmp$ grep --color=always 355693607 ndndump.* | sort -t: -k2
ndndump.c-eth1_1.0.0.6:1467048841.203507 From: 1.0.0.6, To: 1.0.0.5, Tunnel Type: UDP, INTEREST: /ndn/NLSR/sync/d34157d84d19a4f39c359c9794b2686cc061a7dc2411a44255c50a173c1cc89e?ndn.MustBeFresh=1&ndn.Nonce=355693607
ndndump.a-eth1_1.0.0.5:1467048841.203512 From: 1.0.0.6, To: 1.0.0.5, Tunnel Type: UDP, INTEREST: /ndn/NLSR/sync/d34157d84d19a4f39c359c9794b2686cc061a7dc2411a44255c50a173c1cc89e?ndn.MustBeFresh=1&ndn.Nonce=355693607
ndndump.c-eth0_1.0.0.10:1467048841.203513 From: 1.0.0.10, To: 1.0.0.9, Tunnel Type: UDP, INTEREST: /ndn/NLSR/sync/d34157d84d19a4f39c359c9794b2686cc061a7dc2411a44255c50a173c1cc89e?ndn.MustBeFresh=1&ndn.Nonce=355693607
ndndump.b-eth1_1.0.0.9:1467048841.203514 From: 1.0.0.10, To: 1.0.0.9, Tunnel Type: UDP, INTEREST: /ndn/NLSR/sync/d34157d84d19a4f39c359c9794b2686cc061a7dc2411a44255c50a173c1cc89e?ndn.MustBeFresh=1&ndn.Nonce=355693607
ndndump.b-eth0_1.0.0.2:1467048841.213733 From: 1.0.0.2, To: 1.0.0.1, Tunnel Type: UDP, INTEREST: /ndn/NLSR/sync/d34157d84d19a4f39c359c9794b2686cc061a7dc2411a44255c50a173c1cc89e?ndn.MustBeFresh=1&ndn.Nonce=355693607
ndndump.a-eth0_1.0.0.1:1467048841.213740 From: 1.0.0.2, To: 1.0.0.1, Tunnel Type: UDP, INTEREST: /ndn/NLSR/sync/d34157d84d19a4f39c359c9794b2686cc061a7dc2411a44255c50a173c1cc89e?ndn.MustBeFresh=1&ndn.Nonce=355693607
ndndump.a-eth0_1.0.0.1:1467048841.214191 From: 1.0.0.1, To: 1.0.0.2, Tunnel Type: UDP, INTEREST: /ndn/NLSR/sync/d34157d84d19a4f39c359c9794b2686cc061a7dc2411a44255c50a173c1cc89e?ndn.MustBeFresh=1&ndn.Nonce=355693607
ndndump.b-eth0_1.0.0.2:1467048841.214191 From: 1.0.0.1, To: 1.0.0.2, Tunnel Type: UDP, INTEREST: /ndn/NLSR/sync/d34157d84d19a4f39c359c9794b2686cc061a7dc2411a44255c50a173c1cc89e?ndn.MustBeFresh=1&ndn.Nonce=355693607
ndndump.a-eth0_1.0.0.1:1467048841.224056 From: 1.0.0.1, To: 1.0.0.2, Tunnel Type: UDP, NACK: Duplicate, /ndn/NLSR/sync/d34157d84d19a4f39c359c9794b2686cc061a7dc2411a44255c50a173c1cc89e?ndn.MustBeFresh=1&ndn.Nonce=355693607
ndndump.b-eth0_1.0.0.2:1467048841.224078 From: 1.0.0.1, To: 1.0.0.2, Tunnel Type: UDP, NACK: Duplicate, /ndn/NLSR/sync/d34157d84d19a4f39c359c9794b2686cc061a7dc2411a44255c50a173c1cc89e?ndn.MustBeFresh=1&ndn.Nonce=355693607
ndndump.a-eth0_1.0.0.1:1467048841.224360 From: 1.0.0.2, To: 1.0.0.1, Tunnel Type: UDP, NACK: Duplicate, /ndn/NLSR/sync/d34157d84d19a4f39c359c9794b2686cc061a7dc2411a44255c50a173c1cc89e?ndn.MustBeFresh=1&ndn.Nonce=355693607
ndndump.b-eth0_1.0.0.2:1467048841.224360 From: 1.0.0.2, To: 1.0.0.1, Tunnel Type: UDP, NACK: Duplicate, /ndn/NLSR/sync/d34157d84d19a4f39c359c9794b2686cc061a7dc2411a44255c50a173c1cc89e?ndn.MustBeFresh=1&ndn.Nonce=355693607

Seems like:
1) c sends interest to a
2) c sends same interest to b
3) b sends same interest to a
4) a sends same interest to b
5) a sends NACK [Duplicate] to b
6) b sends NACK [Duplicate] to a

Strategy is set as follows by NLSR:
mininet> a nfd-status -s
Strategy choices:
  / strategy=/localhost/nfd/strategy/best-route/%FD%04
  /ndn/NLSR/sync strategy=/localhost/nfd/strategy/multicast/%FD%01
  /localhost strategy=/localhost/nfd/strategy/multicast/%FD%01
  /ndn/broadcast strategy=/localhost/nfd/strategy/multicast/%FD%01
  /ndn/NLSR/LSA strategy=/localhost/nfd/strategy/multicast/%FD%01
  /ndn/broadcast/KEYS strategy=/localhost/nfd/strategy/multicast/%FD%01
  /localhost/nfd strategy=/localhost/nfd/strategy/best-route/%FD%04

So are these duplicate NACKs expected behavior?

Thanks
Ashlesh


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160627/e44dc7a0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dump.a-eth0_1.0.0.1.pcap
Type: application/vnd.tcpdump.pcap
Size: 17459 bytes
Desc: dump.a-eth0_1.0.0.1.pcap
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160627/e44dc7a0/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dump.a-eth1_1.0.0.5.pcap
Type: application/vnd.tcpdump.pcap
Size: 20527 bytes
Desc: dump.a-eth1_1.0.0.5.pcap
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160627/e44dc7a0/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dump.b-eth0_1.0.0.2.pcap
Type: application/vnd.tcpdump.pcap
Size: 17459 bytes
Desc: dump.b-eth0_1.0.0.2.pcap
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160627/e44dc7a0/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dump.b-eth1_1.0.0.9.pcap
Type: application/vnd.tcpdump.pcap
Size: 18852 bytes
Desc: dump.b-eth1_1.0.0.9.pcap
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160627/e44dc7a0/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dump.c-eth0_1.0.0.10.pcap
Type: application/vnd.tcpdump.pcap
Size: 18852 bytes
Desc: dump.c-eth0_1.0.0.10.pcap
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160627/e44dc7a0/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dump.c-eth1_1.0.0.6.pcap
Type: application/vnd.tcpdump.pcap
Size: 20527 bytes
Desc: dump.c-eth1_1.0.0.6.pcap
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160627/e44dc7a0/attachment-0005.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: default-topology.conf
Type: application/octet-stream
Size: 76 bytes
Desc: default-topology.conf
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160627/e44dc7a0/attachment.obj>

From shijunxiao at email.arizona.edu  Mon Jun 27 11:26:57 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Mon, 27 Jun 2016 11:26:57 -0700
Subject: [Nfd-dev] Help needed with debugging duplicate Nonce
In-Reply-To: <BN3PR04MB2196AE795C3741066D59A952D9210@BN3PR04MB2196.namprd04.prod.outlook.com>
References: <BN3PR04MB2196AE795C3741066D59A952D9210@BN3PR04MB2196.namprd04.prod.outlook.com>
Message-ID: <57716ff0.0617620a.1b687.2b5e@mx.google.com>

Hi Ashlesh

Just looking at the six transmissions you summarized, this should be expected behavior.
5. A returns Nack-Duplicate to B in reply to Interest 3, because the same Nonce is seen in Interest 1
6. B returns Nack-Duplicate to A in reply to Interest 4, because the same Nonce is seen in Interest 2

Afterwards, if either A or B has the Data, it would go to consumer C.

Yours, Junxiao

From: Ashlesh Gawande (agawande)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160627/78f6eb06/attachment.html>

From lanwang at memphis.edu  Mon Jun 27 11:30:42 2016
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Mon, 27 Jun 2016 18:30:42 +0000
Subject: [Nfd-dev] Help needed with debugging duplicate Nonce
In-Reply-To: <57716ff0.0617620a.1b687.2b5e@mx.google.com>
References: <BN3PR04MB2196AE795C3741066D59A952D9210@BN3PR04MB2196.namprd04.prod.outlook.com>
	<57716ff0.0617620a.1b687.2b5e@mx.google.com>
Message-ID: <EFB45FC7-40CA-4C6C-9B98-2BAF1E74C433@memphis.edu>

We used /localhop in the name.  Why were the packets forwarded beyond one hop?

Lan

On Jun 27, 2016, at 1:26 PM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:

Hi Ashlesh

Just looking at the six transmissions you summarized, this should be expected behavior.
5. A returns Nack-Duplicate to B in reply to Interest 3, because the same Nonce is seen in Interest 1
6. B returns Nack-Duplicate to A in reply to Interest 4, because the same Nonce is seen in Interest 2

Afterwards, if either A or B has the Data, it would go to consumer C.

Yours, Junxiao

From: Ashlesh Gawande (agawande)<mailto:agawande at memphis.edu>
Sent: Monday, June 27, 2016 11:04
To: nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>
Subject: [Nfd-dev] Help needed with debugging duplicate Nonce

Hi all

I was running a simple three node topology in Mini-NDN (no experiment, simply: sudo minindn topology_file):

                          a
                        /     \
                 10 /        \ 10
                     /           \
                    b----------c
                          10

Seems like:
1) c sends interest to a
2) c sends same interest to b
3) b sends same interest to a
4) a sends same interest to b
5) a sends NACK [Duplicate] to b
6) b sends NACK [Duplicate] to a

So are these duplicate NACKs expected behavior?


_______________________________________________
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/20160627/2b6e7019/attachment.html>

From agawande at memphis.edu  Mon Jun 27 11:33:47 2016
From: agawande at memphis.edu (Ashlesh Gawande (agawande))
Date: Mon, 27 Jun 2016 18:33:47 +0000
Subject: [Nfd-dev] Help needed with debugging duplicate Nonce
In-Reply-To: <EFB45FC7-40CA-4C6C-9B98-2BAF1E74C433@memphis.edu>
References: <BN3PR04MB2196AE795C3741066D59A952D9210@BN3PR04MB2196.namprd04.prod.outlook.com>
	<57716ff0.0617620a.1b687.2b5e@mx.google.com>,
	<EFB45FC7-40CA-4C6C-9B98-2BAF1E74C433@memphis.edu>
Message-ID: <BN3PR04MB2196BD630C500CDF2487D113D9210@BN3PR04MB2196.namprd04.prod.outlook.com>

On the latest experiment (which used tcpdump rather than ndndump) whose data I attached I didn't use /localhop - I can use it and send it again?

(The earlier one I sent to Junxiao had the /localhop)


Ashlesh

________________________________
From: Lan Wang (lanwang)
Sent: Monday, June 27, 2016 1:30:42 PM
To: Junxiao Shi
Cc: Ashlesh Gawande (agawande); nfd-dev at lists.cs.ucla.edu
Subject: Re: [Nfd-dev] Help needed with debugging duplicate Nonce

We used /localhop in the name.  Why were the packets forwarded beyond one hop?

Lan

On Jun 27, 2016, at 1:26 PM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:

Hi Ashlesh

Just looking at the six transmissions you summarized, this should be expected behavior.
5. A returns Nack-Duplicate to B in reply to Interest 3, because the same Nonce is seen in Interest 1
6. B returns Nack-Duplicate to A in reply to Interest 4, because the same Nonce is seen in Interest 2

Afterwards, if either A or B has the Data, it would go to consumer C.

Yours, Junxiao

From: Ashlesh Gawande (agawande)<mailto:agawande at memphis.edu>
Sent: Monday, June 27, 2016 11:04
To: nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>
Subject: [Nfd-dev] Help needed with debugging duplicate Nonce

Hi all

I was running a simple three node topology in Mini-NDN (no experiment, simply: sudo minindn topology_file):

                          a
                        /     \
                 10 /        \ 10
                     /           \
                    b----------c
                          10

Seems like:
1) c sends interest to a
2) c sends same interest to b
3) b sends same interest to a
4) a sends same interest to b
5) a sends NACK [Duplicate] to b
6) b sends NACK [Duplicate] to a

So are these duplicate NACKs expected behavior?


_______________________________________________
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/20160627/91417276/attachment.html>

From peter at remap.UCLA.edu  Mon Jun 27 11:39:52 2016
From: peter at remap.UCLA.edu (Gusev, Peter)
Date: Mon, 27 Jun 2016 18:39:52 +0000
Subject: [Nfd-dev] 1-to-Many NDN-RTC test and hub strategy
In-Reply-To: <CAOFH+ObyH3Z3_GR0R80r0MgHjB+whPQJZEjWSgR7dmGda6D=1Q@mail.gmail.com>
References: <CAOFH+OZL6JLoQZwenACp2a32ruucRbauPM_HuVTTxvzV+0LE0g@mail.gmail.com>
	<5CDE7BF2-2533-407C-A546-3C2A3241C3F7@remap.ucla.edu>
	<059000c3-9a62-47cc-a372-b06a1415a4df@emhub4.ad.ucla.edu>
	<CAOFH+ObxW9Ye4ymzavbPvwc8mcjzDtCMsPRrSc12maq+8RRQXw@mail.gmail.com>
	<CAOFH+OaFiuu52Hjx113vDUc9jCLTgiHJ40NB_rAe5=St+Q42FA@mail.gmail.com>
	<CAOFH+OaQvR2-UkzGAk4shmsS=14VpAD9Vv5eR-kDiJEZOBCbuw@mail.gmail.com>
	<50045441-F7BF-4E3D-A1BD-EBDFAC1AF145@remap.ucla.edu>
	<2c95a909-1c80-42a7-9a24-86c6817b1dbb@EMHUB6.ad.ucla.edu>
	<CAOFH+ObwDXrcub_i-32on3DiEHs1BcY3BzctbOiFd7QHBQXxag@mail.gmail.com>
	<36062ebe-9ce9-432c-882b-21676fadf022@emhub4.ad.ucla.edu>
	<CAOFH+ObyH3Z3_GR0R80r0MgHjB+whPQJZEjWSgR7dmGda6D=1Q@mail.gmail.com>
Message-ID: <C6CC32A9-5AA7-4799-97DA-3D0BC2FEE3ED@remap.ucla.edu>

Hi Junxiao,

Thanks for your input. I think I might know what the problem is. It?s in NDN-RTC library, as nonce values are being set by NDN-RTC currently.
Jeff Thompson introduced refreshNonce() which uses crypto library for nonce generation. Once I update NDN-RTC to the latest NDN-CPP, this should provide better results.
In any way, currently, NDN-RTC needs to know expressed Interests nonce values to track incoming data.

Thanks,

--
Peter Gusev

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

Software Engineer/Programmer Analyst @ REMAP UCLA

Video streaming/ICN networks/Creative Development

On Jun 26, 2016, at 5:07 PM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:

Hi Peter

The trace is attached to https://redmine.named-data.net/issues/3642#note-12 for permanent record.
I can see a lot of Nack-Duplicates from the trace:
vagrant at m0212:~$ ndndump -r capture.pcap | grep -v 10.10.12.3 | sed -e 's/From: 10.10.12.//<http://10.10.12.//>' -e 's/, To: 10.10.12./-<http://10.10.12./->>/' -e 's/, Tunnel Type: UDP, / /' -e 's|/ndn/edu/ucla/remap/ndnrtc/user/client1/streams/camera/low/key|()|' | grep 'Nonce=1732610923'
1466801763.692043 4->2 INTEREST: ()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801763.706693 7->2 INTEREST: ()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801763.706810 2->7 NACK: Duplicate, ()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801763.732589 6->2 INTEREST: ()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801763.732702 2->6 NACK: Duplicate, ()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801763.822424 12->2 INTEREST: ()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801763.822546 2->12 NACK: Duplicate, ()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801763.825780 9->2 INTEREST: ()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801763.825867 2->9 NACK: Duplicate, ()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801763.838540 10->2 INTEREST: ()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801763.838657 2->10 NACK: Duplicate, ()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801763.854087 5->2 INTEREST: ()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801763.854200 2->5 NACK: Duplicate, ()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801763.934206 11->2 INTEREST: ()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801763.934301 2->11 NACK: Duplicate, ()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801764.041182 8->2 INTEREST: ()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801764.041306 2->8 NACK: Duplicate, ()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801764.154624 13->2 INTEREST: ()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923
1466801764.154732 2->13 NACK: Duplicate, ()/2/data/%00%00?ndn.MustBeFresh=1&ndn.InterestLifetime=3000&ndn.Nonce=1732610923

Protocol requires Name+Nonce combination to be unique<http://named-data.net/doc/ndn-tlv/interest.html#nonce>, but the same Nonce is being used by consumer 4,7,6,12,9,10,5,11,8,13. As a result, all except consumer 4 will not get Data.
Even if consumer 4 gets Data this time, if other consumers are still generating the same stream of Nonces, the next Interest from consumer 4 may arrive later than the duplicate Interest from other consumers, causing consumer 4 to receive a Nack-Duplicate and therefore lose track of the video stream.

This is either a bug in the library, or you are using the library incorrectly. You may get more help on ndn-lib mailing list.

Yours, Junxiao

On Fri, Jun 24, 2016 at 2:16 PM, Gusev, Peter <peter at remap.ucla.edu<mailto:peter at remap.ucla.edu>> wrote:

What I meant is that all consumers start simultaneously and what I repeatedly observe, is that they are unable to catch up with the latest produced data in a synchronous manner, what is expected. Instead, chasing phase resolution happens one (or few) consumer(s) at a time. Consumers are identical and in the beginning express same interest - with rightmost child selector enabled.
Here <http://ec2-52-90-158-238.compute-1.amazonaws.com:3000/dashboard/db/ndn-rtc-test-real-time-metrics?panelId=4&fullscreen&from=1466801762500&to=1466801788564>  (login/pw: guest/ndnguest) you can see ?rebufferings stairs? - which indicate that consumer was not able to get any data, so it started over. It feels like NFD was answering one consumer (rightmost interest) at a time.

I attached pcap file for the first 1-1.5 minute of test.


I ran more 1-to-10 tests recently (here are the results<http://ec2-52-90-158-238.compute-1.amazonaws.com:3000/dashboard/db/ndn-rtc-tests-test-run-overview?from=1466566688346&to=1466567022507&var-runtime=15m> of one out five tests) and observe an unusual behavior: consumers are not able to get data all simultaneously, instead - they join one-by-one. This can be seen from rebufferings graph<http://ec2-52-90-158-238.compute-1.amazonaws.com:3000/dashboard/db/ndn-rtc-tests-test-run-overview?from=1466566688346&to=1466567022507&var-runtime=15m&panelId=15&fullscreen> and incoming traffic graph<http://ec2-52-90-158-238.compute-1.amazonaws.com:3000/dashboard/db/ndn-rtc-tests-test-run-overview?from=1466566688346&to=1466567022507&panelId=20&fullscreen&var-runtime=15m>. I see that, consumers get timeouts for the initial interests.



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

From shijunxiao at email.arizona.edu  Mon Jun 27 12:59:56 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Mon, 27 Jun 2016 12:59:56 -0700
Subject: [Nfd-dev] Help needed with debugging duplicate Nonce
In-Reply-To: <EFB45FC7-40CA-4C6C-9B98-2BAF1E74C433@memphis.edu>
References: <BN3PR04MB2196AE795C3741066D59A952D9210@BN3PR04MB2196.namprd04.prod.outlook.com>
	<57716ff0.0617620a.1b687.2b5e@mx.google.com>
	<EFB45FC7-40CA-4C6C-9B98-2BAF1E74C433@memphis.edu>
Message-ID: <CAOFH+OZ4W+sBwWNPXfrQGXUR5scvKQ51qXeP1RsKRDuNj3tGzg@mail.gmail.com>

Hi Lan

The Interest name is the snippet is:
/ndn/NLSR/sync/d34157d84d19a4f39c359c9794b2686cc061a7dc2411a44255c50a173c1cc89e
There's no /localhop is this name.

In general, if you find NFD forwarding a /localhop Interest, this means a
local application is expressing the Interest.
In A-B-C linear topology, when A expresses an Interest and is forwarded to
B, B usually does not forward it to C. However, if a local application on B
expresses an Interest with same Name+Selectors+Link, B can forward this
Interest to C.
If you are suspecting this problem, you may force the application on B to
connect to local NFD via TCP by setting `transport=tcp4://127.0.0.1:6363`
in $HOME/.ndn/client.conf, and then you'll be able to run tcpdump on the
loopback interface and observe whether any local application is expressing
the Interest.

Yours, Junxiao

On Mon, Jun 27, 2016 at 11:30 AM, Lan Wang (lanwang) <lanwang at memphis.edu>
wrote:

> We used /localhop in the name.  Why were the packets forwarded beyond one
> hop?
>
> Lan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160627/b5ed1724/attachment.html>

From zhangjqsmiling at icloud.com  Mon Jun 27 20:33:26 2016
From: zhangjqsmiling at icloud.com (Jingqing Zhang)
Date: Tue, 28 Jun 2016 11:33:26 +0800
Subject: [Nfd-dev] NFD configuration problem on ethernet
Message-ID: <B815B181-6DF2-4EB8-A7D3-31F1F9EE66AF@icloud.com>

Dear NFD team,

This is Jingqing from Tsinghua University, China. We are trying to run applications on NFD for our project. And we encountered a problem when we were trying to configure NFD on ethernet.

We have connected 2 Macbooks together in the ad-hoc wireless mode and they worked fine by the following command:

?nfdc create udp://169.254.25.249 <udp://169.254.25.249>" on Macbook1
?nfdc create udp://169.254.178.227 <udp://169.254.178.227>" on Mackbok2.

However, when we were trying to connect them on ethernet (in the ad-hoc wireless mode) using command:
"nfdc create ether://[ac:bc:32:ac:dd:b9] <ether://[ac:bc:32:ac:dd:b9]>? on Macbook1

we got this error:
"zsh: no matches found: ether://[ac:bc:32:ac:dd:b9] <ether://[ac:bc:32:ac:dd:b9]>"

It is strange that this error was alerted by zsh, rather than NFD. The same error occurred on the other Macbook. 

Do you have any idea on why this happened? Thank you very much!

Best wishes!
--
Jingqing Zhang
Department of Computer Science and Technology, Tsinghua University
Undergraduate Student

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

From susmit at cs.colostate.edu  Mon Jun 27 22:16:15 2016
From: susmit at cs.colostate.edu (Susmit)
Date: Mon, 27 Jun 2016 23:16:15 -0600
Subject: [Nfd-dev] NFD configuration problem on ethernet
In-Reply-To: <B815B181-6DF2-4EB8-A7D3-31F1F9EE66AF@icloud.com>
References: <B815B181-6DF2-4EB8-A7D3-31F1F9EE66AF@icloud.com>
Message-ID: <CAM4XVkrfuLmHS9bMOo0BWc94-Sr2S6kLzyw64-4rh_R3TaTwAA@mail.gmail.com>

Hi,

You need to use the face number, e.g, nfdc register / 32.

https://redmine.named-data.net/issues/3276

On Mon, Jun 27, 2016 at 9:33 PM, Jingqing Zhang
<zhangjqsmiling at icloud.com> wrote:
> Dear NFD team,
>
> This is Jingqing from Tsinghua University, China. We are trying to run
> applications on NFD for our project. And we encountered a problem when we
> were trying to configure NFD on ethernet.
>
> We have connected 2 Macbooks together in the ad-hoc wireless mode and they
> worked fine by the following command:
>
> ?nfdc create udp://169.254.25.249" on Macbook1
> ?nfdc create udp://169.254.178.227" on Mackbok2.
>
> However, when we were trying to connect them on ethernet (in the ad-hoc
> wireless mode) using command:
> "nfdc create ether://[ac:bc:32:ac:dd:b9]? on Macbook1
>
> we got this error:
> "zsh: no matches found: ether://[ac:bc:32:ac:dd:b9]"
>
> It is strange that this error was alerted by zsh, rather than NFD. The same
> error occurred on the other Macbook.
>
> Do you have any idea on why this happened? Thank you very much!
>
> Best wishes!
> --
> Jingqing Zhang
> Department of Computer Science and Technology, Tsinghua University
> Undergraduate Student
>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>



-- 

Regards,
Susmit

====================================
http://www.cs.colostate.edu/~susmit
====================================



From zhangjqsmiling at icloud.com  Mon Jun 27 22:22:04 2016
From: zhangjqsmiling at icloud.com (Jingqing Zhang)
Date: Tue, 28 Jun 2016 13:22:04 +0800
Subject: [Nfd-dev] NFD configuration problem on ethernet
In-Reply-To: <CAM4XVkrfuLmHS9bMOo0BWc94-Sr2S6kLzyw64-4rh_R3TaTwAA@mail.gmail.com>
References: <B815B181-6DF2-4EB8-A7D3-31F1F9EE66AF@icloud.com>
	<CAM4XVkrfuLmHS9bMOo0BWc94-Sr2S6kLzyw64-4rh_R3TaTwAA@mail.gmail.com>
Message-ID: <F69B8FC0-C1B3-4870-8131-BB67D5F6950F@icloud.com>

Thanks for your information!

If I got it right, ?nfdc create? command could create a face and get the face number which I could use in ?nfdc register? command. I think the problem is that I can?t create an ethernet face and the error was alerted by my terminal zsh rather than nfdc. 

Best wishes!
--
Jingqing Zhang
Department of Computer Science and Technology, Tsinghua University
Undergraduate Student

> On Jun 28, 2016, at 1:16 PM, Susmit <susmit at cs.colostate.edu> wrote:
> 
> Hi,
> 
> You need to use the face number, e.g, nfdc register / 32.
> 
> https://redmine.named-data.net/issues/3276
> 
> On Mon, Jun 27, 2016 at 9:33 PM, Jingqing Zhang
> <zhangjqsmiling at icloud.com> wrote:
>> Dear NFD team,
>> 
>> This is Jingqing from Tsinghua University, China. We are trying to run
>> applications on NFD for our project. And we encountered a problem when we
>> were trying to configure NFD on ethernet.
>> 
>> We have connected 2 Macbooks together in the ad-hoc wireless mode and they
>> worked fine by the following command:
>> 
>> ?nfdc create udp://169.254.25.249" on Macbook1
>> ?nfdc create udp://169.254.178.227" on Mackbok2.
>> 
>> However, when we were trying to connect them on ethernet (in the ad-hoc
>> wireless mode) using command:
>> "nfdc create ether://[ac:bc:32:ac:dd:b9]? on Macbook1
>> 
>> we got this error:
>> "zsh: no matches found: ether://[ac:bc:32:ac:dd:b9]"
>> 
>> It is strange that this error was alerted by zsh, rather than NFD. The same
>> error occurred on the other Macbook.
>> 
>> Do you have any idea on why this happened? Thank you very much!
>> 
>> Best wishes!
>> --
>> Jingqing Zhang
>> Department of Computer Science and Technology, Tsinghua University
>> Undergraduate Student
>> 
>> 
>> _______________________________________________
>> Nfd-dev mailing list
>> Nfd-dev at lists.cs.ucla.edu
>> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>> 
> 
> 
> 
> -- 
> 
> Regards,
> Susmit
> 
> ====================================
> http://www.cs.colostate.edu/~susmit
> ====================================




From enewberry at email.arizona.edu  Mon Jun 27 22:27:27 2016
From: enewberry at email.arizona.edu (Eric Newberry)
Date: Mon, 27 Jun 2016 22:27:27 -0700
Subject: [Nfd-dev] NFD configuration problem on ethernet
In-Reply-To: <B815B181-6DF2-4EB8-A7D3-31F1F9EE66AF@icloud.com>
References: <B815B181-6DF2-4EB8-A7D3-31F1F9EE66AF@icloud.com>
Message-ID: <265b20f9-6d38-0ab0-e779-729892f7fc8f@email.arizona.edu>

I believe this issue is being caused by the square brackets in the 
address, which are used for pattern matching in zsh. Try surrounding 
this portion with single quotes, like this:

nfdc create 'ether://[ac:bc:32:ac:dd:b9]'

Eric

On 6/27/2016 8:33 PM, Jingqing Zhang wrote:
> Dear NFD team,
>
> This is Jingqing from Tsinghua University, China. We are trying to run 
> applications on NFD for our project. And we encountered a problem when 
> we were trying to configure NFD on ethernet.
>
> We have connected 2 Macbooks together in the ad-hoc wireless mode and 
> they worked fine by the following command:
>
> ?nfdc create udp://169.254.25.249" on Macbook1
> ?nfdc create udp://169.254.178.227" on Mackbok2.
>
> However, when we were trying to connect them on ethernet (in the 
> ad-hoc wireless mode) using command:
> "nfdc create ether://[ac:bc:32:ac:dd:b9]? on Macbook1
>
> we got this error:
> "zsh: no matches found: ether://[ac:bc:32:ac:dd:b9]"
>
> It is strange that this error was alerted by zsh, rather than NFD. The 
> same error occurred on the other Macbook.
>
> Do you have any idea on why this happened? Thank you very much!
>
> Best wishes!
> --
> Jingqing Zhang
> Department of Computer Science and Technology, Tsinghua University
> Undergraduate Student
>
>
>
> _______________________________________________
> 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/20160627/304c897d/attachment.html>

From lanwang at memphis.edu  Tue Jun 28 03:43:44 2016
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Tue, 28 Jun 2016 10:43:44 +0000
Subject: [Nfd-dev] Help needed with debugging duplicate Nonce
In-Reply-To: <CAOFH+OZ4W+sBwWNPXfrQGXUR5scvKQ51qXeP1RsKRDuNj3tGzg@mail.gmail.com>
References: <BN3PR04MB2196AE795C3741066D59A952D9210@BN3PR04MB2196.namprd04.prod.outlook.com>
	<57716ff0.0617620a.1b687.2b5e@mx.google.com>
	<EFB45FC7-40CA-4C6C-9B98-2BAF1E74C433@memphis.edu>
	<CAOFH+OZ4W+sBwWNPXfrQGXUR5scvKQ51qXeP1RsKRDuNj3tGzg@mail.gmail.com>
Message-ID: <E414F19D-2637-4AF4-8A1E-6525C9F7A7CE@memphis.edu>

Junxiao,

Yes, we observe the same interest forwarding behavior when using /localhop.  I think the reason why the /localhop interest is forwarded beyond one hop is because every node is expressing the same interest -- in ChronoSync when every node reaches consistency, they have the same digest so they have the same sync interest.

We tried to use /localhop to force the sync interest to be one hop.  Otherwise, as you can see in the trace, when the sync interest is forwarded, it causes duplicate NACK and basically it cancels that sync interest.  In order for sync to work correctly, we need to have a pending sync interest in each direction of a link, if the sync interest is canceled by the NACK, then if a node has a change, it cannot respond to the pending sync interest and therefore cannot propagate any changes.  This is what we observed when running NLSR after duplicate NACK was implemented.  There are a lot of duplicate NACKs and the convergence of NLSR is affected.

This is a problem that will affect every protocol that uses sync.

Why was the forwarding of /localhop becomes non local hop if the receiving node is expressing the same interest?

Lan

On Jun 27, 2016, at 2:59 PM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:

Hi Lan

The Interest name is the snippet is: /ndn/NLSR/sync/d34157d84d19a4f39c359c9794b2686cc061a7dc2411a44255c50a173c1cc89e
There's no /localhop is this name.

In general, if you find NFD forwarding a /localhop Interest, this means a local application is expressing the Interest.
In A-B-C linear topology, when A expresses an Interest and is forwarded to B, B usually does not forward it to C. However, if a local application on B expresses an Interest with same Name+Selectors+Link, B can forward this Interest to C.
If you are suspecting this problem, you may force the application on B to connect to local NFD via TCP by setting `transport=tcp4://127.0.0.1:6363` in $HOME/.ndn/client.conf, and then you'll be able to run tcpdump on the loopback interface and observe whether any local application is expressing the Interest.

Yours, Junxiao

On Mon, Jun 27, 2016 at 11:30 AM, Lan Wang (lanwang) <lanwang at memphis.edu<mailto:lanwang at memphis.edu>> wrote:
We used /localhop in the name.  Why were the packets forwarded beyond one hop?

Lan


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

From agawande at memphis.edu  Tue Jun 28 08:48:35 2016
From: agawande at memphis.edu (Ashlesh Gawande (agawande))
Date: Tue, 28 Jun 2016 15:48:35 +0000
Subject: [Nfd-dev] Help needed with debugging duplicate Nonce
In-Reply-To: <E414F19D-2637-4AF4-8A1E-6525C9F7A7CE@memphis.edu>
References: <BN3PR04MB2196AE795C3741066D59A952D9210@BN3PR04MB2196.namprd04.prod.outlook.com>
	<57716ff0.0617620a.1b687.2b5e@mx.google.com>
	<EFB45FC7-40CA-4C6C-9B98-2BAF1E74C433@memphis.edu>
	<CAOFH+OZ4W+sBwWNPXfrQGXUR5scvKQ51qXeP1RsKRDuNj3tGzg@mail.gmail.com>,
	<E414F19D-2637-4AF4-8A1E-6525C9F7A7CE@memphis.edu>
Message-ID: <BN3PR04MB2196A8CFF7A5F364CE289C6AD9220@BN3PR04MB2196.namprd04.prod.outlook.com>

Have attached proof for the said observation.


tmp-localhost_6_27$ grep --color=always 927845950 */ndndump* | sort -t: -k2
c/ndndump.c-eth0_1.0.0.10.pcap:1467054254.052399 From: 1.0.0.10, To: 1.0.0.9, Tunnel Type: UDP, INTEREST: /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
b/ndndump.b-eth1_1.0.0.9.pcap:1467054254.052424 From: 1.0.0.10, To: 1.0.0.9, Tunnel Type: UDP, INTEREST: /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
c/ndndump.c-eth1_1.0.0.6.pcap:1467054254.052428 From: 1.0.0.6, To: 1.0.0.5, Tunnel Type: UDP, INTEREST: /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
a/ndndump.a-eth1_1.0.0.5.pcap:1467054254.052436 From: 1.0.0.6, To: 1.0.0.5, Tunnel Type: UDP, INTEREST: /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
b/ndndump.b-eth0_1.0.0.2.pcap:1467054257.955331 From: 1.0.0.2, To: 1.0.0.1, Tunnel Type: UDP, INTEREST: /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
a/ndndump.a-eth0_1.0.0.1.pcap:1467054257.955348 From: 1.0.0.2, To: 1.0.0.1, Tunnel Type: UDP, INTEREST: /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
a/ndndump.a-eth0_1.0.0.1.pcap:1467054257.965760 From: 1.0.0.1, To: 1.0.0.2, Tunnel Type: UDP, NACK: Duplicate, /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
b/ndndump.b-eth0_1.0.0.2.pcap:1467054257.965760 From: 1.0.0.1, To: 1.0.0.2, Tunnel Type: UDP, NACK: Duplicate, /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950


1) c to b

2) c to a

3) b to a

4) a responds with duplicate NACK


Meanwhile I will also try to test Junxiao's suggestion by forcing communication over TCP and make sure that this is because of local sync expressing the same interest.

Ashlesh

________________________________
From: Lan Wang (lanwang)
Sent: Tuesday, June 28, 2016 5:43 AM
To: Junxiao Shi
Cc: Ashlesh Gawande (agawande); nfd-dev at lists.cs.ucla.edu
Subject: Re: [Nfd-dev] Help needed with debugging duplicate Nonce

Junxiao,

Yes, we observe the same interest forwarding behavior when using /localhop.  I think the reason why the /localhop interest is forwarded beyond one hop is because every node is expressing the same interest -- in ChronoSync when every node reaches consistency, they have the same digest so they have the same sync interest.

We tried to use /localhop to force the sync interest to be one hop.  Otherwise, as you can see in the trace, when the sync interest is forwarded, it causes duplicate NACK and basically it cancels that sync interest.  In order for sync to work correctly, we need to have a pending sync interest in each direction of a link, if the sync interest is canceled by the NACK, then if a node has a change, it cannot respond to the pending sync interest and therefore cannot propagate any changes.  This is what we observed when running NLSR after duplicate NACK was implemented.  There are a lot of duplicate NACKs and the convergence of NLSR is affected.

This is a problem that will affect every protocol that uses sync.

Why was the forwarding of /localhop becomes non local hop if the receiving node is expressing the same interest?

Lan

On Jun 27, 2016, at 2:59 PM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:

Hi Lan

The Interest name is the snippet is: /ndn/NLSR/sync/d34157d84d19a4f39c359c9794b2686cc061a7dc2411a44255c50a173c1cc89e
There's no /localhop is this name.

In general, if you find NFD forwarding a /localhop Interest, this means a local application is expressing the Interest.
In A-B-C linear topology, when A expresses an Interest and is forwarded to B, B usually does not forward it to C. However, if a local application on B expresses an Interest with same Name+Selectors+Link, B can forward this Interest to C.
If you are suspecting this problem, you may force the application on B to connect to local NFD via TCP by setting `transport=tcp4://127.0.0.1:6363` in $HOME/.ndn/client.conf, and then you'll be able to run tcpdump on the loopback interface and observe whether any local application is expressing the Interest.

Yours, Junxiao

On Mon, Jun 27, 2016 at 11:30 AM, Lan Wang (lanwang) <lanwang at memphis.edu> wrote:
We used /localhop in the name.  Why were the packets forwarded beyond one hop?

Lan


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160628/d1831feb/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dump.a-eth0_1.0.0.1.pcap
Type: application/vnd.tcpdump.pcap
Size: 17459 bytes
Desc: dump.a-eth0_1.0.0.1.pcap
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160628/d1831feb/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dump.a-eth1_1.0.0.5.pcap
Type: application/vnd.tcpdump.pcap
Size: 20527 bytes
Desc: dump.a-eth1_1.0.0.5.pcap
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160628/d1831feb/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dump.b-eth0_1.0.0.2.pcap
Type: application/vnd.tcpdump.pcap
Size: 17459 bytes
Desc: dump.b-eth0_1.0.0.2.pcap
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160628/d1831feb/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dump.b-eth1_1.0.0.9.pcap
Type: application/vnd.tcpdump.pcap
Size: 18852 bytes
Desc: dump.b-eth1_1.0.0.9.pcap
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160628/d1831feb/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dump.c-eth0_1.0.0.10.pcap
Type: application/vnd.tcpdump.pcap
Size: 18852 bytes
Desc: dump.c-eth0_1.0.0.10.pcap
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160628/d1831feb/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dump.c-eth1_1.0.0.6.pcap
Type: application/vnd.tcpdump.pcap
Size: 20527 bytes
Desc: dump.c-eth1_1.0.0.6.pcap
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160628/d1831feb/attachment-0005.bin>

From shijunxiao at email.arizona.edu  Tue Jun 28 08:57:20 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Tue, 28 Jun 2016 08:57:20 -0700
Subject: [Nfd-dev] NFD configuration problem on ethernet
In-Reply-To: <B815B181-6DF2-4EB8-A7D3-31F1F9EE66AF@icloud.com>
References: <B815B181-6DF2-4EB8-A7D3-31F1F9EE66AF@icloud.com>
Message-ID: <5D8E5557-06FD-4343-AB23-B8F29B51644E@email.arizona.edu>

Hi Jingqing

NFD does not support Ethernet unicast. The rationale of this design choice is described in NFD developer guide, ?Ethernet transport? section.
You may use Ethernet multicast by first finding the FaceId of an auto-created Ethernet multicast face via `nfd-status -f`, and use that FaceId in nfdc register command.

Yours, Junxiao

> On Jun 27, 2016, at 8:33 PM, Jingqing Zhang <zhangjqsmiling at icloud.com> wrote:
> 
> Dear NFD team,
> 
> This is Jingqing from Tsinghua University, China. We are trying to run applications on NFD for our project. And we encountered a problem when we were trying to configure NFD on ethernet.
> 
> We have connected 2 Macbooks together in the ad-hoc wireless mode and they worked fine by the following command:
> 
> ?nfdc create udp://169.254.25.249 <udp://169.254.25.249>" on Macbook1
> ?nfdc create udp://169.254.178.227 <udp://169.254.178.227>" on Mackbok2.
> 
> However, when we were trying to connect them on ethernet (in the ad-hoc wireless mode) using command:
> "nfdc create ether://[ac:bc:32:ac:dd:b9] <ether://[ac:bc:32:ac:dd:b9]>? on Macbook1
> 
> we got this error:
> "zsh: no matches found: ether://[ac:bc:32:ac:dd:b9] <ether://[ac:bc:32:ac:dd:b9]>"
> 
> It is strange that this error was alerted by zsh, rather than NFD. The same error occurred on the other Macbook. 
> 
> Do you have any idea on why this happened? Thank you very much!
> 
> Best wishes!
> --
> Jingqing Zhang
> Department of Computer Science and Technology, Tsinghua University
> Undergraduate Student
> 
> _______________________________________________
> 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/20160628/f1e89f24/attachment.html>

From nfd-call-notification at mail1.yoursunny.com  Tue Jun 28 10:00:02 2016
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Tue, 28 Jun 2016 10:00:02 -0700
Subject: [Nfd-dev] NFD call 20160628
Message-ID: <201606281700.u5SH02uH004895@lectura.cs.arizona.edu>

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

From lanwang at memphis.edu  Tue Jun 28 10:04:18 2016
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Tue, 28 Jun 2016 17:04:18 +0000
Subject: [Nfd-dev] a question about PIT entry
Message-ID: <536DB9C4-02C9-4212-8FED-CDB364EC540F@memphis.edu>

Hi,

I have a question about how to keep a PIT entry in a particular situation.  Suppose there are two nodes:

a ? b

1) a and b both send the same interests (same name) to each other.
2) a responds to b?s interest with a data packet.  In the current PIT implementation, it will remove both a and b's PIT entry for this interest.

We hope that a?s data packet would not erase the PIT entry in a and b completely (only remove the necessary in and out records) so that b can still respond to a?s interest.

This is inspired by a partialsync implementation issue.  Is there any way to achieve this result?

Lan




From agawande at memphis.edu  Tue Jun 28 10:29:35 2016
From: agawande at memphis.edu (Ashlesh Gawande (agawande))
Date: Tue, 28 Jun 2016 17:29:35 +0000
Subject: [Nfd-dev] Help needed with debugging duplicate Nonce
In-Reply-To: <BN3PR04MB2196A8CFF7A5F364CE289C6AD9220@BN3PR04MB2196.namprd04.prod.outlook.com>
References: <BN3PR04MB2196AE795C3741066D59A952D9210@BN3PR04MB2196.namprd04.prod.outlook.com>
	<57716ff0.0617620a.1b687.2b5e@mx.google.com>
	<EFB45FC7-40CA-4C6C-9B98-2BAF1E74C433@memphis.edu>
	<CAOFH+OZ4W+sBwWNPXfrQGXUR5scvKQ51qXeP1RsKRDuNj3tGzg@mail.gmail.com>,
	<E414F19D-2637-4AF4-8A1E-6525C9F7A7CE@memphis.edu>,
	<BN3PR04MB2196A8CFF7A5F364CE289C6AD9220@BN3PR04MB2196.namprd04.prod.outlook.com>
Message-ID: <BN3PR04MB2196EDD16B94FE23DC7AF016D9220@BN3PR04MB2196.namprd04.prod.outlook.com>

Confirmed that this is happening because node b has the same (sync) interest and hence forwards the interest to a resulting in a NACK.


Ashlesh

________________________________
From: Nfd-dev <nfd-dev-bounces at lists.cs.ucla.edu> on behalf of Ashlesh Gawande (agawande) <agawande at memphis.edu>
Sent: Tuesday, June 28, 2016 10:48:35 AM
To: Lan Wang (lanwang); Junxiao Shi
Cc: nfd-dev at lists.cs.ucla.edu
Subject: Re: [Nfd-dev] Help needed with debugging duplicate Nonce


Have attached proof for the said observation.


tmp-localhost_6_27$ grep --color=always 927845950 */ndndump* | sort -t: -k2
c/ndndump.c-eth0_1.0.0.10.pcap:1467054254.052399 From: 1.0.0.10, To: 1.0.0.9, Tunnel Type: UDP, INTEREST: /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
b/ndndump.b-eth1_1.0.0.9.pcap:1467054254.052424 From: 1.0.0.10, To: 1.0.0.9, Tunnel Type: UDP, INTEREST: /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
c/ndndump.c-eth1_1.0.0.6.pcap:1467054254.052428 From: 1.0.0.6, To: 1.0.0.5, Tunnel Type: UDP, INTEREST: /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
a/ndndump.a-eth1_1.0.0.5.pcap:1467054254.052436 From: 1.0.0.6, To: 1.0.0.5, Tunnel Type: UDP, INTEREST: /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
b/ndndump.b-eth0_1.0.0.2.pcap:1467054257.955331 From: 1.0.0.2, To: 1.0.0.1, Tunnel Type: UDP, INTEREST: /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
a/ndndump.a-eth0_1.0.0.1.pcap:1467054257.955348 From: 1.0.0.2, To: 1.0.0.1, Tunnel Type: UDP, INTEREST: /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
a/ndndump.a-eth0_1.0.0.1.pcap:1467054257.965760 From: 1.0.0.1, To: 1.0.0.2, Tunnel Type: UDP, NACK: Duplicate, /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
b/ndndump.b-eth0_1.0.0.2.pcap:1467054257.965760 From: 1.0.0.1, To: 1.0.0.2, Tunnel Type: UDP, NACK: Duplicate, /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950


1) c to b

2) c to a

3) b to a

4) a responds with duplicate NACK


Meanwhile I will also try to test Junxiao's suggestion by forcing communication over TCP and make sure that this is because of local sync expressing the same interest.

Ashlesh

________________________________
From: Lan Wang (lanwang)
Sent: Tuesday, June 28, 2016 5:43 AM
To: Junxiao Shi
Cc: Ashlesh Gawande (agawande); nfd-dev at lists.cs.ucla.edu
Subject: Re: [Nfd-dev] Help needed with debugging duplicate Nonce

Junxiao,

Yes, we observe the same interest forwarding behavior when using /localhop.  I think the reason why the /localhop interest is forwarded beyond one hop is because every node is expressing the same interest -- in ChronoSync when every node reaches consistency, they have the same digest so they have the same sync interest.

We tried to use /localhop to force the sync interest to be one hop.  Otherwise, as you can see in the trace, when the sync interest is forwarded, it causes duplicate NACK and basically it cancels that sync interest.  In order for sync to work correctly, we need to have a pending sync interest in each direction of a link, if the sync interest is canceled by the NACK, then if a node has a change, it cannot respond to the pending sync interest and therefore cannot propagate any changes.  This is what we observed when running NLSR after duplicate NACK was implemented.  There are a lot of duplicate NACKs and the convergence of NLSR is affected.

This is a problem that will affect every protocol that uses sync.

Why was the forwarding of /localhop becomes non local hop if the receiving node is expressing the same interest?

Lan

On Jun 27, 2016, at 2:59 PM, Junxiao Shi <shijunxiao at email.arizona.edu<mailto:shijunxiao at email.arizona.edu>> wrote:

Hi Lan

The Interest name is the snippet is: /ndn/NLSR/sync/d34157d84d19a4f39c359c9794b2686cc061a7dc2411a44255c50a173c1cc89e
There's no /localhop is this name.

In general, if you find NFD forwarding a /localhop Interest, this means a local application is expressing the Interest.
In A-B-C linear topology, when A expresses an Interest and is forwarded to B, B usually does not forward it to C. However, if a local application on B expresses an Interest with same Name+Selectors+Link, B can forward this Interest to C.
If you are suspecting this problem, you may force the application on B to connect to local NFD via TCP by setting `transport=tcp4://127.0.0.1:6363` in $HOME/.ndn/client.conf, and then you'll be able to run tcpdump on the loopback interface and observe whether any local application is expressing the Interest.

Yours, Junxiao

On Mon, Jun 27, 2016 at 11:30 AM, Lan Wang (lanwang) <lanwang at memphis.edu> wrote:
We used /localhop in the name.  Why were the packets forwarded beyond one hop?

Lan


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

From shijunxiao at email.arizona.edu  Tue Jun 28 16:01:18 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Tue, 28 Jun 2016 16:01:18 -0700
Subject: [Nfd-dev] Help needed with debugging duplicate Nonce
In-Reply-To: <BN3PR04MB2196EDD16B94FE23DC7AF016D9220@BN3PR04MB2196.namprd04.prod.outlook.com>
References: <BN3PR04MB2196AE795C3741066D59A952D9210@BN3PR04MB2196.namprd04.prod.outlook.com>
	<57716ff0.0617620a.1b687.2b5e@mx.google.com>
	<EFB45FC7-40CA-4C6C-9B98-2BAF1E74C433@memphis.edu>
	<CAOFH+OZ4W+sBwWNPXfrQGXUR5scvKQ51qXeP1RsKRDuNj3tGzg@mail.gmail.com>
	<E414F19D-2637-4AF4-8A1E-6525C9F7A7CE@memphis.edu>
	<BN3PR04MB2196A8CFF7A5F364CE289C6AD9220@BN3PR04MB2196.namprd04.prod.outlook.com>
	<BN3PR04MB2196EDD16B94FE23DC7AF016D9220@BN3PR04MB2196.namprd04.prod.outlook.com>
Message-ID: <CAOFH+ObvVxtpgCiFYcFvsYgatrpOQ3yYJ-EcD6QXhLToUCkvxw@mail.gmail.com>

Hi Ashlesh

Can you attach complete pcap traces including those collected on network
links and local links?

Yours, Junxiao

On Tue, Jun 28, 2016 at 10:29 AM, Ashlesh Gawande (agawande) <
agawande at memphis.edu> wrote:

> Confirmed that this is happening because node b has the same
> (sync) interest and hence forwards the interest to a resulting in a NACK.
>
>
> Ashlesh
> ------------------------------
> *From:* Nfd-dev <nfd-dev-bounces at lists.cs.ucla.edu> on behalf of Ashlesh
> Gawande (agawande) <agawande at memphis.edu>
> *Sent:* Tuesday, June 28, 2016 10:48:35 AM
> *To:* Lan Wang (lanwang); Junxiao Shi
> *Cc:* nfd-dev at lists.cs.ucla.edu
>
> *Subject:* Re: [Nfd-dev] Help needed with debugging duplicate Nonce
>
>
> Have attached proof for the said observation.
>
>
> tmp-localhost_6_27$ grep --color=always 927845950 */ndndump* | sort -t: -k2
> c/ndndump.c-eth0_1.0.0.10.pcap:1467054254.052399 From: 1.0.0.10, To:
> 1.0.0.9, Tunnel Type: UDP, INTEREST:
> /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
> b/ndndump.b-eth1_1.0.0.9.pcap:1467054254.052424 From: 1.0.0.10, To:
> 1.0.0.9, Tunnel Type: UDP, INTEREST:
> /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
> c/ndndump.c-eth1_1.0.0.6.pcap:1467054254.052428 From: 1.0.0.6, To:
> 1.0.0.5, Tunnel Type: UDP, INTEREST:
> /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
> a/ndndump.a-eth1_1.0.0.5.pcap:1467054254.052436 From: 1.0.0.6, To:
> 1.0.0.5, Tunnel Type: UDP, INTEREST:
> /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
> b/ndndump.b-eth0_1.0.0.2.pcap:1467054257.955331 From: 1.0.0.2, To:
> 1.0.0.1, Tunnel Type: UDP, INTEREST:
> /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
> a/ndndump.a-eth0_1.0.0.1.pcap:1467054257.955348 From: 1.0.0.2, To:
> 1.0.0.1, Tunnel Type: UDP, INTEREST:
> /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
> a/ndndump.a-eth0_1.0.0.1.pcap:1467054257.965760 From: 1.0.0.1, To:
> 1.0.0.2, Tunnel Type: UDP, NACK: Duplicate,
> /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
> b/ndndump.b-eth0_1.0.0.2.pcap:1467054257.965760 From: 1.0.0.1, To:
> 1.0.0.2, Tunnel Type: UDP, NACK: Duplicate,
> /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
>
>
> 1) c to b
>
> 2) c to a
>
> 3) b to a
>
> 4) a responds with duplicate NACK
>
> Meanwhile I will also try to test Junxiao's suggestion by forcing
> communication over TCP and make sure that this is because of local sync
> expressing the same interest.
>
> Ashlesh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160628/c4aac39e/attachment.html>

From agawande at memphis.edu  Tue Jun 28 16:09:13 2016
From: agawande at memphis.edu (Ashlesh Gawande (agawande))
Date: Tue, 28 Jun 2016 23:09:13 +0000
Subject: [Nfd-dev] Help needed with debugging duplicate Nonce
In-Reply-To: <CAOFH+ObvVxtpgCiFYcFvsYgatrpOQ3yYJ-EcD6QXhLToUCkvxw@mail.gmail.com>
References: <BN3PR04MB2196AE795C3741066D59A952D9210@BN3PR04MB2196.namprd04.prod.outlook.com>
	<57716ff0.0617620a.1b687.2b5e@mx.google.com>
	<EFB45FC7-40CA-4C6C-9B98-2BAF1E74C433@memphis.edu>
	<CAOFH+OZ4W+sBwWNPXfrQGXUR5scvKQ51qXeP1RsKRDuNj3tGzg@mail.gmail.com>
	<E414F19D-2637-4AF4-8A1E-6525C9F7A7CE@memphis.edu>
	<BN3PR04MB2196A8CFF7A5F364CE289C6AD9220@BN3PR04MB2196.namprd04.prod.outlook.com>
	<BN3PR04MB2196EDD16B94FE23DC7AF016D9220@BN3PR04MB2196.namprd04.prod.outlook.com>,
	<CAOFH+ObvVxtpgCiFYcFvsYgatrpOQ3yYJ-EcD6QXhLToUCkvxw@mail.gmail.com>
Message-ID: <BN3PR04MB21967E98ABBB495160FE7F10D9220@BN3PR04MB2196.namprd04.prod.outlook.com>

Please find them attached.


Ashlesh

________________________________
From: Junxiao Shi <shijunxiao at email.arizona.edu>
Sent: Tuesday, June 28, 2016 6:01:18 PM
To: Ashlesh Gawande (agawande)
Cc: Lan Wang (lanwang); nfd-dev at lists.cs.ucla.edu
Subject: Re: [Nfd-dev] Help needed with debugging duplicate Nonce

Hi Ashlesh

Can you attach complete pcap traces including those collected on network links and local links?

Yours, Junxiao

On Tue, Jun 28, 2016 at 10:29 AM, Ashlesh Gawande (agawande) <agawande at memphis.edu<mailto:agawande at memphis.edu>> wrote:

Confirmed that this is happening because node b has the same (sync) interest and hence forwards the interest to a resulting in a NACK.


Ashlesh

________________________________
From: Nfd-dev <nfd-dev-bounces at lists.cs.ucla.edu<mailto:nfd-dev-bounces at lists.cs.ucla.edu>> on behalf of Ashlesh Gawande (agawande) <agawande at memphis.edu<mailto:agawande at memphis.edu>>
Sent: Tuesday, June 28, 2016 10:48:35 AM
To: Lan Wang (lanwang); Junxiao Shi
Cc: nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>

Subject: Re: [Nfd-dev] Help needed with debugging duplicate Nonce


Have attached proof for the said observation.


tmp-localhost_6_27$ grep --color=always 927845950 */ndndump* | sort -t: -k2
c/ndndump.c-eth0_1.0.0.10.pcap:1467054254.052399 From: 1.0.0.10, To: 1.0.0.9, Tunnel Type: UDP, INTEREST: /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
b/ndndump.b-eth1_1.0.0.9.pcap:1467054254.052424 From: 1.0.0.10, To: 1.0.0.9, Tunnel Type: UDP, INTEREST: /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
c/ndndump.c-eth1_1.0.0.6.pcap:1467054254.052428 From: 1.0.0.6, To: 1.0.0.5, Tunnel Type: UDP, INTEREST: /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
a/ndndump.a-eth1_1.0.0.5.pcap:1467054254.052436 From: 1.0.0.6, To: 1.0.0.5, Tunnel Type: UDP, INTEREST: /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
b/ndndump.b-eth0_1.0.0.2.pcap:1467054257.955331 From: 1.0.0.2, To: 1.0.0.1, Tunnel Type: UDP, INTEREST: /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
a/ndndump.a-eth0_1.0.0.1.pcap:1467054257.955348 From: 1.0.0.2, To: 1.0.0.1, Tunnel Type: UDP, INTEREST: /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
a/ndndump.a-eth0_1.0.0.1.pcap:1467054257.965760 From: 1.0.0.1, To: 1.0.0.2, Tunnel Type: UDP, NACK: Duplicate, /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
b/ndndump.b-eth0_1.0.0.2.pcap:1467054257.965760 From: 1.0.0.1, To: 1.0.0.2, Tunnel Type: UDP, NACK: Duplicate, /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950


1) c to b

2) c to a

3) b to a

4) a responds with duplicate NACK


Meanwhile I will also try to test Junxiao's suggestion by forcing communication over TCP and make sure that this is because of local sync expressing the same interest.

Ashlesh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160628/2ee4c7b2/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: a-lo.pcap
Type: application/vnd.tcpdump.pcap
Size: 86520 bytes
Desc: a-lo.pcap
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160628/2ee4c7b2/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dump.a-eth0_1.0.0.1.pcap
Type: application/vnd.tcpdump.pcap
Size: 30931 bytes
Desc: dump.a-eth0_1.0.0.1.pcap
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160628/2ee4c7b2/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dump.a-eth1_1.0.0.5.pcap
Type: application/vnd.tcpdump.pcap
Size: 25934 bytes
Desc: dump.a-eth1_1.0.0.5.pcap
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160628/2ee4c7b2/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: b-lo.pcap
Type: application/vnd.tcpdump.pcap
Size: 86757 bytes
Desc: b-lo.pcap
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160628/2ee4c7b2/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dump.b-eth0_1.0.0.2.pcap
Type: application/vnd.tcpdump.pcap
Size: 30931 bytes
Desc: dump.b-eth0_1.0.0.2.pcap
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160628/2ee4c7b2/attachment-0004.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dump.b-eth1_1.0.0.9.pcap
Type: application/vnd.tcpdump.pcap
Size: 31139 bytes
Desc: dump.b-eth1_1.0.0.9.pcap
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160628/2ee4c7b2/attachment-0005.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: c-lo.pcap
Type: application/vnd.tcpdump.pcap
Size: 87821 bytes
Desc: c-lo.pcap
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160628/2ee4c7b2/attachment-0006.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dump.c-eth0_1.0.0.10.pcap
Type: application/vnd.tcpdump.pcap
Size: 31139 bytes
Desc: dump.c-eth0_1.0.0.10.pcap
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160628/2ee4c7b2/attachment-0007.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dump.c-eth1_1.0.0.6.pcap
Type: application/vnd.tcpdump.pcap
Size: 25934 bytes
Desc: dump.c-eth1_1.0.0.6.pcap
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160628/2ee4c7b2/attachment-0008.bin>

From shijunxiao at email.arizona.edu  Wed Jun 29 09:54:37 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Wed, 29 Jun 2016 09:54:37 -0700
Subject: [Nfd-dev] Help needed with debugging duplicate Nonce
In-Reply-To: <BN3PR04MB2196EDD16B94FE23DC7AF016D9220@BN3PR04MB2196.namprd04.prod.outlook.com>
References: <BN3PR04MB2196AE795C3741066D59A952D9210@BN3PR04MB2196.namprd04.prod.outlook.com>
	<57716ff0.0617620a.1b687.2b5e@mx.google.com>
	<EFB45FC7-40CA-4C6C-9B98-2BAF1E74C433@memphis.edu>
	<CAOFH+OZ4W+sBwWNPXfrQGXUR5scvKQ51qXeP1RsKRDuNj3tGzg@mail.gmail.com>
	<E414F19D-2637-4AF4-8A1E-6525C9F7A7CE@memphis.edu>
	<BN3PR04MB2196A8CFF7A5F364CE289C6AD9220@BN3PR04MB2196.namprd04.prod.outlook.com>
	<BN3PR04MB2196EDD16B94FE23DC7AF016D9220@BN3PR04MB2196.namprd04.prod.outlook.com>
Message-ID: <B6716404-2F5E-4F1C-A05D-B674271100C7@email.arizona.edu>

Hi Ashlesh

As discussed in 20160628 NFD call, packet timing at B is like:
fwB receives Interest from appB with nonceB; this Interest is not forwarded
fwB receives Interest from fwC with nonceC
Interest is forwarded to fwA with nonceC

This exposes a weakness in outgoing Interest pipeline ?pick Interest? step: when fwB forwards the Interest, it picks the latest incoming Interest with nonceC, and thus trigger Nack-Duplicate from fwA. If it picks nonceB instead, there wouldn?t be a Nack-Duplicate from fwA.

But another question is: why fwB did not forward the Interest from appB in the first place? This indicates there might be a FIB update during this process.
Can you provide NFD logs to show whether a FIB update occurred? Log level settings should be FibManager=DEBUG, Forwarder=DEBUG.

Yours, Junxiao

> On Jun 28, 2016, at 10:29 AM, Ashlesh Gawande (agawande) <agawande at memphis.edu> wrote:
> 
> Confirmed that this is happening because node b has the same (sync) interest and hence forwards the interest to a resulting in a NACK.
> 
> Ashlesh
> From: Nfd-dev <nfd-dev-bounces at lists.cs.ucla.edu> on behalf of Ashlesh Gawande (agawande) <agawande at memphis.edu>
> Sent: Tuesday, June 28, 2016 10:48:35 AM
> To: Lan Wang (lanwang); Junxiao Shi
> Cc: nfd-dev at lists.cs.ucla.edu
> Subject: Re: [Nfd-dev] Help needed with debugging duplicate Nonce
>  
> Have attached proof for the said observation.
> 
> tmp-localhost_6_27$ grep --color=always 927845950 */ndndump* | sort -t: -k2
> c/ndndump.c-eth0_1.0.0.10.pcap:1467054254.052399 From: 1.0.0.10, To: 1.0.0.9, Tunnel Type: UDP, INTEREST: /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
> b/ndndump.b-eth1_1.0.0.9.pcap:1467054254.052424 From: 1.0.0.10, To: 1.0.0.9, Tunnel Type: UDP, INTEREST: /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
> c/ndndump.c-eth1_1.0.0.6.pcap:1467054254.052428 From: 1.0.0.6, To: 1.0.0.5, Tunnel Type: UDP, INTEREST: /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
> a/ndndump.a-eth1_1.0.0.5.pcap:1467054254.052436 From: 1.0.0.6, To: 1.0.0.5, Tunnel Type: UDP, INTEREST: /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
> b/ndndump.b-eth0_1.0.0.2.pcap:1467054257.955331 From: 1.0.0.2, To: 1.0.0.1, Tunnel Type: UDP, INTEREST: /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
> a/ndndump.a-eth0_1.0.0.1.pcap:1467054257.955348 From: 1.0.0.2, To: 1.0.0.1, Tunnel Type: UDP, INTEREST: /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
> a/ndndump.a-eth0_1.0.0.1.pcap:1467054257.965760 From: 1.0.0.1, To: 1.0.0.2, Tunnel Type: UDP, NACK: Duplicate, /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
> b/ndndump.b-eth0_1.0.0.2.pcap:1467054257.965760 From: 1.0.0.1, To: 1.0.0.2, Tunnel Type: UDP, NACK: Duplicate, /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
> 
> 1) c to b
> 2) c to a
> 3) b to a
> 4) a responds with duplicate NACK
> 
> Meanwhile I will also try to test Junxiao's suggestion by forcing communication over TCP and make sure that this is because of local sync expressing the same interest.
> 
> Ashlesh

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

From agawande at memphis.edu  Wed Jun 29 13:24:30 2016
From: agawande at memphis.edu (Ashlesh Gawande (agawande))
Date: Wed, 29 Jun 2016 20:24:30 +0000
Subject: [Nfd-dev] Help needed with debugging duplicate Nonce
In-Reply-To: <B6716404-2F5E-4F1C-A05D-B674271100C7@email.arizona.edu>
References: <BN3PR04MB2196AE795C3741066D59A952D9210@BN3PR04MB2196.namprd04.prod.outlook.com>
	<57716ff0.0617620a.1b687.2b5e@mx.google.com>
	<EFB45FC7-40CA-4C6C-9B98-2BAF1E74C433@memphis.edu>
	<CAOFH+OZ4W+sBwWNPXfrQGXUR5scvKQ51qXeP1RsKRDuNj3tGzg@mail.gmail.com>
	<E414F19D-2637-4AF4-8A1E-6525C9F7A7CE@memphis.edu>
	<BN3PR04MB2196A8CFF7A5F364CE289C6AD9220@BN3PR04MB2196.namprd04.prod.outlook.com>
	<BN3PR04MB2196EDD16B94FE23DC7AF016D9220@BN3PR04MB2196.namprd04.prod.outlook.com>,
	<B6716404-2F5E-4F1C-A05D-B674271100C7@email.arizona.edu>
Message-ID: <BN3PR04MB2196A571E3EA23F96316B5B5D9230@BN3PR04MB2196.namprd04.prod.outlook.com>

Okay, so I performed a new experiment (i.e. just ran minindn and quit after some time) with FibManager and Forwarder DEBUG logs.


In this experiment, looked at the first Duplicate NACK on localhop prefix (Nonce: 567161547) and found the following:

1) b->a

2) b->c

3) a->c

4) c sends Duplicate NACK


This happens around 1467225861 - I don't see any FibManager messages around this time in NFD logs.


I have attached a sync interest trail where I grepped for the particular sync interest such as:

grep "/localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce" */ndndump* | sort -t: -nk2 | awk '{split($NF,a,"Nonce="); $NF=""; print $0 " " a[2]}' > sync-interest-trail


(ndndump* includes localhost as well as interface)


Seems like before the NACK, a sends interests with two different Nonces - one to c (which resulted in the above NACK), one to b (resulted in another NACK).

This time I didn't see any local new interest for the sync on a  (which should be equivalent to b from the previous example).


Ashlesh

________________________________
From: Junxiao Shi <shijunxiao at email.arizona.edu>
Sent: Wednesday, June 29, 2016 11:54:37 AM
To: Ashlesh Gawande (agawande)
Cc: Lan Wang (lanwang); nfd-dev at lists.cs.ucla.edu
Subject: Re: [Nfd-dev] Help needed with debugging duplicate Nonce

Hi Ashlesh

As discussed in 20160628 NFD call, packet timing at B is like:

  1.  fwB receives Interest from appB with nonceB; this Interest is not forwarded
  2.  fwB receives Interest from fwC with nonceC
  3.  Interest is forwarded to fwA with nonceC

This exposes a weakness in outgoing Interest pipeline ?pick Interest? step: when fwB forwards the Interest, it picks the latest incoming Interest with nonceC, and thus trigger Nack-Duplicate from fwA. If it picks nonceB instead, there wouldn?t be a Nack-Duplicate from fwA.

But another question is: why fwB did not forward the Interest from appB in the first place? This indicates there might be a FIB update during this process.
Can you provide NFD logs to show whether a FIB update occurred? Log level settings should be FibManager=DEBUG, Forwarder=DEBUG.

Yours, Junxiao

On Jun 28, 2016, at 10:29 AM, Ashlesh Gawande (agawande) <agawande at memphis.edu<mailto:agawande at memphis.edu>> wrote:

Confirmed that this is happening because node b has the same (sync) interest and hence forwards the interest to a resulting in a NACK.

Ashlesh
________________________________
From: Nfd-dev <nfd-dev-bounces at lists.cs.ucla.edu<mailto:nfd-dev-bounces at lists.cs.ucla.edu>> on behalf of Ashlesh Gawande (agawande) <agawande at memphis.edu<mailto:agawande at memphis.edu>>
Sent: Tuesday, June 28, 2016 10:48:35 AM
To: Lan Wang (lanwang); Junxiao Shi
Cc: nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>
Subject: Re: [Nfd-dev] Help needed with debugging duplicate Nonce

Have attached proof for the said observation.


tmp-localhost_6_27$ grep --color=always 927845950 */ndndump* | sort -t: -k2
c/ndndump.c-eth0_1.0.0.10.pcap:1467054254.052399 From: 1.0.0.10, To: 1.0.0.9, Tunnel Type: UDP, INTEREST: /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
b/ndndump.b-eth1_1.0.0.9.pcap:1467054254.052424 From: 1.0.0.10, To: 1.0.0.9, Tunnel Type: UDP, INTEREST: /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
c/ndndump.c-eth1_1.0.0.6.pcap:1467054254.052428 From: 1.0.0.6, To: 1.0.0.5, Tunnel Type: UDP, INTEREST: /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
a/ndndump.a-eth1_1.0.0.5.pcap:1467054254.052436 From: 1.0.0.6, To: 1.0.0.5, Tunnel Type: UDP, INTEREST: /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
b/ndndump.b-eth0_1.0.0.2.pcap:1467054257.955331 From: 1.0.0.2, To: 1.0.0.1, Tunnel Type: UDP, INTEREST: /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
a/ndndump.a-eth0_1.0.0.1.pcap:1467054257.955348 From: 1.0.0.2, To: 1.0.0.1, Tunnel Type: UDP, INTEREST: /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
a/ndndump.a-eth0_1.0.0.1.pcap:1467054257.965760 From: 1.0.0.1, To: 1.0.0.2, Tunnel Type: UDP, NACK: Duplicate, /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950
b/ndndump.b-eth0_1.0.0.2.pcap:1467054257.965760 From: 1.0.0.1, To: 1.0.0.2, Tunnel Type: UDP, NACK: Duplicate, /localhop/NLSR/sync/e4c858598a526f7f25d42f4da49cb51b7950cf352e26d5092bd35126b509101b?ndn.MustBeFresh=1&ndn.Nonce=927845950

1) c to b
2) c to a
3) b to a
4) a responds with duplicate NACK

Meanwhile I will also try to test Junxiao's suggestion by forcing communication over TCP and make sure that this is because of local sync expressing the same interest.

Ashlesh

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160629/450ace97/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nfd_log_localhost_tcp_6_29.tar.gz
Type: application/gzip
Size: 355320 bytes
Desc: nfd_log_localhost_tcp_6_29.tar.gz
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20160629/450ace97/attachment.bin>

From lixia at CS.UCLA.EDU  Wed Jun 29 12:28:18 2016
From: lixia at CS.UCLA.EDU (Lixia Zhang)
Date: Wed, 29 Jun 2016 12:28:18 -0700
Subject: [Nfd-dev] a question about PIT entry
In-Reply-To: <536DB9C4-02C9-4212-8FED-CDB364EC540F@memphis.edu>
References: <536DB9C4-02C9-4212-8FED-CDB364EC540F@memphis.edu>
Message-ID: <DC771E19-3E13-4EC1-95FF-5F314A0F6CA5@cs.ucla.edu>


> On Jun 28, 2016, at 10:04 AM, Lan Wang (lanwang) <lanwang at memphis.edu> wrote:
> 
> Hi,
> 
> I have a question about how to keep a PIT entry in a particular situation.  Suppose there are two nodes:
> 
> a ? b
> 
> 1) a and b both send the same interests (same name) to each other.
> 2) a responds to b?s interest with a data packet.  In the current PIT implementation, it will remove both a and b's PIT entry for this interest.
> 
> We hope that a?s data packet would not erase the PIT entry in a and b completely (only remove the necessary in and out records) so that b can still respond to a?s interest.
> 
> This is inspired by a partialsync implementation issue.  Is there any way to achieve this result?

Not sure I fully understand the problem here: given A already has the data packet, wonder why it is necessary for B to send the data packet back to A (instead of having A to resolve the issue internally)?

Lixia


From shijunxiao at email.arizona.edu  Wed Jun 29 16:25:23 2016
From: shijunxiao at email.arizona.edu (Junxiao Shi)
Date: Wed, 29 Jun 2016 16:25:23 -0700
Subject: [Nfd-dev] a question about PIT entry
In-Reply-To: <536DB9C4-02C9-4212-8FED-CDB364EC540F@memphis.edu>
References: <536DB9C4-02C9-4212-8FED-CDB364EC540F@memphis.edu>
Message-ID: <CAOFH+OaTGSrEp-XLKcRh2LmtExUxKoZsK+OOhRz9RCVSgBDS_g@mail.gmail.com>

Hi Lan

Let me expand the topology as:
appA   appB
  |     |
 fwA---fwB

   1. appA sends Interest /P nonce=1 to fwA, which is forwarded to fwB, and
   then appB
   fwA has PIT entry /P in=["appA nonce=1"] out=["fwB nonce=1"]
   fwB has PIT entry /P in=["fwA nonce=1"] out=["appB nonce=1"]
   2. appB sends Interest /P nonce=2 to fwB, which is forwarded to fwA, and
   then appA
   fwB has PIT entry /P in=["fwA nonce=1", "appB nonce=2"] out=["appB
   nonce=1", "fwA nonce=2"]
   fwA has PIT entry /P in=["appA nonce=1", "fwB nonce=2"] out=["fwB
   nonce=1", "appA nonce=2"]
   3. appA responds Data /P to fwA, which is returned to fwB, and then appB
   fwA has PIT entry /P in=[] out=["fwB nonce=1"]
   fwB has PIT entry /P in=[] out=["appB nonce=1"]

In step3, fwA will clear the in-record "appA nonce=1" but will not return
Data to appA. fwA assumes appA can internally satisfy this pending
Interest; this "internal satisfying" feature is not implemented in ndn-cxx,
so application should handle this by itself.
Similarly, fwB will clear the in-record "fwA nonce=1" but will not return
Data to fwA. fwB assumes fwA can internally satisfy this pending Interest;
this "internal satisfying" feature is implemented in NFD, in the form of
returning Data to all consumers and admitting Data into CS.
The PIT entries on fwA and fwB are not erased. Instead, it's kept for loop
detection and measurement purpose, and will be erased by the straggler
timer.

If appB would respond to appA's Interest with the same Data, the same
effect can be achieved by implementing "internal satisfying" feature
mentioned above.
If appB would respond to appA's Interest with a different Data of same
name, the protocol design is wrong because it violates Data immutability
principle <http://named-data.net/project/ndn-design-principles/>. Instead,
appB should create a Data with a higher version number, and appA can
express another Interest that excludes its own version number in order to
receive appB's Data.

Yours, Junxiao

On Tue, Jun 28, 2016 at 10:04 AM, Lan Wang (lanwang) <lanwang at memphis.edu>
wrote:

> Hi,
>
> I have a question about how to keep a PIT entry in a particular
> situation.  Suppose there are two nodes:
>
> a ? b
>
> 1) a and b both send the same interests (same name) to each other.
> 2) a responds to b?s interest with a data packet.  In the current PIT
> implementation, it will remove both a and b's PIT entry for this interest.
>
> We hope that a?s data packet would not erase the PIT entry in a and b
> completely (only remove the necessary in and out records) so that b can
> still respond to a?s interest.
>
> This is inspired by a partialsync implementation issue.  Is there any way
> to achieve this result?
>
> Lan
>
>
> _______________________________________________
> 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/20160629/8728c5bc/attachment.html>

From nfd-call-notification at mail1.yoursunny.com  Thu Jun 30 07:00:02 2016
From: nfd-call-notification at mail1.yoursunny.com (NFD call notification)
Date: Thu, 30 Jun 2016 07:00:02 -0700
Subject: [Nfd-dev] NFD call 20160630
Message-ID: <201606301400.u5UE02Q9027778@lectura.cs.arizona.edu>

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

From lanwang at memphis.edu  Thu Jun 30 09:35:27 2016
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Thu, 30 Jun 2016 16:35:27 +0000
Subject: [Nfd-dev] NFD call time and link
Message-ID: <84AC005D-4CE9-434C-BCDC-7DDD05EB3CCC@memphis.edu>

Hi all,

Just want to remind everyone that the NFD call time has been changed back to Tue and Thu 1pm pacific time.  The new Bluejeans link is https://bluejeans.com/424982807

Thanks.

Lan