[Olsr-dev] Link metrics

Henning Rogge (spam-protected)
Mon Jul 30 05:45:53 CEST 2012

OLSRv2 defines no type of metric, it transports the metric as
directional integer values in a compressed format (~ 1 - 2^24). You
can implement any kind of metric you want with these values.

I plan to put the metric generation completely into plugins, which
will make it easy to deploy different kind of metrics.

I would also like to have both an ETX and ETT metric, which will be
compatible with each other (by allowing to set a fixed link speed for
the ETX) and use the same range of numbers.

Minimum delay is a bad metric in my opinion, because you cannot
measure it well, it depends a lot on the number of packets in the
outgoing queue.

But if you can measure it, it should be very easy to use it.


On Sun, Jul 29, 2012 at 5:55 PM, scolfield <(spam-protected)> wrote:
> Thank you for answers.
> It's truth that current OLSR version was prepared to use ETX
> in the past and some modification on link quality calculation will
> break the compatibility... and I'm bit curious about OLSRv2.
> I think that link quality metrics based on ETX, at the implementation
> level view, we "don't have much problems". I mean, in example,
> the metric ML calculation method is very similar to ETX, in other
> words, we can use the same HELLO and TC packets implemented
> currently to provide ML metric.
> I imagine that it is not possible to metrics based on link bandwidth
> calculation like MD or ETT, where they use packet-pair probe to
> measure the link quality.
> The future OLSR version 2 will be able to "add" these metrics?
> In other words, if the research community decide to implement
> a new metric that use packet-pair probing technique, OLSRv2
> will be prepared/modulated to add it? There is a preview
> when it will be released?
> And to finish, I would like know if you intend to provide
> MD (minimum delay) metric as a standard metric or
> as a optional metric (available to use).
> On Sun, Jul 29, 2012 at 6:34 PM, Henning Rogge <(spam-protected)>
> wrote:
>> Not completely right.
>> The main reason at the moment is that the packet encoding of Olsrd was
>> designed specifically for ETX in the past, so we have to break
>> compatibility for new metrics.
>> Thats why (at least from my side) we plan to introduce them with
>> OLSRv2 (which I am working on at the moment) where we have to break
>> compatibility anyway.
>> Breaking it twice in a row is bad.
>> Henning
>> On Sun, Jul 29, 2012 at 11:21 AM, ZioPRoTo (Saverio Proto)
>> <(spam-protected)> wrote:
>> > I think the main reason why we don't use them is that the core
>> > developers are all volunteers, and there is not enogh spare time to
>> > implement everything.
>> >
>> > ciao,
>> >
>> > Saverio
>> >
>> >
>> > 2012/7/29 scolfield <(spam-protected)>:
>> >> Hi everyone,
>> >>
>> >> Maybe ETX link metric is the most known technique used to calculate
>> >> or estimate link quality between to points. However, in the literature
>> >> we can see any kind of link quality metric has proposed, such as
>> >> ETT, ML, MD and other variation of ETX.
>> >>
>> >> Such metrics has proposed and tested at the simulation level like ns-2
>> >> and those works show us that such new metrics were better than ETX
>> >> in multimedia environments.
>> >>
>> >> So, I would like your opinions about these metrics. What do you think
>> >> about it? Why don't  use in the OLSR protocol?
>> >>
>> >> My best thanks,
>> >>
>> >> --
>> >> Olsr-dev mailing list
>> >> (spam-protected)
>> >> https://lists.olsr.org/mailman/listinfo/olsr-dev
>> >
>> > --
>> > Olsr-dev mailing list
>> > (spam-protected)
>> > https://lists.olsr.org/mailman/listinfo/olsr-dev
>> --
>> Steven Hawkings about cosmic inflation: "An increase of billions of
>> billions of percent in a tiny fraction of a second. Of course, that
>> was before the present government."

Steven Hawkings about cosmic inflation: "An increase of billions of
billions of percent in a tiny fraction of a second. Of course, that
was before the present government."

More information about the Olsr-dev mailing list