wifi multi-hop network ---> routing tables problem (OLSR)

[Marco Mezzavilla]

Dear all,

in my previous post (https://groups.google.com/forum/?fromgroups#!topic/ns-3-users/v9K5v6yGzbI) I was trying to identify the reason why a node that correctly received a packet did not forward it.

I thought that the problem was at the MAC level, but I've just noted that the real problem is at the IP level.

By analyzing the routing tables, I observed that the 'selfish' node does not forward the packet because it's missing some routing paths info.

SCENARIO:

one source node transmits TCP packets via bulk-send-application to a destination node that is 5 hops away (CHAIN topology).

(source)0 ---> 1 ---> 2 ---> 3 ---> 4 ---> 5(destination) 

NETWORK CONFIG:

- Wifi 802.11a

- TCP NewReno

- Fixed positions (100 meters inter-node distance)

- OLSR

The 'selfish' node is Node 3; it correctly received ACK=X, but it did not enqueued the packet in its transmission queue, approximately at time 46.  

In the following, please find the routing tables of each node at time 45.6.

As you can note, Node 3 does not 'see' Node 0.

NODE 0 

Destination   NextHop        Interface    Distance
10.1.1.2        10.1.1.2        1        1    
10.1.1.3        10.1.1.2        1        2    
10.1.1.4        10.1.1.2        1        3    
10.1.1.5        10.1.1.2        1        4    
10.1.1.6        10.1.1.2        1        5    

NODE 1

Destination   NextHop        Interface    Distance
10.1.1.1        10.1.1.1        1        1    
10.1.1.3        10.1.1.3        1        1    
10.1.1.4        10.1.1.3        1        2    
10.1.1.5        10.1.1.3        1        3    
10.1.1.6        10.1.1.3        1        4    

NODE 2
Destination   NextHop        Interface    Distance
10.1.1.1        10.1.1.2        1        2    
10.1.1.2        10.1.1.2        1        1    
10.1.1.4        10.1.1.4        1        1    
10.1.1.5        10.1.1.4        1        2    
10.1.1.6        10.1.1.4        1        3    

NODE 3

Destination   NextHop        Interface    Distance
10.1.1.2        10.1.1.3        1        2    
10.1.1.3        10.1.1.3        1        1    
10.1.1.5        10.1.1.5        1        1    
10.1.1.6        10.1.1.5        1        2    

NODE 4

Destination   NextHop        Interface    Distance
10.1.1.1        10.1.1.4        1        4    
10.1.1.2        10.1.1.4        1        3    
10.1.1.3        10.1.1.4        1        2    
10.1.1.4        10.1.1.4        1        1    
10.1.1.6        10.1.1.6        1        1    

NODE 5

Destination   NextHop        Interface    Distance
10.1.1.1        10.1.1.5        1        5    
10.1.1.2        10.1.1.5        1        4    
10.1.1.3        10.1.1.5        1        3    
10.1.1.4        10.1.1.5        1        2    
10.1.1.5        10.1.1.5        1        1

Later routing tables (time 46.4) show that also Node 4 and Node 5 stops having routing information about Node 0.

NODE 0

Destination   NextHop        Interface    Distance
10.1.1.2        10.1.1.2        1        1    
10.1.1.3        10.1.1.2        1        2    
10.1.1.4        10.1.1.2        1        3    
10.1.1.5        10.1.1.2        1        4    
10.1.1.6        10.1.1.2        1        5    

NODE 1
Destination   NextHop        Interface    Distance
10.1.1.1        10.1.1.1        1        1    
10.1.1.3        10.1.1.3        1        1    
10.1.1.4        10.1.1.3        1        2    
10.1.1.5        10.1.1.3        1        3    
10.1.1.6        10.1.1.3        1        4    

NODE 2
Destination   NextHop        Interface    Distance
10.1.1.1        10.1.1.2        1        2    
10.1.1.2        10.1.1.2        1        1    
10.1.1.4        10.1.1.4        1        1    
10.1.1.5        10.1.1.4        1        2    
10.1.1.6        10.1.1.4        1        3    

NODE 3
Destination   NextHop        Interface    Distance
10.1.1.2        10.1.1.3        1        2    
10.1.1.3        10.1.1.3        1        1    
10.1.1.5        10.1.1.5        1        1    
10.1.1.6        10.1.1.5        1        2    

NODE 4

Destination   NextHop        Interface    Distance
10.1.1.2        10.1.1.4        1        3    
10.1.1.3        10.1.1.4        1        2    
10.1.1.4        10.1.1.4        1        1    
10.1.1.6        10.1.1.6        1        1    

NODE 5

Destination    NextHop        Interface    Distance
10.1.1.2        10.1.1.5        1        4    
10.1.1.3        10.1.1.5        1        3    
10.1.1.4        10.1.1.5        1        2    
10.1.1.5        10.1.1.5        1        1

At around 50 seconds, the routing tables are again complete.

Please note that I am using OLSR routing with its default configuration, and the nodes are static... 

Does anybody have an idea?

Further, as I said, by evaluating 100s-long simulations with different seeds, this is occurring 2/3 times.

Thanks in advance for your support.

BR,

Marco

 

[Nicola Baldo]

I am no OLSR expert at all, but I guess that OLSR is mistakenly detecting that a link goes down, and I guess this might happen because e.g. of missed hello packets or something similar. Now the question is why this happens... for example I wonder if OLSR control packets end up in the same wifi queue of data packet, and hence might be discarded by a buffer overflow. I seem to recall that ns-2 had an explicit priority queue mechanism for this purpose. No idea how ns-3 handle this... maybe some routing expert could shed some light.

Nicola

[Marco Mezzavilla]

The OLSR control packets are enqueued in the same wifi queue of data packet, but the buffer is never overflowing.

1) If any of you, routing experts, have a suggestion, please contact me.

