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

[Ben West]

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?



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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-users/attachments/20150603/605b3bfd/attachment.html>