From agawande at memphis.edu  Wed Aug 12 11:09:32 2015
From: agawande at memphis.edu (Ashlesh Gawande (agawande))
Date: Wed, 12 Aug 2015 18:09:32 +0000
Subject: [Mini-NDN] Doubts regarding face creation
In-Reply-To: <12DB5299AAAB1A40B17E72AB76FDA6D8EDC285@PALLENE.office.hd>
References: <12DB5299AAAB1A40B17E72AB76FDA6D8EDC285@PALLENE.office.hd>
Message-ID: <BY1PR0401MB16103F9F832AD0B78B2AD4B1D97E0@BY1PR0401MB1610.namprd04.prod.outlook.com>

Hi


So this is happening because NLSR does not support parallel links as of now. It will simply ignore the second neighbor in the configuration file. I have filed a feature request:

http://redmine.named-data.net/issues/3097

But it will not be in the near future as it requires some design and implementation work.


Right now you will have to do that manually. If your topology is fixed you can do it within the code

so you don't have to do it manually every time the topology comes up.


Example: In bin/minindn you can do something like net.hosts['g1'].cmd("nfdc register ....")

Ashlesh
________________________________
From: Nfd-dev <nfd-dev-bounces at lists.cs.ucla.edu> on behalf of Navdeep Uniyal <navdeep.uniyal at neclab.eu>
Sent: Wednesday, August 12, 2015 3:51 AM
To: nfd-dev at lists.cs.ucla.edu
Subject: [Nfd-dev] Doubts regarding face creation


Hello All,



I am working on minindn. While creating the topology I am using the following configuration file:

[nodes]

h1: _

h2: _

h3: _

h4: _

g1: _

[links]

h1:g1 delay=10ms bw=10

h2:g1 delay=5ms bw=1

h2:g1 delay=0ms bw=2

h3:g1 delay=0ms bw=1

h4:g1 delay=0ms bw=3





As per my understanding, between h2 and g1 there should be 2 faces created but I am finding only one face created for this, and the other connection I have to make explicitly. Please confirm if this is expected behavior,  if I am doing anything wrong  or my understanding is wrong.



For g1, faces are :

Faces:

  faceid=1 remote=internal:// local=internal:// counters={in={0i 81d 0B} out={132i 0d 0B}} local persistent point-to-point

  faceid=254 remote=contentstore:// local=contentstore:// counters={in={0i 0d 0B} out={0i 0d 0B}} local persistent point-to-point

  faceid=255 remote=null:// local=null:// counters={in={0i 0d 0B} out={0i 0d 0B}} local persistent point-to-point

  faceid=256 remote=fd://18 local=unix:///run/g1.sock counters={in={92i 27d 36942B} out={27i 43d 45212B}} local on-demand point-to-point

  faceid=257 remote=fd://20 local=unix:///run/g1.sock counters={in={1022i 223d 208468B} out={912i 288d 231943B}} local on-demand point-to-point

  faceid=258 remote=udp4://1.0.0.1:6363 local=udp4://0.0.0.0:6363 counters={in={766i 74d 106769B} out={784i 89d 115716B}} non-local persistent point-to-point

  faceid=259 remote=udp4://1.0.0.5:6363 local=udp4://0.0.0.0:6363 counters={in={767i 65d 102476B} out={779i 89d 115339B}} non-local persistent point-to-point

  faceid=260 remote=udp4://1.0.0.13:6363 local=udp4://0.0.0.0:6363 counters={in={767i 67d 103289B} out={779i 89d 115605B}} non-local persistent point-to-point

  faceid=261 remote=udp4://1.0.0.17:6363 local=udp4://0.0.0.0:6363 counters={in={768i 68d 104006B} out={782i 89d 115879B}} non-local persistent point-to-point

  faceid=265 remote=udp4://1.0.0.9:6363 local=udp4://0.0.0.0:6363 counters={in={0i 0d 0B} out={0i 0d 0B}} non-local persistent point-to-point

  faceid=266 remote=fd://25 local=unix:///run/g1.sock counters={in={3i 0d 137B} out={0i 2d 903B}} local on-demand point-to-point



Highlighted one I created explicitly using nfdc register.

Also, please explain the significance of the counters [counters={in={0i 0d 0B} out={0i 0d 0B}}]







Best Regards,

Navdeep Uniyal


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/mini-ndn/attachments/20150812/90f031a8/attachment.html>

From lanwang at memphis.edu  Wed Aug 12 12:22:14 2015
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Wed, 12 Aug 2015 19:22:14 +0000
Subject: [Mini-NDN] [Nfd-dev] Doubts regarding face creation
In-Reply-To: <BY1PR0401MB16103F9F832AD0B78B2AD4B1D97E0@BY1PR0401MB1610.namprd04.prod.outlook.com>
References: <12DB5299AAAB1A40B17E72AB76FDA6D8EDC285@PALLENE.office.hd>
	<BY1PR0401MB16103F9F832AD0B78B2AD4B1D97E0@BY1PR0401MB1610.namprd04.prod.outlook.com>
Message-ID: <D3B13089-F795-4566-9372-649519774583@memphis.edu>

Ashlesh,

I don't see how nfdc register is going to help if NLSR does not support parallel links (I may have misunderstood something).  But since Navdeep has joined the mini-ndn mailing list, let's move the discussion there.

Lan

On Aug 12, 2015, at 1:09 PM, Ashlesh Gawande (agawande) <agawande at memphis.edu<mailto:agawande at memphis.edu>> wrote:

Hi

So this is happening because NLSR does not support parallel links as of now. It will simply ignore the second neighbor in the configuration file. I have filed a feature request:
http://redmine.named-data.net/issues/3097
But it will not be in the near future as it requires some design and implementation work.

Right now you will have to do that manually. If your topology is fixed you can do it within the code
so you don't have to do it manually every time the topology comes up.

Example: In bin/minindn you can do something like net.hosts['g1'].cmd("nfdc register ....")

Ashlesh
________________________________
From: Nfd-dev <nfd-dev-bounces at lists.cs.ucla.edu<mailto:nfd-dev-bounces at lists.cs.ucla.edu>> on behalf of Navdeep Uniyal <navdeep.uniyal at neclab.eu<mailto:navdeep.uniyal at neclab.eu>>
Sent: Wednesday, August 12, 2015 3:51 AM
To: nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>
Subject: [Nfd-dev] Doubts regarding face creation

Hello All,



I am working on minindn. While creating the topology I am using the following configuration file:
[nodes]
h1: _
h2: _
h3: _
h4: _
g1: _
[links]
h1:g1 delay=10ms bw=10
h2:g1 delay=5ms bw=1
h2:g1 delay=0ms bw=2
h3:g1 delay=0ms bw=1
h4:g1 delay=0ms bw=3





As per my understanding, between h2 and g1 there should be 2 faces created but I am finding only one face created for this, and the other connection I have to make explicitly. Please confirm if this is expected behavior,  if I am doing anything wrong  or my understanding is wrong.



For g1, faces are :
Faces:
  faceid=1 remote=internal:// local=internal:// counters={in={0i 81d 0B} out={132i 0d 0B}} local persistent point-to-point
  faceid=254 remote=contentstore:// local=contentstore:// counters={in={0i 0d 0B} out={0i 0d 0B}} local persistent point-to-point
  faceid=255 remote=null:// local=null:// counters={in={0i 0d 0B} out={0i 0d 0B}} local persistent point-to-point
  faceid=256 remote=fd://18 local=unix:///run/g1.sock counters={in={92i 27d 36942B} out={27i 43d 45212B}} local on-demand point-to-point
  faceid=257 remote=fd://20 local=unix:///run/g1.sock counters={in={1022i 223d 208468B} out={912i 288d 231943B}} local on-demand point-to-point
  faceid=258 remote=udp4://1.0.0.1:6363 local=udp4://0.0.0.0:6363 counters={in={766i 74d 106769B} out={784i 89d 115716B}} non-local persistent point-to-point
  faceid=259 remote=udp4://1.0.0.5:6363 local=udp4://0.0.0.0:6363 counters={in={767i 65d 102476B} out={779i 89d 115339B}} non-local persistent point-to-point
  faceid=260 remote=udp4://1.0.0.13:6363 local=udp4://0.0.0.0:6363 counters={in={767i 67d 103289B} out={779i 89d 115605B}} non-local persistent point-to-point
  faceid=261 remote=udp4://1.0.0.17:6363 local=udp4://0.0.0.0:6363 counters={in={768i 68d 104006B} out={782i 89d 115879B}} non-local persistent point-to-point
  faceid=265 remote=udp4://1.0.0.9:6363 local=udp4://0.0.0.0:6363 counters={in={0i 0d 0B} out={0i 0d 0B}} non-local persistent point-to-point
  faceid=266 remote=fd://25 local=unix:///run/g1.sock counters={in={3i 0d 137B} out={0i 2d 903B}} local on-demand point-to-point