otherwise

2) Does any of you know if there is a simple way to freeze the routing tables initially generated with OLSR until the end of the simulation?

Regards,

Marco

--
You received this message because you are subscribed to the Google Groups "ns-3-users" group.

To view this discussion on the web visit https://groups.google.com/d/msg/ns-3-users/-/GHsS6_jM50wJ.

To post to this group, send email to ns-3-...@googlegroups.com.
To unsubscribe from this group, send email to ns-3-users+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ns-3-users?hl=en.

--
Marco Mezzavilla
Ph.D. Student - SIGNET Group
Department of Information Engineering (DEI)
University of Padova - Italy

[Konstantinos]

On Tuesday, 22 May 2012 10:42:20 UTC+1, Marco Mezzavilla wrote:

The OLSR control packets are enqueued in the same wifi queue of data packet, but the buffer is never overflowing.

1) If any of you, routing experts, have a suggestion, please contact me.

I am not an expert on OLSR, but I would ask you to test the RTS/CTS mechanism. Because there might be the case that there are collisions on the HELLO and since they are broadcast messages, you don't get an ACK (NACK). In addition, since you are using TCP connections, and there are packets in both directions, you might have collisions on these packets with the HELLOs.
 
See from Wireshark if the HELLO messages at that time are received properly.

otherwise

2) Does any of you know if there is a simple way to freeze the routing tables initially generated with OLSR until the end of the simulation?

You can try to manipulate the HELLO interval time. You need some time for convergence until the tables are set, after that I guess you can set it larger.
 

Regards,
Konstantinos

Regards,

Marco

To unsubscribe from this group, send email to ns-3-users+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/ns-3-users?hl=en.

[Marco Mezzavilla]

Hi Kostantinos, all,

thanks for the support. 

I tried to focus on the analysis of HELLO+TC messages, and it looks like it is all working properly, no losses nor collisions.

I would kindly ask some routing (OLSR) experts to give a look to this discussion. 

In few words, I can't understand why at a certain time a node loses some routing info for few seconds.

I tried to log OLSR procedures, but I do not see any strange behavior (find attached, starting from approximately 40seconds, referring to the previous example). 

Thanks

To view this discussion on the web visit https://groups.google.com/d/msg/ns-3-users/-/aZ_9Xna7NvsJ.

To post to this group, send email to ns-3-...@googlegroups.com.

To unsubscribe from this group, send email to ns-3-users+...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/ns-3-users?hl=en.

[Lalith Suresh]

Hi Marco,

On Thu, May 24, 2012 at 2:42 AM, Marco Mezzavilla <mezzavil...@gmail.com> wrote:

Hi Kostantinos, all,

thanks for the support. 

I tried to focus on the analysis of HELLO+TC messages, and it looks like it is all working properly, no losses nor collisions.

