Bug 2585

Summary:	OLSR model does not scale above 300 nodes
Product:	ns-3	Reporter:	peter eder-neuhauser <peter.eder-neuhauser>
Component:	olsr	Assignee:	Lalith Suresh <suresh.lalith>
Status:	NEEDINFO ---
Severity:	major	CC:	gjcarneiro, ns-bugs, tomh
Priority:	P3	Keywords:	bug
Version:	ns-3.26
Hardware:	PC
OS:	Linux

Description peter eder-neuhauser 2016-12-14 08:07:57 UTC

the OLSR model does not scale well due to increasing (probably squared) number of HELLO-messages per physical node, when more than 300 nodes are in one mesh. There are several broadcast messages (HELLOs) which can collide and hence not have an optimal path. The standard does not specify any flood control mechanism, and none is implemented in ns-3. You can only control the frequency of the broadcasts.

Comment 1 peter eder-neuhauser 2016-12-14 08:10:54 UTC

dear lalith suresh, please get back to me if you have a workaround or any idea how to decrease the size of the messages or properly increase the frequency of the hello-message cycles.

Comment 2 Tom Henderson 2016-12-14 11:12:29 UTC

What do you propose the model should do?

In general, protocols like OLSR do not scale indefinitely with the size of the broadcast (flooding) domain.  The typical solution is to partition the broadcast domains.

Comment 3 Lalith Suresh 2016-12-14 11:45:19 UTC

I don't see this as a bug. As Tom said, OLSR isn't meant to scale indefinitely.

If too many nodes are within each other's broadcast range, their messages will collide.

Keep in mind that ns-3's OSLR implementation does "jitter" packet transmissions to avoid collisions since the clocks are synchronized across nodes (see OLSR_MAXJITTER and JITTER macros in src/olsr/model/olsr-routing-protocol.cc). But it looks like that isn't helping your scenario either.

Comment 4 peter eder-neuhauser 2016-12-14 11:48:06 UTC

I understand that with increasing size of the broadcast domain comes more control traffic. 

Is it at all possible to either decrease the frequency at which this control traffic is generated? I was looking into the model settings on "HelloInterval" and "TCinterval" yet it does not do the trick.

Or is it possible to define nodes that are responsible for broadcasting, while others only passively listen?

Partitioning the broadcast domains would be my last resort.

Comment 5 Lalith Suresh 2016-12-14 11:55:05 UTC

(In reply to peter eder-neuhauser from comment #4)
> I understand that with increasing size of the broadcast domain comes more
> control traffic. 
> 
> Is it at all possible to either decrease the frequency at which this control
> traffic is generated? I was looking into the model settings on
> "HelloInterval" and "TCinterval" yet it does not do the trick.
> 

I would suggest increasing the Hello/TC intervals and playing with the JITTER macro that I mentioned above.

> Or is it possible to define nodes that are responsible for broadcasting,
> while others only passively listen?
> 

There are no turn-key mechanisms to do that in the code.

Comment 6 peter eder-neuhauser 2016-12-14 12:17:57 UTC

Thank you I will try that and get back to you.