[OLSR-users] Differing metrics for route decision

[Roar Bjørgum Rotvik]

Thomas Lopatic wrote:
> Hey Liam.
> 
> [...]
> 
>> How was the ETX metric implemented into the main olsr codebase?
> 
> Currently there isn't any clean plugin-like interface for metrics. The
> ETX implementation hooks into the code of olsrd at quite a lot of places
> which are dispersed all over the code.
> 
> [...]
> 
> Regarding other metrics or improvements of the existing metric we're
> always open for discussion. I am not a routing expert, though, I just
> implement what other, smarter people tell me to implement. :-)

I just wanted to tell you that I also thought about changing the 
metric/route calculation in OLSR, and looked at the code.

My idea was to start with the ETX code, but just replace the code where 
the calculation takes place to match my own calculation, but reuse much 
of the ETX infrastructure.

I worked on a project where each node had two radios, one long range and 
low bandwidth, second radio had short range and high bandwidth.
In this scenario each node will probably hear another over the long 
range radio, but if you want to transmit for instance video streaming 
over two hop, you would like to use two short range instead of one long 
range because of the bandwidth requirements.

In this case the metric would be interface "cost", where the long range 
radio/interface has a higher cost than the short range radio. But when 
number of hops on short radio reaches a certain limit (let say 2-3 
hops), then we would like to use one long range hop instead (for traffic 
suited for this bandwidth of course. Video cannot be sent over this 
radio anyway).

So I looked into changing ETX calculation from quality metric to cost 
metric, it seemed possible to do without to much trouble. But 
unfortunately I did not have time in the project to implement this.

But I saw that if olsrd had a plugin-like solution to the metric 
calculation, it would be a lot easier to implement and test new 
calculations and maybe come up with range of better metrics. The 
standard OLSR lowest-hop-count is clearly not the best solution 
everywhere :)

If I'm correct OLSRD today have three methods to calculate 
metric/routing: OLSR, ETX and Fisheye.
Would it be simpler to maintain (less code duplication and so on) if 
olsrd had a common generic framework for the metric/routing calculation 
and plugin-like support for the actual calculation? Just an idea..

NB: Sending this email to olsr-dev with CC to olsr-user, as I think 
olsr-dev is the most appropriate for this kind of discussions.

-- 
Roar Bjørgum Rotvik