[Olsr-users] OLSR configuration for mobility.

[Dan O'Keeffe]

Hey Henning,
Thanks for your reply.


On 25/08/15 19:16, Henning Rogge wrote:
> On Tue, Aug 25, 2015 at 7:35 PM, Dan O'Keeffe <(spam-protected)> wrote:
>> Hello,
>> I have a few questions regarding the best version of OLSRd to use in a
>> mobile scenario, and also whether there are any best practices for
>> configuring OLSRd for mobility.
>>
>> I'm currently using OLSRv1 0.6.3 (from the ppa at from ppa at
>> https://launchpad.net/~guardianproject/+archive/ubuntu/commotion). My
>> olsrd.conf is included at the end of this email.
> 
> First advise... if you want to keep using olsrd (v1), upgrade to the
> most recent version.
> 
>> 1) Is OLSRv2 stable and if so is it now recommended to use OLSRv2 over
>> OLSRv1? Is the feature set of OLSRv2 strictly better than that of OLSRv1
>> (I'm only interested in features related to routing in a standalone MANET)?
> 
> Yes, I think its stable enough...


OK, I'll upgrade, thanks.


> 
> OLSRv2 includes the link speed into its metrics, OLSRv1 does not.


By link speed do you mean something like ETT? Do you have a
reference/link describing how OLSRv2 incorporates link speed, and the
benefits over just using ETX?


> 
>> 2) Do OLSRv2 and/or versions of OLSRv1 > 0.6.3 offer any potential
>> performance improvements relevant to a mobile scenario?
> 
> See above.
> 
>> I'm thinking in
>> particular of a properly tested implementation of optimized flooding of
>> topology control/MPR selection messages (this forum post seems to
>> indicate OLSRv1 0.6.x is configured to flood messages by default:
>> http://olsr-users.olsr.narkive.com/pmZC1pta/doubts-about-willingness-mpr-selection-and-routing
>> ). Any other major (routing related) bugfixes in OLSRv2 or OLSRv1 >
>> 0.6.3 would also be of interest.
> 
> I would advise NOT using MPR flooding... the current MPR algorithms
> are pure greedy algorithm without a memory, I don't think they are a
> good idea for mobile mesh networks.
> 
>> 3) I'm doing some emulation experiments with a distributed application
>> in a MANET on top of the CORE/EMANE wireless network emulator. For my
>> experiments I use the OLSR version above as the routing protocol. I'm
>> having problems with OLSR performance where I see long periods with
>> effectively 0 bitrate between two nodes communicating over a TCP socket.
>> I suspect it is because the MANET routing is taking a long time to
>> converge after routes change, since my network is dense enough that
>> partitions shouldn't be that much of an issue. I made some changes to
>> the default 0.6.3 conf to reduce the validity times of various control
>> messages (HelloValidityTime 600.0 -> 60.0, TcValidityTime 300.0 -> 30.0,
>> MidValidityTime 300.0 -> 30.0). This seemed to make the routing more
>> responsive, but is this discourage for any reason? Are there any similar
>> configuration tips that I should be aware of to help cope with mobility?
> 
> The most common change would be to reduce the Hello/TC intervals...
> validity time could also be reduced, but the interval is more
> important.


OK, thanks. Out of interest, does OLSRd (or a plugin) by any chance
report any statistics about how stable the network is, i.e. what
proportion of the time it converged?


> 
> Oh, with CORE/EMANE the link-speed detection of Olsrd2 will not work
> because there is no Wifi-card to query.


OK. When you say it won't work, will it fall back to something like ETX,
or will OLSRv2 just not work at all in emulation?


> 
> 
> Oh, and please have a look at the default configuration file provided
> with the latest Olsrd... and only put values into your file that are
> not the default.


Sure. Thanks again.