Highlighted one I created explicitly using nfdc register.
Also, please explain the significance of the counters [counters={in={0i 0d 0B} out={0i 0d 0B}}]







Best Regards,
Navdeep Uniyal



_______________________________________________
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/mini-ndn/attachments/20150812/7c7c0ee9/attachment.html>

From agawande at memphis.edu  Wed Aug 12 12:33:54 2015
From: agawande at memphis.edu (Ashlesh Gawande (agawande))
Date: Wed, 12 Aug 2015 19:33:54 +0000
Subject: [Mini-NDN] [Nfd-dev] Doubts regarding face creation
In-Reply-To: <D3B13089-F795-4566-9372-649519774583@memphis.edu>
References: <12DB5299AAAB1A40B17E72AB76FDA6D8EDC285@PALLENE.office.hd>
	<BY1PR0401MB16103F9F832AD0B78B2AD4B1D97E0@BY1PR0401MB1610.namprd04.prod.outlook.com>,
	<D3B13089-F795-4566-9372-649519774583@memphis.edu>
Message-ID: <BY1PR0401MB1610C425A010721BE79C48B8D97E0@BY1PR0401MB1610.namprd04.prod.outlook.com>

Maybe he just wants a static entry. I am not sure but he mentions using nfdc register to get the desired face list.

Ashlesh
________________________________
From: Mini-NDN <mini-ndn-bounces at lists.cs.ucla.edu> on behalf of Lan Wang (lanwang) <lanwang at memphis.edu>
Sent: Wednesday, August 12, 2015 2:22 PM
To: mini-ndn at lists.cs.ucla.edu
Subject: [SPAM:###68] [SPAM:###68] Re: [Mini-NDN] [Nfd-dev] Doubts regarding face creation

Ashlesh,

I don't see how nfdc register is going to help if NLSR does not support parallel links (I may have misunderstood something).  But since Navdeep has joined the mini-ndn mailing list, let's move the discussion there.

Lan

On Aug 12, 2015, at 1:09 PM, Ashlesh Gawande (agawande) <agawande at memphis.edu<mailto:agawande at memphis.edu>> wrote:

Hi

So this is happening because NLSR does not support parallel links as of now. It will simply ignore the second neighbor in the configuration file. I have filed a feature request:
http://redmine.named-data.net/issues/3097
But it will not be in the near future as it requires some design and implementation work.

Right now you will have to do that manually. If your topology is fixed you can do it within the code
so you don't have to do it manually every time the topology comes up.

Example: In bin/minindn you can do something like net.hosts['g1'].cmd("nfdc register ....")

Ashlesh
________________________________
From: Nfd-dev <nfd-dev-bounces at lists.cs.ucla.edu<mailto:nfd-dev-bounces at lists.cs.ucla.edu>> on behalf of Navdeep Uniyal <navdeep.uniyal at neclab.eu<mailto:navdeep.uniyal at neclab.eu>>
Sent: Wednesday, August 12, 2015 3:51 AM
To: nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>
Subject: [Nfd-dev] Doubts regarding face creation

Hello All,



I am working on minindn. While creating the topology I am using the following configuration file:
[nodes]
h1: _
h2: _
h3: _
h4: _
g1: _
[links]
h1:g1 delay=10ms bw=10
h2:g1 delay=5ms bw=1
h2:g1 delay=0ms bw=2
h3:g1 delay=0ms bw=1
h4:g1 delay=0ms bw=3





As per my understanding, between h2 and g1 there should be 2 faces created but I am finding only one face created for this, and the other connection I have to make explicitly. Please confirm if this is expected behavior,  if I am doing anything wrong  or my understanding is wrong.



For g1, faces are :
Faces:
  faceid=1 remote=internal:// local=internal:// counters={in={0i 81d 0B} out={132i 0d 0B}} local persistent point-to-point
  faceid=254 remote=contentstore:// local=contentstore:// counters={in={0i 0d 0B} out={0i 0d 0B}} local persistent point-to-point
  faceid=255 remote=null:// local=null:// counters={in={0i 0d 0B} out={0i 0d 0B}} local persistent point-to-point
  faceid=256 remote=fd://18 local=unix:///run/g1.sock counters={in={92i 27d 36942B} out={27i 43d 45212B}} local on-demand point-to-point
  faceid=257 remote=fd://20 local=unix:///run/g1.sock counters={in={1022i 223d 208468B} out={912i 288d 231943B}} local on-demand point-to-point
  faceid=258 remote=udp4://1.0.0.1:6363 local=udp4://0.0.0.0:6363 counters={in={766i 74d 106769B} out={784i 89d 115716B}} non-local persistent point-to-point
  faceid=259 remote=udp4://1.0.0.5:6363 local=udp4://0.0.0.0:6363 counters={in={767i 65d 102476B} out={779i 89d 115339B}} non-local persistent point-to-point
  faceid=260 remote=udp4://1.0.0.13:6363 local=udp4://0.0.0.0:6363 counters={in={767i 67d 103289B} out={779i 89d 115605B}} non-local persistent point-to-point
  faceid=261 remote=udp4://1.0.0.17:6363 local=udp4://0.0.0.0:6363 counters={in={768i 68d 104006B} out={782i 89d 115879B}} non-local persistent point-to-point
  faceid=265 remote=udp4://1.0.0.9:6363 local=udp4://0.0.0.0:6363 counters={in={0i 0d 0B} out={0i 0d 0B}} non-local persistent point-to-point
  faceid=266 remote=fd://25 local=unix:///run/g1.sock counters={in={3i 0d 137B} out={0i 2d 903B}} local on-demand point-to-point



Highlighted one I created explicitly using nfdc register.
Also, please explain the significance of the counters [counters={in={0i 0d 0B} out={0i 0d 0B}}]







Best Regards,
Navdeep Uniyal



_______________________________________________
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/mini-ndn/attachments/20150812/7ed6b0b3/attachment.html>

From lanwang at memphis.edu  Wed Aug 12 12:52:02 2015
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Wed, 12 Aug 2015 19:52:02 +0000
Subject: [Mini-NDN] [Nfd-dev] Doubts regarding face creation
In-Reply-To: <BY1PR0401MB1610C425A010721BE79C48B8D97E0@BY1PR0401MB1610.namprd04.prod.outlook.com>
References: <12DB5299AAAB1A40B17E72AB76FDA6D8EDC285@PALLENE.office.hd>
	<BY1PR0401MB16103F9F832AD0B78B2AD4B1D97E0@BY1PR0401MB1610.namprd04.prod.outlook.com>,
	<D3B13089-F795-4566-9372-649519774583@memphis.edu>
	<BY1PR0401MB1610C425A010721BE79C48B8D97E0@BY1PR0401MB1610.namprd04.prod.outlook.com>
Message-ID: <056597ED-D151-4C66-A555-9575249A28FA@memphis.edu>

Yes, the nfdc command will create an additional face at the NFD level, but I'm not sure how NLSR will treat the two faces since they are between the same two routers (at least it's not something we handle by design).  Vince can clarify.

By the way, just want to clarify that, for the original configuration mininet does create two links between the nodes.  See below.

Lan

Begin forwarded message:

From: "Ashlesh Gawande (agawande)" <agawande at memphis.edu<mailto:agawande at memphis.edu>>
Subject: Re: [Nfd-dev] Doubts regarding face creation
Date: August 12, 2015 12:47:03 PM CDT
To: "Lan Wang (lanwang)" <lanwang at memphis.edu<mailto:lanwang at memphis.edu>>, "Vince Lehman (vslehman)" <vslehman at memphis.edu<mailto:vslehman at memphis.edu>>

So I checked and Mininet does make the two interfaces.

Then I made a small subset of the topology with h2 having two links to g1 each having a different cost (5 and 0).
(h2===g1)
So h2 has two interfaces connecting to two interfaces on g1.
Now Mini-NDN starts up and writes NLSR configuration file for h2 and g1. Their neighbor sections are:

h1:
neighbor
{
  name /ndn/edu/%C1.Router/cs/g1
  face-uri udp://1.0.0.2
  link-cost 5
}
neighbor
{
  name /ndn/edu/%C1.Router/cs/g1
  face-uri udp://1.0.0.6
  link-cost 0
}

g1:
neighbor
{
  name /ndn/edu/%C1.Router/cs/h2
  face-uri udp://1.0.0.1
  link-cost 5
}
neighbor
{
  name /ndn/edu/%C1.Router/cs/h2
  face-uri udp://1.0.0.5
  link-cost 0
}

