named-data-ndnSIM / ndnSIM

ndnSIM: NS-3 based NDN simulator
GNU General Public License v3.0
108 stars 165 forks source link

Anomal/unexpected behavior of routing helpers and forwarding strategies. #71

Open aliaksander-samuseu opened 9 years ago

aliaksander-samuseu commented 9 years ago

Hi, this time it's a real issue. Though I presume I could also misenterpret the outputs due to a lack of knowledge about NDN, or experience with ndnSIM. Anyway, it looks very strange.

Please refer to these two pictures showing a diagrams based on PyVis's outputs during playback of the network model I'm currently working on (you can get source code and topology file here: http://rghost.ru/private/7GbYrKYBT/245f344bf0a66a3eb6397f53f7ef60f3; to run it in two producers' mode issue command like ./waf --run "ndnsim-multi2 --mode=two_producers" --vis)

Network model with a random balanced forwarding strategy in place: http://rghost.ru/private/6Ct7DZwtm/dee2716028425a81a679d87ac78e5773 Addition: I've just spotted it: it seems I miss-clicked in a hurry and made a mistake in one section of the network diagram above, the one claiming that tables are changing over time (at the right side of the diagram). If you pay attention to captions of two tables specified there, you'll see they are from 2 different adjacent routers. So please ignore this claim for now.

The very same network model with a broadcast forwarding strategy in place: http://rghost.ru/private/6nzCgqhPN/f627fcdb9c18c798a3bc8332ed89be21

I also marked and commented some anomalies in how FIB routing tables are being set accross the network on these diagrams, you should see if for yourself.

A brief summary: 1) Some devices have more than 2 ifaces, but it's always up to 2 records in their FIB (at least as shown by PyVis), and some of their links aren't used at all; some routers even become totally excluded from forwarding the traffic. 2) Sometimes in some FIB tables there is only one record (and it can be different tables during different runs, while no other options were changed) - see FIB for node 26 at the upper-left corner of the 1st diagram above. 3) Traffic doesn't cover all network even in broadcast scenario.

All this drew me to the following questions: 1) Between what and what is actually random load balancer balancing interests? Or what is percieved as the [possible] destinations for broadcast? Any iface on the host? Actual producers on the network? Judging from desctiption of random load balancer here - https://github.com/dibenede/ndn-tutorial-gec21 - it should send interests through any suitable random iface (i.e. which has a route to some producer/prefix). If only ifaces with routes to destinations in FIB are considered, than should we assume those routes are set incorrecly by helpers (i.e. some routers' ifaces don't have a route assosiated with prefixes/producers used/present in the network, though it's clear that there ARE possible routes to producers from ANY interface of ANY router, they only differ by their metrics), as random balancer and broadcast otherwise should have covered all the links with traffic in this topology? 2) Does the fact that whatever forwarding strategy I choose it results in no percievable difference on how traffic is distributed over the model diagram signify that routing/forwarding strategy isn't functioning correctly and simply falls back to default one (which is shortest path)?

Also needed to be mentioned that I tried to run one of the expamples that come with ndnSIM, setting the forwarding strategy in it to broadcast, and in this case network also wasn't fully covered with traffic.

aliaksander-samuseu commented 9 years ago

Thats how I'm setting up the routing tables atm:

ndn::StackHelper ndnHelper; ndnHelper.setCsSize(100); ndnHelper.InstallAll();

...

ndn::GlobalRoutingHelper ndnGlobalRoutingHelper; ndnGlobalRoutingHelper.InstallAll();

std::string prefix = "/prefix";

...

//ndn::StrategyChoiceHelper::InstallAll(prefix, "/localhost/nfd/strategy/broadcast"); ndn::StrategyChoiceHelper::Install<::nfd::fw::RandomLoadBalancerStrategy>(routerNodes, prefix);

...

/ / Add /prefix origins to ndn::GlobalRouter ndnGlobalRoutingHelper.AddOrigins(prefix, producers);

// Calculate and install FIBs ndn::GlobalRoutingHelper::CalculateRoutes();

aliaksander-samuseu commented 9 years ago

Here is a couple of code snippets from sources of mentioned strategies I've been trying to study, for your reference/convinience: http://pastebin.com/XJUB21Qs

aliaksander-samuseu commented 9 years ago

I've just spotted it: it seems I miss-clicked in a hurry and made a mistake in one section of 1st network diagram in my 1st post here, the one claiming that tables are changing over time (at the right side of the diagram). If you pay attention to captions of two tables specified there, you'll see they are from 2 different adjacent routers. So please ignore this claim for now.

aliaksander-samuseu commented 9 years ago

I'm sorry for being a nuisanse, but as I will have to submit my project on ndnsim soon, that would really helped to know is that intended behavior (and how comes it is), or it is a bug. If some of the developers will happen to read it till next Monday, I would really appreciated if they left a comment on this here. Thank you very much in advance.

cawka commented 9 years ago

I'll try to answer some of the questions.

1/ As you can see in https://github.com/named-data/ndnSIM/blob/master/examples/ndn-load-balancer/random-load-balancer-strategy.cpp#L84, the decision for this load balancer is based on the next hop faces that are associated with the FIB entry. Default behavior of the global routing helper (I'm assuming you're using it), is to calculate just one route... I'm kind of unsure why do you have multiple nexthops at routes. To address this issue you can try to use CalculateAllPossibleRoutes method of global controller, but I would personally recommend to just manually configure all routes.

2/ Not necessarily. If you happen to have only one next hop for a FIB entry, then all strategies will behave the same way, as there is nothing to choose from. When you have meaningfully multiple entries, then the strategy can try to play tricks.

aliaksander-samuseu commented 9 years ago

Hi, cawka.

Thank you for your time and hints you have provided. Though thats somewhat unexpected behavior for me, as if it works like this you rarely will be able to use any of these strategies when using ndnSIM framework the way it's shown in official examples, as they all set routes with simple "calculate routes" methods, which, as you mentioned, produce only one route per host. Could I suggest to mention this behavior in the guides on the project's site? That would have saved you a lot of time in the future by reducing a number of stupid questions you have to answer :) Can I also ask why are you suggesting not to use this CalculateAllPossibleRoutes method? I have a feeling that setting all these toutes manually will be extremely tedious job.

cawka commented 9 years ago

Yes, this is a good suggestion and we'll try to make it more clear in documentation. If you have time, we will really appreciate if you can help us with this.

Major reason that I'm hesitant to promote CalculateAllPossibleRoutes is that it is extremely slow, especially for relatively large topologies. Besides that, the logic that is put into this method does not necessarily fit all scenarios.