[Olsr-dev] Additional Metrics for Link Quality

[Markus Kittenberger]

hmm olsrd (stable branch) has a metric plugin interface,..
(but currently there are not much plugins around,..)

and olsrd has the lqmult factor to tune linkquality a bit,..

olsrd "0.7.0" will have olsrv2 packet format, allwoing to add custom fields
for really complex or multiple metrics aswell,..

Markus

On Sun, May 15, 2011 at 1:20 PM, Benny Baumann <(spam-protected)> wrote:

> Hi,
>
> when building a larger network which is (partly) interconnected by
> infrastructure abroad routing the traffic inside the network gets more
> complicated than when you only have a flat structure of ad-hoc access
> points meshing a local network.
>
> Now let's assume you have the following situation:
>
> 1. 3 local networks A, B, C each consisting of roughtly 50-100 nodes.
> 2. An infrastructure network D consisting of 5-10 nodes which
> interconnects through VPN/Tinc. Due to the nature of the VPN all routes
> inside the VPN are seen with ETX 1 (between all nodes)
> 3. One of the nodes in the networks A, B and C (each) has a VPN
> connection to D
>
> Given this basic network layout routing traffic is kinda straight
> forward as if you want to go from one of the local networks to another
> one since taking the inter-connect network D is the only route to go.
>
> Let us further assume, you built some new access points that
> interconnect A, B and C directly (direct wireless link). Given this was
> a wireless link you'd probably be much better than taking a DSL or cable
> line from A to D to B (D being around the globe). Instead the new
> wireless link would be much better. Unfortunately in regards to the
> hop-count D might be the shorter path, but latency-wise D might be just
> the most horrible choice you could do (e.g. UMTS or satelite uplink).
>
> Now as I understood the workings of OLSR there's the nice feature called
> ETX, which calculates link quality and estimates which way our packet
> would get to its destination the best.. Though if you have a VPN which
> interconnects different networks this ETX metric is rendered worthless
> as most VPN links should appear as ETX 1 (and practically always do)
> while the better direct link might have an ETX of let's say 1.5 (due to
> lots of angry birds crossing the way).
>
> When having a look at latency it's basically identical: The longer a
> packet needs to transmit the worse is the link quality for the user
> (e.g. for real-time applications). But OLSR doesn't take this into
> consideration. Not to mention band-width control and load-balancing
> (which is out of scope for now as this can be achieved with means other
> than OLSR).
>
> So now for the actual question: Is it possible (in OLSR 0.6 or later) to
> influence the Link Quality for a node through a plugin? E.g. make OLSR
> use Latency*LQ as the weight for a link, instead of plain 1/LQ?
>
> Are there means to introduce such additional metrics in a portable way?
> I.e. without rehacking the packet parser or introducing lots of new
> packets that would have to be flooded (separately) into the network? How
> much work would it be to implement such a mechanism?
>
> Regards,
> Benny Baumann
>
>
> --
> Olsr-dev mailing list
> (spam-protected)
> http://lists.olsr.org/mailman/listinfo/olsr-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20110515/cef592f1/attachment.html>