[Olsr-dev] Link metrics

[Henning Rogge]

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.

Henning

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."