I would kindly ask some routing (OLSR) experts to give a look to this discussion. 

In few words, I can't understand why at a certain time a node loses some routing info for few seconds.

I tried to log OLSR procedures, but I do not see any strange behavior (find attached, starting from approximately 40seconds, referring to the previous example). 

Can you please attach the simulation script? And which version of ns-3 are you using?

--
Lalith Suresh

www.lalith.in

[Marco Mezzavilla]

Hi Lalith,

please find attached the simulation script.

I am using an ns-3-dev version updated three weeks ago

 (cloned from http://code.nsnam.org/ns-3-dev)

./waf --run 'flow_monitoring 106' 

may return the same situation described in this thread.

Otherwise, in order to detect the time of the anomaly for checking the routing tables, log the tcp-socket-base, and search for 'ReTxTimeout Expired at time '.

Thank you very much.

Best,

Marco

[Lalith Suresh]

On Thu, May 24, 2012 at 6:15 PM, Marco Mezzavilla
<mezzavil...@gmail.com> wrote:
> Hi Lalith,
>
> please find attached the simulation script.
> I am using an ns-3-dev version updated three weeks ago
>  (cloned from http://code.nsnam.org/ns-3-dev)
>
> ./waf --run 'flow_monitoring 106'
> may return the same situation described in this thread.
>
> Otherwise, in order to detect the time of the anomaly for checking the
> routing tables, log the tcp-socket-base, and search for 'ReTxTimeout Expired
> at time '.
>
> Thank you very much.
>

Thanks. I'll look at it over the weekend.

[Marco Mezzavilla]

Thank you Lalith, 

if you need any clarification I'll be online most of the time.

Regards,

Marco

[Srikant MANAS KALA]

Hi Marco/Lalith,

I am experiencing a similar problem in my implementation of a multi-hop wireless mesh network. The OLSR routings go haywire during the simulation.
Please share your solution to the problem with me.

Thanks.

[Tommaso Pecorella]

The solution was (back at the time) basically to:

1) describe the problem exactly.

2) upgrade to the laters ns-3 release

3) debug the issue

4) more things, some of them involving bloody rituals with a rooster and a pentagram.

I heard that Marco is now more concerned with the succubus he summoned, which fixed his code, but stole his body and soul in return.

As a consequence, I seriously doubt that he'll reply to you

Moreover, the succubus didn't care to update the fix for the newest ns-3 release. Hence, the fix is nowadays lost in time, space and in a computer protected by a hell of a firewall (literally).

I seriously fear that you'll have to start all over again, but I'd strongly suggest to use a stronger summoning ritual spell in order to avoid the troubles Marco faced.

Cheers,

T.

[Manas]

Thanks Tommasso. That was quite an answer !!

[Tommaso Pecorella]

You're welcome. However, I think it's good to give a translation for the ones that didn't get the hints.

The thread Manas replied to is dating back to 2012 (4 years ago). In the meantime ns-3 and OLSR had a number of bug fixes and improvements, and it's unclear from the old thread if the issue fix was incorporated in ns-3 or not. Checking it is a pain, as one should re-build an example with the new ns-3 APIs (some did change), and the bug could be still there, just hidden in a different place.

The second issue in Manas request was that "OLSR routings go haywire" is describing the overall effect, but it's not describing enough the issue to say anything (other than a poor joke). We know about some OLSR bugs (they're in bugzilla) but... it's hard to match a "OLSR routings go haywire".

Cheers,

T.

[Manas Kala]

Well, the issue with the OLSR routing  table I faced (and still am ) was precisely the same as elucidated in the initial problem description of this post. Hence I replied to this specific post instead of starting a new thread.

I hope this remedies the ambiguity  in my statement.

--
You received this message because you are subscribed to a topic in the Google Groups "ns-3-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ns-3-users/-5StoPQZ1pU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ns-3-users+...@googlegroups.com.

To post to this group, send email to ns-3-...@googlegroups.com.

Visit this group at http://groups.google.com/group/ns-3-users.
For more options, visit https://groups.google.com/d/optout.

--
Regards and Goodwill
Srikant Manas Kala

[Tommaso Pecorella]

