[Olsr-dev] Link metrics

[scolfield]

Ok, I think the same that Minimum Delay is not so good metric to measure
link delay
because you need to overhead the environment with probe packets.
Moreover, I think such approach cause "damage" to layer-2 based
on CSMA/CA adding more delay, and consequently, data packets
are affected.

And I think the manner how was implemented in ns-2 is not good
in my opinion, because it change the OLSR packet header
and the number of neighbor in HELLO packet is limited
or fixed to 4 neighbors always (that's I remember,  if I not wrong).
Moreover, it hasn't any problem with float point in ns-2 environment
(without serialization), in other words, the clock time is "perfect"
in whole network. I think that problems will appear exactly in this point
in real environment, with clock.

Well, thank you very much for answers
and good work with OLSRv2. The modulated implementation
with plugins will help any research community to deploy new metric
easily.

On Mon, Jul 30, 2012 at 12:45 AM, Henning Rogge <(spam-protected)>wrote:

> 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."
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20120730/82f5deb5/attachment.html>