[Mini-NDN] NdnRoutingHelper error in large topologies

[Saurab Dulal (sdulal)]

Hi Philipp,

Routing helper definately minimizes the cost incur by the routing protocols, I have tested this recently. Computing the routes and installing them to the fib is much faster than the NLSR. If you don't care about features offered by NLSR, I would definately suggest/encourage using it.

The primary purpose of the routing helper is to support very large topologies and to eliminate NLSR overhead. However, you need to be cautious while using large topology. Don't compute routes via all the faces, especially in the case of Link-state, this will take an enormous amount of time. Rather only compute the shortest path by passing 1 as an argument to this calculateNPossibleRoutes() function.

We are still working on to support prefix announcement/revocation and node addition/failure on routing helper. This will further help to perform node failure, mobility, and other experiments. [suggestions are welcome here]

Regarding the overhead, you are correct, most of it is caused by route addition and very little by face creation. Unfortunately, I don't have better improvement ideas for now.

Thanks for the feedback. Please let me know if you have more suggestions and concerns.

Regards,
Saurab Dulal


________________________________
From: Philipp Moll <philipp.moll at itec.aau.at>
Sent: Tuesday, March 3, 2020 12:45 PM
To: Saurab Dulal (sdulal) <sdulal at memphis.edu>; mini-ndn at lists.cs.ucla.edu <mini-ndn at lists.cs.ucla.edu>
Subject: Re: [Mini-NDN] NdnRoutingHelper error in large topologies


Hi Saurab,


thanks for looking in to that issue. The routing helper was my first choice because I thought it would minimize unforeseen side effects resulting from routing protocols in my evaluation. Do you think that using NLSR would be the better (faster / more stable / more resilient) choice for doing evaluations using MiniNDN?


My observation yesterday indicated that the lag results from registerRoute, not createFace in nfdc.py. This is why I achieved a significant speedup with my hack to only register one route only. But it seems that I don't need my hack anymore. Thanks for fixing the issue.


Best
Philipp


On 3/2/20 11:23 PM, Saurab Dulal (sdulal) wrote:
Hi Philipp,

Thank you so much for reporting the problem. I have found the bug and also have uploaded a patch in the gerrit. https://gerrit.named-data.net/c/mini-ndn/+/5957

However, your topology (45 nodes, 71 links) should be easily handled by minindn without routing helper (unless you specifically need it). I ran your topology with minindn in a vagrant box (4 gigs ram) without routing helper and it converged successfully in less than 5 minutes. I have also tested larger size topologies i.e. 150+ nodes, and 700+ links and they all have converged successfully.

I did some benchmark testing and found out that routing-helper especially in case of all face, link-state is pretty slow. But this is normal because you are creating an enormous amount of routes. With a single face, it's much better. Most of the lags are caused by face creation route addition. This is somewhat configurable in nfdc.py but still, I was not able to improve performance significantly. I have some improvements in my mind, just haven't got enough time to work on it.

Regards,
Saurab Dulal





________________________________
From: Mini-NDN <mini-ndn-bounces at lists.cs.ucla.edu><mailto:mini-ndn-bounces at lists.cs.ucla.edu> on behalf of Philipp Moll <philipp.moll at itec.aau.at><mailto:philipp.moll at itec.aau.at>
Sent: Friday, February 28, 2020 3:29 PM
To: mini-ndn at lists.cs.ucla.edu<mailto:mini-ndn at lists.cs.ucla.edu> <mini-ndn at lists.cs.ucla.edu><mailto:mini-ndn at lists.cs.ucla.edu>
Subject: [Mini-NDN] NdnRoutingHelper error in large topologies

Hi guys,

I am currently working on a MiniNDN scenario evaluation, where I need a
large network topology. I pushed the Geant topology to gerrit yesterday.
This topology has 45 nodes and quite high connectivity between the
nodes. Installing all possible routes with the NdnRoutingHelper takes
about 20 minutes. For me, this is too long when considering that my
actual evaluation only takes 10 minutes.

When restricting the routes to install to the shortest path only to save
time (NdnRoutingHelper.calculateNPossibleRoutes(nFaces=1)), the
computeDijkastra method fails in line 241 when using the Geant topology.

I am not familiar with the ndn_routing_helper code, that's why I'll use
a workaround. But maybe someone who is familiar with the routing-helper
can find the problem's cause.

Thanks,
Philipp

_______________________________________________
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/20200304/78ba8b04/attachment-0001.html>