But NLSR only advertises the first neighbor (maybe since the router names are same).
So I am not sure whether this is the correct behavior of NLSR or should I file a bug?

Note that Junxaio's point may not apply here since the the IPs are different. And that's why Navdeep is able to create the route himself via nfdc.

Ashlesh

Lan

On Aug 12, 2015, at 2:33 PM, "Ashlesh Gawande (agawande)" <agawande at memphis.edu<mailto:agawande at memphis.edu>>
 wrote:

Maybe he just wants a static entry. I am not sure but he mentions using nfdc register to get the desired face list.

Ashlesh
________________________________
From: Mini-NDN <mini-ndn-bounces at lists.cs.ucla.edu<mailto:mini-ndn-bounces at lists.cs.ucla.edu>> on behalf of Lan Wang (lanwang) <lanwang at memphis.edu<mailto:lanwang at memphis.edu>>
Sent: Wednesday, August 12, 2015 2:22 PM
To: mini-ndn at lists.cs.ucla.edu<mailto:mini-ndn at lists.cs.ucla.edu>
Subject: [SPAM:###68] [SPAM:###68] Re: [Mini-NDN] [Nfd-dev] Doubts regarding face creation

Ashlesh,

I don't see how nfdc register is going to help if NLSR does not support parallel links (I may have misunderstood something).  But since Navdeep has joined the mini-ndn mailing list, let's move the discussion there.

Lan

On Aug 12, 2015, at 1:09 PM, Ashlesh Gawande (agawande) <agawande at memphis.edu<mailto:agawande at memphis.edu>> wrote:

Hi

So this is happening because NLSR does not support parallel links as of now. It will simply ignore the second neighbor in the configuration file. I have filed a feature request:
http://redmine.named-data.net/issues/3097
But it will not be in the near future as it requires some design and implementation work.

Right now you will have to do that manually. If your topology is fixed you can do it within the code
so you don't have to do it manually every time the topology comes up.

Example: In bin/minindn you can do something like net.hosts['g1'].cmd("nfdc register ....")

Ashlesh
________________________________
From: Nfd-dev <nfd-dev-bounces at lists.cs.ucla.edu<mailto:nfd-dev-bounces at lists.cs.ucla.edu>> on behalf of Navdeep Uniyal <navdeep.uniyal at neclab.eu<mailto:navdeep.uniyal at neclab.eu>>
Sent: Wednesday, August 12, 2015 3:51 AM
To: nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>
Subject: [Nfd-dev] Doubts regarding face creation

Hello All,



I am working on minindn. While creating the topology I am using the following configuration file:
[nodes]
h1: _
h2: _
h3: _
h4: _
g1: _
[links]
h1:g1 delay=10ms bw=10
h2:g1 delay=5ms bw=1
h2:g1 delay=0ms bw=2
h3:g1 delay=0ms bw=1
h4:g1 delay=0ms bw=3





As per my understanding, between h2 and g1 there should be 2 faces created but I am finding only one face created for this, and the other connection I have to make explicitly. Please confirm if this is expected behavior,  if I am doing anything wrong  or my understanding is wrong.



For g1, faces are :
Faces:
  faceid=1 remote=internal:// local=internal:// counters={in={0i 81d 0B} out={132i 0d 0B}} local persistent point-to-point
  faceid=254 remote=contentstore:// local=contentstore:// counters={in={0i 0d 0B} out={0i 0d 0B}} local persistent point-to-point
  faceid=255 remote=null:// local=null:// counters={in={0i 0d 0B} out={0i 0d 0B}} local persistent point-to-point
  faceid=256 remote=fd://18 local=unix:///run/g1.sock counters={in={92i 27d 36942B} out={27i 43d 45212B}} local on-demand point-to-point
  faceid=257 remote=fd://20 local=unix:///run/g1.sock counters={in={1022i 223d 208468B} out={912i 288d 231943B}} local on-demand point-to-point
  faceid=258 remote=udp4://1.0.0.1:6363 local=udp4://0.0.0.0:6363 counters={in={766i 74d 106769B} out={784i 89d 115716B}} non-local persistent point-to-point
  faceid=259 remote=udp4://1.0.0.5:6363 local=udp4://0.0.0.0:6363 counters={in={767i 65d 102476B} out={779i 89d 115339B}} non-local persistent point-to-point
  faceid=260 remote=udp4://1.0.0.13:6363 local=udp4://0.0.0.0:6363 counters={in={767i 67d 103289B} out={779i 89d 115605B}} non-local persistent point-to-point
  faceid=261 remote=udp4://1.0.0.17:6363 local=udp4://0.0.0.0:6363 counters={in={768i 68d 104006B} out={782i 89d 115879B}} non-local persistent point-to-point
  faceid=265 remote=udp4://1.0.0.9:6363 local=udp4://0.0.0.0:6363 counters={in={0i 0d 0B} out={0i 0d 0B}} non-local persistent point-to-point
  faceid=266 remote=fd://25 local=unix:///run/g1.sock counters={in={3i 0d 137B} out={0i 2d 903B}} local on-demand point-to-point



Highlighted one I created explicitly using nfdc register.
Also, please explain the significance of the counters [counters={in={0i 0d 0B} out={0i 0d 0B}}]







Best Regards,
Navdeep Uniyal



_______________________________________________
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/mini-ndn/attachments/20150812/bac22253/attachment.html>

From navdeep.uniyal at neclab.eu  Thu Aug 13 00:39:48 2015
From: navdeep.uniyal at neclab.eu (Navdeep Uniyal)
Date: Thu, 13 Aug 2015 07:39:48 +0000
Subject: [Mini-NDN] [Nfd-dev] Doubts regarding face creation
In-Reply-To: <BY1PR0401MB1610C425A010721BE79C48B8D97E0@BY1PR0401MB1610.namprd04.prod.outlook.com>
References: <12DB5299AAAB1A40B17E72AB76FDA6D8EDC285@PALLENE.office.hd>
	<BY1PR0401MB16103F9F832AD0B78B2AD4B1D97E0@BY1PR0401MB1610.namprd04.prod.outlook.com>,
	<D3B13089-F795-4566-9372-649519774583@memphis.edu>
	<BY1PR0401MB1610C425A010721BE79C48B8D97E0@BY1PR0401MB1610.namprd04.prod.outlook.com>
Message-ID: <12DB5299AAAB1A40B17E72AB76FDA6D8EE24E2@PALLENE.office.hd>

Actually I need to configure a multi interface gateway and by nfdc register I can create the face as mentioned below. The strategies like broadcast(which uses multi link) are able to transfer the interest messages over the links. But the issue I am seeing here is that the counters value are 0. Please if you can explain the significance of counters, According to my understanding they are just measuring the number of bytes going out and coming in through the interface(but what are the values i,d and B represents). Also, there is no management traffic going through the link( which might be because as you said that NLSR does not support multilinks as of now). My concern is will it have any impact on the way the traffic is sent if my strategy supports multi interface gateway?

Best Regards,
Navdeep Uniyal

From: Mini-NDN [mailto:mini-ndn-bounces at lists.cs.ucla.edu] On Behalf Of Ashlesh Gawande (agawande)
Sent: Mittwoch, 12. August 2015 21:34
To: Lan Wang (lanwang); mini-ndn at lists.cs.ucla.edu
Subject: Re: [Mini-NDN] [Nfd-dev] Doubts regarding face creation


Maybe he just wants a static entry. I am not sure but he mentions using nfdc register to get the desired face list.

Ashlesh
________________________________
From: Mini-NDN <mini-ndn-bounces at lists.cs.ucla.edu<mailto:mini-ndn-bounces at lists.cs.ucla.edu>> on behalf of Lan Wang (lanwang) <lanwang at memphis.edu<mailto:lanwang at memphis.edu>>
Sent: Wednesday, August 12, 2015 2:22 PM
To: mini-ndn at lists.cs.ucla.edu<mailto:mini-ndn at lists.cs.ucla.edu>
Subject: [SPAM:###68] [SPAM:###68] Re: [Mini-NDN] [Nfd-dev] Doubts regarding face creation

Ashlesh,

I don't see how nfdc register is going to help if NLSR does not support parallel links (I may have misunderstood something).  But since Navdeep has joined the mini-ndn mailing list, let's move the discussion there.

Lan

On Aug 12, 2015, at 1:09 PM, Ashlesh Gawande (agawande) <agawande at memphis.edu<mailto:agawande at memphis.edu>> wrote:


Hi

So this is happening because NLSR does not support parallel links as of now. It will simply ignore the second neighbor in the configuration file. I have filed a feature request:
http://redmine.named-data.net/issues/3097
But it will not be in the near future as it requires some design and implementation work.

Right now you will have to do that manually. If your topology is fixed you can do it within the code
so you don't have to do it manually every time the topology comes up.

Example: In bin/minindn you can do something like net.hosts['g1'].cmd("nfdc register ....")

Ashlesh
________________________________
From: Nfd-dev <nfd-dev-bounces at lists.cs.ucla.edu<mailto:nfd-dev-bounces at lists.cs.ucla.edu>> on behalf of Navdeep Uniyal <navdeep.uniyal at neclab.eu<mailto:navdeep.uniyal at neclab.eu>>
Sent: Wednesday, August 12, 2015 3:51 AM
To: nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>
Subject: [Nfd-dev] Doubts regarding face creation

Hello All,


I am working on minindn. While creating the topology I am using the following configuration file:
[nodes]
h1: _
h2: _
h3: _
h4: _
g1: _
[links]
h1:g1 delay=10ms bw=10
h2:g1 delay=5ms bw=1
h2:g1 delay=0ms bw=2
h3:g1 delay=0ms bw=1
h4:g1 delay=0ms bw=3




As per my understanding, between h2 and g1 there should be 2 faces created but I am finding only one face created for this, and the other connection I have to make explicitly. Please confirm if this is expected behavior,  if I am doing anything wrong  or my understanding is wrong.


For g1, faces are :
Faces:
  faceid=1 remote=internal:// local=internal:// counters={in={0i 81d 0B} out={132i 0d 0B}} local persistent point-to-point
  faceid=254 remote=contentstore:// local=contentstore:// counters={in={0i 0d 0B} out={0i 0d 0B}} local persistent point-to-point
  faceid=255 remote=null:// local=null:// counters={in={0i 0d 0B} out={0i 0d 0B}} local persistent point-to-point
  faceid=256 remote=fd://18 local=unix:///run/g1.sock counters={in={92i 27d 36942B} out={27i 43d 45212B}} local on-demand point-to-point
  faceid=257 remote=fd://20 local=unix:///run/g1.sock counters={in={1022i 223d 208468B} out={912i 288d 231943B}} local on-demand point-to-point
  faceid=258 remote=udp4://1.0.0.1:6363 local=udp4://0.0.0.0:6363 counters={in={766i 74d 106769B} out={784i 89d 115716B}} non-local persistent point-to-point
  faceid=259 remote=udp4://1.0.0.5:6363 local=udp4://0.0.0.0:6363 counters={in={767i 65d 102476B} out={779i 89d 115339B}} non-local persistent point-to-point
  faceid=260 remote=udp4://1.0.0.13:6363 local=udp4://0.0.0.0:6363 counters={in={767i 67d 103289B} out={779i 89d 115605B}} non-local persistent point-to-point
  faceid=261 remote=udp4://1.0.0.17:6363 local=udp4://0.0.0.0:6363 counters={in={768i 68d 104006B} out={782i 89d 115879B}} non-local persistent point-to-point
  faceid=265 remote=udp4://1.0.0.9:6363 local=udp4://0.0.0.0:6363 counters={in={0i 0d 0B} out={0i 0d 0B}} non-local persistent point-to-point
  faceid=266 remote=fd://25 local=unix:///run/g1.sock counters={in={3i 0d 137B} out={0i 2d 903B}} local on-demand point-to-point


Highlighted one I created explicitly using nfdc register.
Also, please explain the significance of the counters [counters={in={0i 0d 0B} out={0i 0d 0B}}]






Best Regards,
Navdeep Uniyal


_______________________________________________
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/mini-ndn/attachments/20150813/fcce8f22/attachment.html>

From lanwang at memphis.edu  Thu Aug 13 04:19:04 2015
From: lanwang at memphis.edu (Lan Wang (lanwang))
Date: Thu, 13 Aug 2015 11:19:04 +0000
Subject: [Mini-NDN] [Nfd-dev] Doubts regarding face creation
In-Reply-To: <12DB5299AAAB1A40B17E72AB76FDA6D8EE24E2@PALLENE.office.hd>
References: <12DB5299AAAB1A40B17E72AB76FDA6D8EDC285@PALLENE.office.hd>
	<BY1PR0401MB16103F9F832AD0B78B2AD4B1D97E0@BY1PR0401MB1610.namprd04.prod.outlook.com>,
	<D3B13089-F795-4566-9372-649519774583@memphis.edu>
	<BY1PR0401MB1610C425A010721BE79C48B8D97E0@BY1PR0401MB1610.namprd04.prod.outlook.com>,
	<12DB5299AAAB1A40B17E72AB76FDA6D8EE24E2@PALLENE.office.hd>
Message-ID: <70967AC1-73D5-45AB-8D2C-FD3221C39CD8@memphis.edu>

Even if the parallel links exist in the interface and face list, if NLSR uses only one of them, the others will not be in the FIB and strategy won't see them (at least for now).  There may be a way for the strategy to get around this, but it is best to wait for Vince to answer the question (he is on vacation until Monday).

Lan (on phone)

On Aug 13, 2015, at 2:40 AM, Navdeep Uniyal <navdeep.uniyal at neclab.eu<mailto:navdeep.uniyal at neclab.eu>> wrote:

Actually I need to configure a multi interface gateway and by nfdc register I can create the face as mentioned below. The strategies like broadcast(which uses multi link) are able to transfer the interest messages over the links. But the issue I am seeing here is that the counters value are 0. Please if you can explain the significance of counters, According to my understanding they are just measuring the number of bytes going out and coming in through the interface(but what are the values i,d and B represents). Also, there is no management traffic going through the link( which might be because as you said that NLSR does not support multilinks as of now). My concern is will it have any impact on the way the traffic is sent if my strategy supports multi interface gateway?

Best Regards,
Navdeep Uniyal

From: Mini-NDN [mailto:mini-ndn-bounces at lists.cs.ucla.edu] On Behalf Of Ashlesh Gawande (agawande)
Sent: Mittwoch, 12. August 2015 21:34
To: Lan Wang (lanwang); mini-ndn at lists.cs.ucla.edu<mailto:mini-ndn at lists.cs.ucla.edu>
Subject: Re: [Mini-NDN] [Nfd-dev] Doubts regarding face creation


Maybe he just wants a static entry. I am not sure but he mentions using nfdc register to get the desired face list.

Ashlesh
________________________________
From: Mini-NDN <mini-ndn-bounces at lists.cs.ucla.edu<mailto:mini-ndn-bounces at lists.cs.ucla.edu>> on behalf of Lan Wang (lanwang) <lanwang at memphis.edu<mailto:lanwang at memphis.edu>>
Sent: Wednesday, August 12, 2015 2:22 PM
To: mini-ndn at lists.cs.ucla.edu<mailto:mini-ndn at lists.cs.ucla.edu>
Subject: [SPAM:###68] [SPAM:###68] Re: [Mini-NDN] [Nfd-dev] Doubts regarding face creation

Ashlesh,

I don't see how nfdc register is going to help if NLSR does not support parallel links (I may have misunderstood something).  But since Navdeep has joined the mini-ndn mailing list, let's move the discussion there.

Lan

On Aug 12, 2015, at 1:09 PM, Ashlesh Gawande (agawande) <agawande at memphis.edu<mailto:agawande at memphis.edu>> wrote:


Hi

So this is happening because NLSR does not support parallel links as of now. It will simply ignore the second neighbor in the configuration file. I have filed a feature request:
http://redmine.named-data.net/issues/3097
But it will not be in the near future as it requires some design and implementation work.

Right now you will have to do that manually. If your topology is fixed you can do it within the code
so you don't have to do it manually every time the topology comes up.

Example: In bin/minindn you can do something like net.hosts['g1'].cmd("nfdc register ....")

Ashlesh
________________________________
From: Nfd-dev <nfd-dev-bounces at lists.cs.ucla.edu<mailto:nfd-dev-bounces at lists.cs.ucla.edu>> on behalf of Navdeep Uniyal <navdeep.uniyal at neclab.eu<mailto:navdeep.uniyal at neclab.eu>>
Sent: Wednesday, August 12, 2015 3:51 AM
To: nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>
Subject: [Nfd-dev] Doubts regarding face creation

Hello All,


I am working on minindn. While creating the topology I am using the following configuration file:
[nodes]
h1: _
h2: _
h3: _
h4: _
g1: _
[links]
h1:g1 delay=10ms bw=10
h2:g1 delay=5ms bw=1
h2:g1 delay=0ms bw=2
h3:g1 delay=0ms bw=1
h4:g1 delay=0ms bw=3




As per my understanding, between h2 and g1 there should be 2 faces created but I am finding only one face created for this, and the other connection I have to make explicitly. Please confirm if this is expected behavior,  if I am doing anything wrong  or my understanding is wrong.


For g1, faces are :
Faces:
  faceid=1 remote=internal:// local=internal:// counters={in={0i 81d 0B} out={132i 0d 0B}} local persistent point-to-point
  faceid=254 remote=contentstore:// local=contentstore:// counters={in={0i 0d 0B} out={0i 0d 0B}} local persistent point-to-point
  faceid=255 remote=null:// local=null:// counters={in={0i 0d 0B} out={0i 0d 0B}} local persistent point-to-point
  faceid=256 remote=fd://18 local=unix:///run/g1.sock counters={in={92i 27d 36942B} out={27i 43d 45212B}} local on-demand point-to-point
  faceid=257 remote=fd://20 local=unix:///run/g1.sock counters={in={1022i 223d 208468B} out={912i 288d 231943B}} local on-demand point-to-point
  faceid=258 remote=udp4://1.0.0.1:6363 local=udp4://0.0.0.0:6363 counters={in={766i 74d 106769B} out={784i 89d 115716B}} non-local persistent point-to-point
  faceid=259 remote=udp4://1.0.0.5:6363 local=udp4://0.0.0.0:6363 counters={in={767i 65d 102476B} out={779i 89d 115339B}} non-local persistent point-to-point
  faceid=260 remote=udp4://1.0.0.13:6363 local=udp4://0.0.0.0:6363 counters={in={767i 67d 103289B} out={779i 89d 115605B}} non-local persistent point-to-point
  faceid=261 remote=udp4://1.0.0.17:6363 local=udp4://0.0.0.0:6363 counters={in={768i 68d 104006B} out={782i 89d 115879B}} non-local persistent point-to-point
  faceid=265 remote=udp4://1.0.0.9:6363 local=udp4://0.0.0.0:6363 counters={in={0i 0d 0B} out={0i 0d 0B}} non-local persistent point-to-point
  faceid=266 remote=fd://25 local=unix:///run/g1.sock counters={in={3i 0d 137B} out={0i 2d 903B}} local on-demand point-to-point


Highlighted one I created explicitly using nfdc register.
Also, please explain the significance of the counters [counters={in={0i 0d 0B} out={0i 0d 0B}}]






Best Regards,
Navdeep Uniyal


_______________________________________________
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/mini-ndn/attachments/20150813/b3356579/attachment.html>

From vslehman at memphis.edu  Mon Aug 17 10:36:58 2015
From: vslehman at memphis.edu (Vince Lehman (vslehman))
Date: Mon, 17 Aug 2015 17:36:58 +0000
Subject: [Mini-NDN] [Nfd-dev] Doubts regarding face creation
In-Reply-To: <70967AC1-73D5-45AB-8D2C-FD3221C39CD8@memphis.edu>
References: <12DB5299AAAB1A40B17E72AB76FDA6D8EDC285@PALLENE.office.hd>
	<BY1PR0401MB16103F9F832AD0B78B2AD4B1D97E0@BY1PR0401MB1610.namprd04.prod.outlook.com>
	<D3B13089-F795-4566-9372-649519774583@memphis.edu>
	<BY1PR0401MB1610C425A010721BE79C48B8D97E0@BY1PR0401MB1610.namprd04.prod.outlook.com>
	<12DB5299AAAB1A40B17E72AB76FDA6D8EE24E2@PALLENE.office.hd>
	<70967AC1-73D5-45AB-8D2C-FD3221C39CD8@memphis.edu>
Message-ID: <EC92AF16-6988-4ED9-9D39-7B77B62A95B6@memphis.edu>

Hi Navdeep,

Currently, NLSR is designed to only consider one Face per configured neighbor. Also, NLSR is only aware of Faces that it itself attempts to create.

For these reasons, you will not see management traffic travel through a Face created externally from NLSR, and NLSR will not install the externally created Face as a next hop for any routes.

Please if you can explain the significance of counters, According to my understanding they are just measuring the number of bytes going out and coming in through the interface(but what are the values i,d and B represents).

i is the number of Interests traveling through the Face, d is the number of Data traveling through the Face, and B is the byte count.

My concern is will it have any impact on the way the traffic is sent if my strategy supports multi interface gateway?

If you have two Faces that can be used to retrieve data for the prefix /ndn/example where one Face was created by NLSR and the other using nfdc, you will need to manually register the externally created Face as a route for /ndn/example. Otherwise, the externally created Face will not be in the FIB entry for /ndn/example, and your strategy will not have the externally created Face as a forwarding option.

--
Vince Lehman

On Aug 13, 2015, at 6:19 AM, Lan Wang (lanwang) <lanwang at memphis.edu<mailto:lanwang at memphis.edu>> wrote:

Even if the parallel links exist in the interface and face list, if NLSR uses only one of them, the others will not be in the FIB and strategy won't see them (at least for now).  There may be a way for the strategy to get around this, but it is best to wait for Vince to answer the question (he is on vacation until Monday).

Lan (on phone)

On Aug 13, 2015, at 2:40 AM, Navdeep Uniyal <navdeep.uniyal at neclab.eu<mailto:navdeep.uniyal at neclab.eu>> wrote:

Actually I need to configure a multi interface gateway and by nfdc register I can create the face as mentioned below. The strategies like broadcast(which uses multi link) are able to transfer the interest messages over the links. But the issue I am seeing here is that the counters value are 0. Please if you can explain the significance of counters, According to my understanding they are just measuring the number of bytes going out and coming in through the interface(but what are the values i,d and B represents). Also, there is no management traffic going through the link( which might be because as you said that NLSR does not support multilinks as of now). My concern is will it have any impact on the way the traffic is sent if my strategy supports multi interface gateway?

Best Regards,
Navdeep Uniyal

From: Mini-NDN [mailto:mini-ndn-bounces at lists.cs.ucla.edu] On Behalf Of Ashlesh Gawande (agawande)
Sent: Mittwoch, 12. August 2015 21:34
To: Lan Wang (lanwang); mini-ndn at lists.cs.ucla.edu<mailto:mini-ndn at lists.cs.ucla.edu>
Subject: Re: [Mini-NDN] [Nfd-dev] Doubts regarding face creation

Maybe he just wants a static entry. I am not sure but he mentions using nfdc register to get the desired face list.

Ashlesh
________________________________
From: Mini-NDN <mini-ndn-bounces at lists.cs.ucla.edu<mailto:mini-ndn-bounces at lists.cs.ucla.edu>> on behalf of Lan Wang (lanwang) <lanwang at memphis.edu<mailto:lanwang at memphis.edu>>
Sent: Wednesday, August 12, 2015 2:22 PM
To: mini-ndn at lists.cs.ucla.edu<mailto:mini-ndn at lists.cs.ucla.edu>
Subject: [SPAM:###68] [SPAM:###68] Re: [Mini-NDN] [Nfd-dev] Doubts regarding face creation

Ashlesh,

I don't see how nfdc register is going to help if NLSR does not support parallel links (I may have misunderstood something).  But since Navdeep has joined the mini-ndn mailing list, let's move the discussion there.

Lan

On Aug 12, 2015, at 1:09 PM, Ashlesh Gawande (agawande) <agawande at memphis.edu<mailto:agawande at memphis.edu>> wrote:


Hi

So this is happening because NLSR does not support parallel links as of now. It will simply ignore the second neighbor in the configuration file. I have filed a feature request:
http://redmine.named-data.net/issues/3097
But it will not be in the near future as it requires some design and implementation work.

Right now you will have to do that manually. If your topology is fixed you can do it within the code
so you don't have to do it manually every time the topology comes up.

Example: In bin/minindn you can do something like net.hosts['g1'].cmd("nfdc register ....")

Ashlesh
________________________________
From: Nfd-dev <nfd-dev-bounces at lists.cs.ucla.edu<mailto:nfd-dev-bounces at lists.cs.ucla.edu>> on behalf of Navdeep Uniyal <navdeep.uniyal at neclab.eu<mailto:navdeep.uniyal at neclab.eu>>
Sent: Wednesday, August 12, 2015 3:51 AM
To: nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>
Subject: [Nfd-dev] Doubts regarding face creation

Hello All,

I am working on minindn. While creating the topology I am using the following configuration file:
[nodes]
h1: _
h2: _
h3: _
h4: _
g1: _
[links]
h1:g1 delay=10ms bw=10
h2:g1 delay=5ms bw=1
h2:g1 delay=0ms bw=2
h3:g1 delay=0ms bw=1
h4:g1 delay=0ms bw=3


As per my understanding, between h2 and g1 there should be 2 faces created but I am finding only one face created for this, and the other connection I have to make explicitly. Please confirm if this is expected behavior,  if I am doing anything wrong  or my understanding is wrong.

For g1, faces are :
Faces:
  faceid=1 remote=internal:// local=internal:// counters={in={0i 81d 0B} out={132i 0d 0B}} local persistent point-to-point
  faceid=254 remote=contentstore:// local=contentstore:// counters={in={0i 0d 0B} out={0i 0d 0B}} local persistent point-to-point
  faceid=255 remote=null:// local=null:// counters={in={0i 0d 0B} out={0i 0d 0B}} local persistent point-to-point
  faceid=256 remote=fd://18 local=unix:///run/g1.sock counters={in={92i 27d 36942B} out={27i 43d 45212B}} local on-demand point-to-point
  faceid=257 remote=fd://20 local=unix:///run/g1.sock counters={in={1022i 223d 208468B} out={912i 288d 231943B}} local on-demand point-to-point
  faceid=258 remote=udp4://1.0.0.1:6363 local=udp4://0.0.0.0:6363 counters={in={766i 74d 106769B} out={784i 89d 115716B}} non-local persistent point-to-point
  faceid=259 remote=udp4://1.0.0.5:6363 local=udp4://0.0.0.0:6363 counters={in={767i 65d 102476B} out={779i 89d 115339B}} non-local persistent point-to-point
  faceid=260 remote=udp4://1.0.0.13:6363 local=udp4://0.0.0.0:6363 counters={in={767i 67d 103289B} out={779i 89d 115605B}} non-local persistent point-to-point
  faceid=261 remote=udp4://1.0.0.17:6363 local=udp4://0.0.0.0:6363 counters={in={768i 68d 104006B} out={782i 89d 115879B}} non-local persistent point-to-point
  faceid=265 remote=udp4://1.0.0.9:6363 local=udp4://0.0.0.0:6363 counters={in={0i 0d 0B} out={0i 0d 0B}} non-local persistent point-to-point
  faceid=266 remote=fd://25 local=unix:///run/g1.sock counters={in={3i 0d 137B} out={0i 2d 903B}} local on-demand point-to-point

Highlighted one I created explicitly using nfdc register.
Also, please explain the significance of the counters [counters={in={0i 0d 0B} out={0i 0d 0B}}]



Best Regards,
Navdeep Uniyal

_______________________________________________
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

_______________________________________________
Mini-NDN mailing list
Mini-NDN at lists.cs.ucla.edu<mailto:Mini-NDN at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/mini-ndn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/mini-ndn/attachments/20150817/b9c9076f/attachment.html>

From navdeep.uniyal at neclab.eu  Tue Aug 18 01:03:00 2015
From: navdeep.uniyal at neclab.eu (Navdeep Uniyal)
Date: Tue, 18 Aug 2015 08:03:00 +0000
Subject: [Mini-NDN] [Nfd-dev] Doubts regarding face creation
In-Reply-To: <EC92AF16-6988-4ED9-9D39-7B77B62A95B6@memphis.edu>
References: <12DB5299AAAB1A40B17E72AB76FDA6D8EDC285@PALLENE.office.hd>
	<BY1PR0401MB16103F9F832AD0B78B2AD4B1D97E0@BY1PR0401MB1610.namprd04.prod.outlook.com>
	<D3B13089-F795-4566-9372-649519774583@memphis.edu>
	<BY1PR0401MB1610C425A010721BE79C48B8D97E0@BY1PR0401MB1610.namprd04.prod.outlook.com>
	<12DB5299AAAB1A40B17E72AB76FDA6D8EE24E2@PALLENE.office.hd>
	<70967AC1-73D5-45AB-8D2C-FD3221C39CD8@memphis.edu>
	<EC92AF16-6988-4ED9-9D39-7B77B62A95B6@memphis.edu>
Message-ID: <12DB5299AAAB1A40B17E72AB76FDA6D8EE35C5@PALLENE.office.hd>

Thank you Vince for the explanation.
In case I have manually registered the face, will NLSR support parallel interest transmission and data download over various interfaces?


Best Regards,
Navdeep Uniyal

From: Vince Lehman (vslehman) [mailto:vslehman at memphis.edu]
Sent: Montag, 17. August 2015 19:37
To: Navdeep Uniyal
Cc: Lan Wang (lanwang); mini-ndn at lists.cs.ucla.edu
Subject: Re: [Mini-NDN] [Nfd-dev] Doubts regarding face creation

Hi Navdeep,

Currently, NLSR is designed to only consider one Face per configured neighbor. Also, NLSR is only aware of Faces that it itself attempts to create.

For these reasons, you will not see management traffic travel through a Face created externally from NLSR, and NLSR will not install the externally created Face as a next hop for any routes.

Please if you can explain the significance of counters, According to my understanding they are just measuring the number of bytes going out and coming in through the interface(but what are the values i,d and B represents).

i is the number of Interests traveling through the Face, d is the number of Data traveling through the Face, and B is the byte count.

My concern is will it have any impact on the way the traffic is sent if my strategy supports multi interface gateway?

If you have two Faces that can be used to retrieve data for the prefix /ndn/example where one Face was created by NLSR and the other using nfdc, you will need to manually register the externally created Face as a route for /ndn/example. Otherwise, the externally created Face will not be in the FIB entry for /ndn/example, and your strategy will not have the externally created Face as a forwarding option.

--
Vince Lehman

On Aug 13, 2015, at 6:19 AM, Lan Wang (lanwang) <lanwang at memphis.edu<mailto:lanwang at memphis.edu>> wrote:

Even if the parallel links exist in the interface and face list, if NLSR uses only one of them, the others will not be in the FIB and strategy won't see them (at least for now).  There may be a way for the strategy to get around this, but it is best to wait for Vince to answer the question (he is on vacation until Monday).

Lan (on phone)

On Aug 13, 2015, at 2:40 AM, Navdeep Uniyal <navdeep.uniyal at neclab.eu<mailto:navdeep.uniyal at neclab.eu>> wrote:
Actually I need to configure a multi interface gateway and by nfdc register I can create the face as mentioned below. The strategies like broadcast(which uses multi link) are able to transfer the interest messages over the links. But the issue I am seeing here is that the counters value are 0. Please if you can explain the significance of counters, According to my understanding they are just measuring the number of bytes going out and coming in through the interface(but what are the values i,d and B represents). Also, there is no management traffic going through the link( which might be because as you said that NLSR does not support multilinks as of now). My concern is will it have any impact on the way the traffic is sent if my strategy supports multi interface gateway?

Best Regards,
Navdeep Uniyal

From: Mini-NDN [mailto:mini-ndn-bounces at lists.cs.ucla.edu] On Behalf Of Ashlesh Gawande (agawande)
Sent: Mittwoch, 12. August 2015 21:34
To: Lan Wang (lanwang); mini-ndn at lists.cs.ucla.edu<mailto:mini-ndn at lists.cs.ucla.edu>
Subject: Re: [Mini-NDN] [Nfd-dev] Doubts regarding face creation

Maybe he just wants a static entry. I am not sure but he mentions using nfdc register to get the desired face list.

Ashlesh
________________________________
From: Mini-NDN <mini-ndn-bounces at lists.cs.ucla.edu<mailto:mini-ndn-bounces at lists.cs.ucla.edu>> on behalf of Lan Wang (lanwang) <lanwang at memphis.edu<mailto:lanwang at memphis.edu>>
Sent: Wednesday, August 12, 2015 2:22 PM
To: mini-ndn at lists.cs.ucla.edu<mailto:mini-ndn at lists.cs.ucla.edu>
Subject: [SPAM:###68] [SPAM:###68] Re: [Mini-NDN] [Nfd-dev] Doubts regarding face creation

Ashlesh,

I don't see how nfdc register is going to help if NLSR does not support parallel links (I may have misunderstood something).  But since Navdeep has joined the mini-ndn mailing list, let's move the discussion there.

Lan

On Aug 12, 2015, at 1:09 PM, Ashlesh Gawande (agawande) <agawande at memphis.edu<mailto:agawande at memphis.edu>> wrote:



Hi

So this is happening because NLSR does not support parallel links as of now. It will simply ignore the second neighbor in the configuration file. I have filed a feature request:
http://redmine.named-data.net/issues/3097
But it will not be in the near future as it requires some design and implementation work.

Right now you will have to do that manually. If your topology is fixed you can do it within the code
so you don't have to do it manually every time the topology comes up.

Example: In bin/minindn you can do something like net.hosts['g1'].cmd("nfdc register ....")

Ashlesh
________________________________
From: Nfd-dev <nfd-dev-bounces at lists.cs.ucla.edu<mailto:nfd-dev-bounces at lists.cs.ucla.edu>> on behalf of Navdeep Uniyal <navdeep.uniyal at neclab.eu<mailto:navdeep.uniyal at neclab.eu>>
Sent: Wednesday, August 12, 2015 3:51 AM
To: nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>
Subject: [Nfd-dev] Doubts regarding face creation

Hello All,

I am working on minindn. While creating the topology I am using the following configuration file:
[nodes]
h1: _
h2: _
h3: _
h4: _
g1: _
[links]
h1:g1 delay=10ms bw=10
h2:g1 delay=5ms bw=1
h2:g1 delay=0ms bw=2
h3:g1 delay=0ms bw=1
h4:g1 delay=0ms bw=3


As per my understanding, between h2 and g1 there should be 2 faces created but I am finding only one face created for this, and the other connection I have to make explicitly. Please confirm if this is expected behavior,  if I am doing anything wrong  or my understanding is wrong.

For g1, faces are :
Faces:
  faceid=1 remote=internal:// local=internal:// counters={in={0i 81d 0B} out={132i 0d 0B}} local persistent point-to-point
  faceid=254 remote=contentstore:// local=contentstore:// counters={in={0i 0d 0B} out={0i 0d 0B}} local persistent point-to-point
  faceid=255 remote=null:// local=null:// counters={in={0i 0d 0B} out={0i 0d 0B}} local persistent point-to-point
  faceid=256 remote=fd://18 local=unix:///run/g1.sock<unix://run/g1.sock> counters={in={92i 27d 36942B} out={27i 43d 45212B}} local on-demand point-to-point
  faceid=257 remote=fd://20 local=unix:///run/g1.sock<unix://run/g1.sock> counters={in={1022i 223d 208468B} out={912i 288d 231943B}} local on-demand point-to-point
  faceid=258 remote=udp4://1.0.0.1:6363 local=udp4://0.0.0.0:6363 counters={in={766i 74d 106769B} out={784i 89d 115716B}} non-local persistent point-to-point
  faceid=259 remote=udp4://1.0.0.5:6363 local=udp4://0.0.0.0:6363 counters={in={767i 65d 102476B} out={779i 89d 115339B}} non-local persistent point-to-point
  faceid=260 remote=udp4://1.0.0.13:6363 local=udp4://0.0.0.0:6363 counters={in={767i 67d 103289B} out={779i 89d 115605B}} non-local persistent point-to-point
  faceid=261 remote=udp4://1.0.0.17:6363 local=udp4://0.0.0.0:6363 counters={in={768i 68d 104006B} out={782i 89d 115879B}} non-local persistent point-to-point
  faceid=265 remote=udp4://1.0.0.9:6363 local=udp4://0.0.0.0:6363 counters={in={0i 0d 0B} out={0i 0d 0B}} non-local persistent point-to-point
  faceid=266 remote=fd://25 local=unix:///run/g1.sock<unix://run/g1.sock> counters={in={3i 0d 137B} out={0i 2d 903B}} local on-demand point-to-point

Highlighted one I created explicitly using nfdc register.
Also, please explain the significance of the counters [counters={in={0i 0d 0B} out={0i 0d 0B}}]



Best Regards,
Navdeep Uniyal

_______________________________________________
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

_______________________________________________
Mini-NDN mailing list
Mini-NDN at lists.cs.ucla.edu<mailto:Mini-NDN at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/mini-ndn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/mini-ndn/attachments/20150818/a2ac3104/attachment.html>

From vslehman at memphis.edu  Wed Aug 19 07:20:47 2015
From: vslehman at memphis.edu (Vince Lehman (vslehman))
Date: Wed, 19 Aug 2015 14:20:47 +0000
Subject: [Mini-NDN] [Nfd-dev] Doubts regarding face creation
In-Reply-To: <12DB5299AAAB1A40B17E72AB76FDA6D8EE35C5@PALLENE.office.hd>
References: <12DB5299AAAB1A40B17E72AB76FDA6D8EDC285@PALLENE.office.hd>
	<BY1PR0401MB16103F9F832AD0B78B2AD4B1D97E0@BY1PR0401MB1610.namprd04.prod.outlook.com>
	<D3B13089-F795-4566-9372-649519774583@memphis.edu>
	<BY1PR0401MB1610C425A010721BE79C48B8D97E0@BY1PR0401MB1610.namprd04.prod.outlook.com>
	<12DB5299AAAB1A40B17E72AB76FDA6D8EE24E2@PALLENE.office.hd>
	<70967AC1-73D5-45AB-8D2C-FD3221C39CD8@memphis.edu>
	<EC92AF16-6988-4ED9-9D39-7B77B62A95B6@memphis.edu>
	<12DB5299AAAB1A40B17E72AB76FDA6D8EE35C5@PALLENE.office.hd>
Message-ID: <FB2912FB-8C60-4B33-B1C8-4DF78917167F@memphis.edu>

Navdeep,

NLSR only manages the routes to reach advertised name prefixes. The forwarding strategy in use for the name prefixes will need to implement support for parallel Interest transmission and data download.

--
Vince Lehman

On Aug 18, 2015, at 3:03 AM, Navdeep Uniyal <navdeep.uniyal at neclab.eu<mailto:navdeep.uniyal at neclab.eu>> wrote:

Thank you Vince for the explanation.
In case I have manually registered the face, will NLSR support parallel interest transmission and data download over various interfaces?


Best Regards,
Navdeep Uniyal

From: Vince Lehman (vslehman) [mailto:vslehman at memphis.edu]
Sent: Montag, 17. August 2015 19:37
To: Navdeep Uniyal
Cc: Lan Wang (lanwang); mini-ndn at lists.cs.ucla.edu<mailto:mini-ndn at lists.cs.ucla.edu>
Subject: Re: [Mini-NDN] [Nfd-dev] Doubts regarding face creation

Hi Navdeep,

Currently, NLSR is designed to only consider one Face per configured neighbor. Also, NLSR is only aware of Faces that it itself attempts to create.

For these reasons, you will not see management traffic travel through a Face created externally from NLSR, and NLSR will not install the externally created Face as a next hop for any routes.

Please if you can explain the significance of counters, According to my understanding they are just measuring the number of bytes going out and coming in through the interface(but what are the values i,d and B represents).

i is the number of Interests traveling through the Face, d is the number of Data traveling through the Face, and B is the byte count.

My concern is will it have any impact on the way the traffic is sent if my strategy supports multi interface gateway?

If you have two Faces that can be used to retrieve data for the prefix /ndn/example where one Face was created by NLSR and the other using nfdc, you will need to manually register the externally created Face as a route for /ndn/example. Otherwise, the externally created Face will not be in the FIB entry for /ndn/example, and your strategy will not have the externally created Face as a forwarding option.

--
Vince Lehman

On Aug 13, 2015, at 6:19 AM, Lan Wang (lanwang) <lanwang at memphis.edu<mailto:lanwang at memphis.edu>> wrote:

Even if the parallel links exist in the interface and face list, if NLSR uses only one of them, the others will not be in the FIB and strategy won't see them (at least for now).  There may be a way for the strategy to get around this, but it is best to wait for Vince to answer the question (he is on vacation until Monday).

Lan (on phone)

On Aug 13, 2015, at 2:40 AM, Navdeep Uniyal <navdeep.uniyal at neclab.eu<mailto:navdeep.uniyal at neclab.eu>> wrote:
Actually I need to configure a multi interface gateway and by nfdc register I can create the face as mentioned below. The strategies like broadcast(which uses multi link) are able to transfer the interest messages over the links. But the issue I am seeing here is that the counters value are 0. Please if you can explain the significance of counters, According to my understanding they are just measuring the number of bytes going out and coming in through the interface(but what are the values i,d and B represents). Also, there is no management traffic going through the link( which might be because as you said that NLSR does not support multilinks as of now). My concern is will it have any impact on the way the traffic is sent if my strategy supports multi interface gateway?

Best Regards,
Navdeep Uniyal

From: Mini-NDN [mailto:mini-ndn-bounces at lists.cs.ucla.edu] On Behalf Of Ashlesh Gawande (agawande)
Sent: Mittwoch, 12. August 2015 21:34
To: Lan Wang (lanwang); mini-ndn at lists.cs.ucla.edu<mailto:mini-ndn at lists.cs.ucla.edu>
Subject: Re: [Mini-NDN] [Nfd-dev] Doubts regarding face creation

Maybe he just wants a static entry. I am not sure but he mentions using nfdc register to get the desired face list.

Ashlesh
________________________________
From: Mini-NDN <mini-ndn-bounces at lists.cs.ucla.edu<mailto:mini-ndn-bounces at lists.cs.ucla.edu>> on behalf of Lan Wang (lanwang) <lanwang at memphis.edu<mailto:lanwang at memphis.edu>>
Sent: Wednesday, August 12, 2015 2:22 PM
To: mini-ndn at lists.cs.ucla.edu<mailto:mini-ndn at lists.cs.ucla.edu>
Subject: [SPAM:###68] [SPAM:###68] Re: [Mini-NDN] [Nfd-dev] Doubts regarding face creation

Ashlesh,

I don't see how nfdc register is going to help if NLSR does not support parallel links (I may have misunderstood something).  But since Navdeep has joined the mini-ndn mailing list, let's move the discussion there.

Lan

On Aug 12, 2015, at 1:09 PM, Ashlesh Gawande (agawande) <agawande at memphis.edu<mailto:agawande at memphis.edu>> wrote:



Hi

So this is happening because NLSR does not support parallel links as of now. It will simply ignore the second neighbor in the configuration file. I have filed a feature request:
http://redmine.named-data.net/issues/3097
But it will not be in the near future as it requires some design and implementation work.

Right now you will have to do that manually. If your topology is fixed you can do it within the code
so you don't have to do it manually every time the topology comes up.

Example: In bin/minindn you can do something like net.hosts['g1'].cmd("nfdc register ....")

Ashlesh
________________________________
From: Nfd-dev <nfd-dev-bounces at lists.cs.ucla.edu<mailto:nfd-dev-bounces at lists.cs.ucla.edu>> on behalf of Navdeep Uniyal <navdeep.uniyal at neclab.eu<mailto:navdeep.uniyal at neclab.eu>>
Sent: Wednesday, August 12, 2015 3:51 AM
To: nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>
Subject: [Nfd-dev] Doubts regarding face creation

Hello All,

I am working on minindn. While creating the topology I am using the following configuration file:
[nodes]
h1: _
h2: _
h3: _
h4: _
g1: _
[links]
h1:g1 delay=10ms bw=10
h2:g1 delay=5ms bw=1
h2:g1 delay=0ms bw=2
h3:g1 delay=0ms bw=1
h4:g1 delay=0ms bw=3


As per my understanding, between h2 and g1 there should be 2 faces created but I am finding only one face created for this, and the other connection I have to make explicitly. Please confirm if this is expected behavior,  if I am doing anything wrong  or my understanding is wrong.

For g1, faces are :
Faces:
  faceid=1 remote=internal:// local=internal:// counters={in={0i 81d 0B} out={132i 0d 0B}} local persistent point-to-point
  faceid=254 remote=contentstore:// local=contentstore:// counters={in={0i 0d 0B} out={0i 0d 0B}} local persistent point-to-point
  faceid=255 remote=null:// local=null:// counters={in={0i 0d 0B} out={0i 0d 0B}} local persistent point-to-point
  faceid=256 remote=fd://18 local=unix:///run/g1.sock<unix://run/g1.sock> counters={in={92i 27d 36942B} out={27i 43d 45212B}} local on-demand point-to-point
  faceid=257 remote=fd://20 local=unix:///run/g1.sock<unix://run/g1.sock> counters={in={1022i 223d 208468B} out={912i 288d 231943B}} local on-demand point-to-point
  faceid=258 remote=udp4://1.0.0.1:6363 local=udp4://0.0.0.0:6363 counters={in={766i 74d 106769B} out={784i 89d 115716B}} non-local persistent point-to-point
  faceid=259 remote=udp4://1.0.0.5:6363 local=udp4://0.0.0.0:6363 counters={in={767i 65d 102476B} out={779i 89d 115339B}} non-local persistent point-to-point
  faceid=260 remote=udp4://1.0.0.13:6363 local=udp4://0.0.0.0:6363 counters={in={767i 67d 103289B} out={779i 89d 115605B}} non-local persistent point-to-point
  faceid=261 remote=udp4://1.0.0.17:6363 local=udp4://0.0.0.0:6363 counters={in={768i 68d 104006B} out={782i 89d 115879B}} non-local persistent point-to-point
  faceid=265 remote=udp4://1.0.0.9:6363 local=udp4://0.0.0.0:6363 counters={in={0i 0d 0B} out={0i 0d 0B}} non-local persistent point-to-point
  faceid=266 remote=fd://25 local=unix:///run/g1.sock<unix://run/g1.sock> counters={in={3i 0d 137B} out={0i 2d 903B}} local on-demand point-to-point

Highlighted one I created explicitly using nfdc register.
Also, please explain the significance of the counters [counters={in={0i 0d 0B} out={0i 0d 0B}}]



Best Regards,
Navdeep Uniyal

_______________________________________________
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

_______________________________________________
Mini-NDN mailing list
Mini-NDN at lists.cs.ucla.edu<mailto:Mini-NDN at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/mini-ndn


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/mini-ndn/attachments/20150819/49449819/attachment.html>

From navdeep.uniyal at neclab.eu  Thu Aug 27 06:42:46 2015
From: navdeep.uniyal at neclab.eu (Navdeep Uniyal)
Date: Thu, 27 Aug 2015 13:42:46 +0000
Subject: [Mini-NDN] mini ndn performance
Message-ID: <12DB5299AAAB1A40B17E72AB76FDA6D8EE5925@PALLENE.office.hd>

Hello all,

I am trying to run a 10 node network on a VM with following configuration:
[:/chipset_16px.png]

System

Base Memory:

5124 MB

Processor(s):

2

Execution Cap:

100%

VT-x/AMD-V:

Enabled

Nested Paging:

Enabled


Base System has Intel(r) Core2 Duo CPU @3.00 GHz.

With this configuration I am facing some performance issues while running nfd commands or while sending out interest messages. Could you please let me know if there is some minimum requirement to run minindn and what is the recommended configuration of the system.
With less node network it is working fine.



Best Regards,
Navdeep Uniyal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/mini-ndn/attachments/20150827/8d4b8295/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 174 bytes
Desc: image001.png
URL: <http://www.lists.cs.ucla.edu/pipermail/mini-ndn/attachments/20150827/8d4b8295/attachment.png>

From agawande at memphis.edu  Thu Aug 27 08:04:04 2015
From: agawande at memphis.edu (Ashlesh Gawande (agawande))
Date: Thu, 27 Aug 2015 15:04:04 +0000
Subject: [Mini-NDN] mini ndn performance
In-Reply-To: <12DB5299AAAB1A40B17E72AB76FDA6D8EE5925@PALLENE.office.hd>
References: <12DB5299AAAB1A40B17E72AB76FDA6D8EE5925@PALLENE.office.hd>
Message-ID: <CY1PR0401MB1615487B8A8C007A21F09E4FD96F0@CY1PR0401MB1615.namprd04.prod.outlook.com>

Scalability depends on the amount of CPU you have since we are running multiple instances of NFD and NLSR plus any other traffic.

It also depends on how much logging you have turned on and how much other things you are logging simultaneously.

If you are logging a lot of things I would suggest switching to RAM disk
(http://www.jamescoyle.net/how-to/943-create-a-ram-disk-in-linux)

And change all the instances of /tmp in mini-ndn to /mnt/ramdisk (if that is the name you have chosen for your ram disk).

If logging is not high then you will have to switch to a machine which has more CPU/cores.

Ashlesh
________________________________
From: Mini-NDN <mini-ndn-bounces at lists.cs.ucla.edu> on behalf of Navdeep Uniyal <navdeep.uniyal at neclab.eu>
Sent: Thursday, August 27, 2015 8:42 AM
To: mini-ndn at lists.cs.ucla.edu
Subject: [Mini-NDN] mini ndn performance


Hello all,



I am trying to run a 10 node network on a VM with following configuration:

[:/chipset_16px.png]


System


Base Memory:


5124 MB


Processor(s):


2


Execution Cap:


100%


VT-x/AMD-V:


Enabled


Nested Paging:


Enabled




Base System has Intel? Core2 Duo CPU @3.00 GHz.



With this configuration I am facing some performance issues while running nfd commands or while sending out interest messages. Could you please let me know if there is some minimum requirement to run minindn and what is the recommended configuration of the system.

With less node network it is working fine.







Best Regards,

Navdeep Uniyal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/mini-ndn/attachments/20150827/cae7cc77/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 174 bytes
Desc: image001.png
URL: <http://www.lists.cs.ucla.edu/pipermail/mini-ndn/attachments/20150827/cae7cc77/attachment.png>