[Olsr-users] How to make routes *very* sticky?

[Teco Boot]

> Op 3 jun. 2015, om 22:01 heeft Ben West <(spam-protected)> het volgende geschreven:
> 
> Thank you Teco and Henning for the responses.  I do fully agree overloading a multi-hop link is suboptimal.  I'm actually doing this for the purpose of stress testing, i.e. wilfully creating worst case conditions.
> 
> I did not enable any special queuing strategy or QoS on these nodes under test, besides whatever OpenWRT v14 decides to use with stock configuration.  I anticipated fq_codel tweaking to be doable as a later step (or in parallel).
> 
> The route flapping doesn't occur when these nodes don't use olsr just have static routes set, yet with the same traffic (over)load.  My interest in trying to deploy olsr in this mesh is to see if it could be useful in establishing backup routes through the redundant wifi links, in the event of a repeater node along the preferred multi-hop route going down.  (I.e. where just setting static routes manually would fail.)
> 
> Indeed, I wouldn't expect olsrd to flap routes disruptively under moderate traffic load.  However, the catch-22 I'm seeing is that the backup routes through the weaker links would be more likely to saturate (i.e. since their capacity is less), meaning the very conditions where I'd like to see olsr establish the backup routes are also those where it may start flapping routes disruptively.
> 
> Independent of queuing discipline (if any), what is the best way simply to make olsrd extremely unwilling to change routes?  I.e. where a particular link has to be extremely bad (or non-existent if the node goes down) where olsrd alters any routes?
> 

The hysteresis parameters are hard coded in the lq plugins (+/- 10%, disabled for perfect links). For an experiment, where you modify all nodes in the network, you could play tweaking.

Having unaffected LQ by user traffic would be the better approach. 

Maybe olsrd2 with DAT metric (lower layer data rate) does a better job. Although a loaded network would influence minstrel. @Henning: already experimental data, where DAT outperforms ETX on heavily loaded networks?

Teco


> 
> 
> On Wed, Jun 3, 2015 at 3:17 AM, Henning Rogge <(spam-protected)> wrote:
> On Wed, Jun 3, 2015 at 10:12 AM, Teco Boot <(spam-protected)> wrote:
> > Could you check your queuing strategy? The olsrd packets could get dropped
> > by Linux queue management, NIC driver or NIC hardware. There is some space
> > for improvement.
> >
> > ETX link measurement should not be influenced badly by user traffic. On the
> > other hand, high rate of olsrd packets in highest priority queue has bad
> > effects on real time traffic. Also because multicast is on low data rate.
> >
> > There is the olsrd TosValue parameter, you could mark olsrd packets with
> > "Network Control" (TosValue 192).
> 
> This is the default setting for current olsrd (and for olsrd2).
> 
> > No reason not having fq_codel in place. However, because lower layer queue
> > management dominates, it doesn't help that much.
> > Most difficult part is to manage queue strategy of NIC driver and hardware.
> > Broadcast packets might have its special handling. Check net/mac80211/wme.c
> > on is_multicast_ether_addr(ra).
> >
> > Having codel at driver level is a research topic. Dave Taht could inform you
> > on current status.
> 
> There is also the point that overloading a multihop wifi link is a bad idea.
> 
> Henning
> 
> 
> 
> -- 
> Ben West
> http://gowasabi.net
> (spam-protected)
> 314-246-9434