[Mini-NDN] [Nfd-dev] Doubts regarding face creation

Wed Aug 19 07:20:47 PDT 2015

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>