[Olsr-dev] Additional Metrics for Link Quality

Benny Baumann (spam-protected)
Sun May 15 13:20:53 CEST 2011


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?

Benny Baumann

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 479 bytes
Desc: OpenPGP digital signature
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20110515/31a88476/attachment.sig>

More information about the Olsr-dev mailing list