Well, in this case the reply to the thread is justified (even if it's very old). However you could have said that the problem is the very same :P

Anyway, a lot of things have changed from 2 years ago. If you can send your script, it will ease the analysis. By the way (just to be sure)... I hope you're using a very recent ns-3 (greater or equal to 3.19). Otherwise the very first suggestion is... upgrade.

Cheers,

T.

[Marco Mezzavilla]

Dear Manas,

back in 2012 I spoke with both ns-3 and OLSR devs to try to shade some light on such issue; apparently, the behavior is just correct.

The reason why the communication goes down should be related to lost TC packets which break the IP routing tables.  

Regards,

Dr. Marco Mezzavilla

Postdoctoral Research Fellow at CATT - NYU Poly, Brooklyn, NY, USA

Chief Research Officer and Co-Founder at Snapback, Rome, Italy

mobile +1 347 593 1161

email mezza...@nyu.edu m.mezz...@snapback.io

skype misciua 

linkedin mmemzzavilla 

[Manas Kala]

Hi Marco.

Thanks for that input. I will investigate the reason for the packet loss then.

cheers.

[Maciej]

Hi Manas,

Did you manage to investigate the problem and find solution? I'm facing the same problem.

--

email mezza...@nyu.edu m.mezza...@snapback.io

skype misciua 

linkedin mmemzzavilla 

--
You received this message because you are subscribed to a topic in the Google Groups "ns-3-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ns-3-users/-5StoPQZ1pU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ns-3-users+...@googlegroups.com.
To post to this group, send email to ns-3-...@googlegroups.com.
Visit this group at http://groups.google.com/group/ns-3-users.
For more options, visit https://groups.google.com/d/optout.

[Manas Kala]

Hi Maciej,

I was able to recreate the tables and could see missing routing information as illustrated in Marco's original post. But beyond that I was unable to pursue the problem. I have noticed that with 802.11n this problem is less frequent, so you may want to try that.

--

email mezza...@nyu.edu m.mezz...@snapback.io

skype misciua 

linkedin mmemzzavilla 

--
You received this message because you are subscribed to a topic in the Google Groups "ns-3-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ns-3-users/-5StoPQZ1pU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ns-3-users+...@googlegroups.com.
To post to this group, send email to ns-3-...@googlegroups.com.
Visit this group at http://groups.google.com/group/ns-3-users.
For more options, visit https://groups.google.com/d/optout.

--
Regards and Goodwill
Srikant Manas Kala

--

You received this message because you are subscribed to a topic in the Google Groups "ns-3-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ns-3-users/-5StoPQZ1pU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ns-3-users+...@googlegroups.com.
To post to this group, send email to ns-3-...@googlegroups.com.
Visit this group at http://groups.google.com/group/ns-3-users.
For more options, visit https://groups.google.com/d/optout.

--

Regards and Goodwill
Srikant Manas Kala

Phone : 9985177631

Google Scholar Profile : https://goo.gl/wt30A7

[Tommaso Pecorella]

Hi all,

the problem seems to be correlated with packet losses. As we said, it happens (the losses). OLSR is able to recover from the apparent link failure, but there is a noticeable route hiccup.

Sadly, we can't do much about it, other than noting that OLSR isn't robust with respect to this kind of losses.

It could be also a problem of the implementation, in particular with respect to the timers and their values (i.e., I'd expect that to remove a route it would be necessary to have a number of missing packets, a quite uncommon case).

Unfortunately I have no time to investigate further, but I'd start by checking if the timers are set according to the standard.

If you have a specific bug or you notice a specific bad behaviour, we'll be happy to fix it.

Cheers,

T.

--

email mezza...@nyu.edu m.mezzavilla@snapback.io

skype misciua 

linkedin mmemzzavilla 

--
You received this message because you are subscribed to a topic in the Google Groups "ns-3-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ns-3-users/-5StoPQZ1pU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ns-3-users+...@googlegroups.com.
To post to this group, send email to ns-3-...@googlegroups.com.
Visit this group at http://groups.google.com/group/ns-3-users.
For more options, visit https://groups.google.com/d/optout.

--
Regards and Goodwill
Srikant Manas Kala

--
You received this message because you are subscribed to a topic in the Google Groups "ns-3-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ns-3-users/-5StoPQZ1pU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ns-3-users+...@googlegroups.com.
To post to this group, send email to ns-3-...@googlegroups.com.
Visit this group at http://groups.google.com/group/ns-3-users.
For more options, visit https://groups.google.com/d/optout.