[Mini-NDN] NdnRoutingHelper error in large topologies

Tue Mar 3 23:19:18 PST 2020

Hi Saurab,

thanks for your response. Please find my answers inline.

Thanks,
Philipp

On 3/4/20 5:32 AM, Saurab Dulal (sdulal) wrote:
> 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.
Thanks for clarifying, yesterday I thought that you suggest to use NLSR 
instead of the routing helper.
>
> 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.
Have you tried calculating the routes with libigraph? My experience from 
the IP-Routing helper is that calculating the routes is pretty fast and 
(at least in the 45 node topology) should not delay an experiment for 
longer than a few seconds. (Of course, applying the nfdc commands takes 
longer than a few secs)
>
> 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]
I think the answer depends on what you want to evaluate. However, maybe 
the fastest solution you could do is, to plan link failures in advance 
and pre-calculate shortest paths for the whole evaluation run in 
advance. When you actually fail a link during the evaluation, you just 
need to apply the pre-calculated shortest paths, which should be 
possible by simply looking at "nfdc route list" of each node and by 
modifing the existing entries. As I said above, pre-calculating shortest 
paths should not be an performance issue when using libigraph.
>
> 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.
I've got one more question regarding the routing helper. In mininet, you 
can easily test the connectivity between all nodes with mininets 
built-in pingall command. Is there something comparable available in 
Mini-NDN? In my evaluation topology, depending where my nodes are 
located, my application sometimes receives NACKs with reason NO_ROUTE. 
If a "pingall" functionality is available, I could easily debug the issue.
>
> 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/70029939/attachment.html>