Re: [Roll] ETX metric

["Pascal Thubert (pthubert)" <pthubert at cisco.com>]

Hi Henning.

Good to hear from you :)

We also called that syndrome the 'Worst Path First'. I think the name
was introduced by Teco quite a long time ago.

The trick to make it work outside the Lab is to filter out any packet
that does not have metrics like RSSI above a quality threshold and
blacklist peers that show a poor history. Like a WIFI AP that does not
associate or drops association with nodes under a certain signal
strength.

RPL requires an abstract peer link evaluation though it does not say how
that is done and it has the hold down feature.

I got good results with an emulation of LMI's N392/N393 that computes a
loss ratio. But there must be a great many other strategies so that
least each hop is rated 'good enough' and the network is not stretched
too far. I'm unsure whether we should specify how that's done, since it
might be L2 dependent. And even if one can alleviate the WPF syndrome,
the end result is that paths cannot be compared for their end to end
metric thus are not optimized.
 
RPL is a bit more subtle than meet the eye from JP's summarized
description. It provides a default increment per hop (4), but the node
can play around that increment to reflect the quality of the link
(1..16). So we can advertise something that's a lot closer to the link's
quality and thus optimize something that's dependent on the objective.

OCP0 (the arch default) increments by 4 so it really relies on the link
evaluation. Maybe we could allow to play around the 4 value within the
1..16 range but then we cannot really specify how that is done since
that sort of thing is left to the metrics draft.

Cheers,

Pascal

>-----Original Message-----
>From: roll-bounces at ietf.org [mailto:roll-bounces at ietf.org] On Behalf Of
Henning Rogge
>Sent: mardi 13 octobre 2009 15:54
>To: JP Vasseur (jvasseur)
>Cc: roll at ietf.org
>Subject: Re: [Roll] ETX metric
>
>Am Dienstag 13 Oktober 2009 15:35:40 schrieb JP Vasseur:
>> > So the question about a metric for ROLL should not only be "what's
>> > the best metric for our networks" but "what metric is simple enough
>> > that everyone can implement it on any kind of hardware".
>>
>> I fully agree with your approach.
>>
>> Yes, what we have done so far (in the new revision to be posted) is
to
>> define one mandatory metric (hop count) and have all other ones
optional.
>> May be "hop count" is one the one that we will keep as mandatory but
>> the spirit is to have a set of metrics people can decide to use based
on the OF.
>
>OLSRv1 did the same way and it shaped the conclusion "OLSR is crap" or
"OLSR does not work" in huge parts of
>the industry. Hop count metrics can be called "use worst link" metrics
for wireless networks, because it tries
>to optimize for the LONGEST links possible, which will be (most likely)
worst links your network knows.
>
>With OLSR and 802.11 you can summarize it "Hopcount does not work in
real networks outside the lab". There are
>some special cases how you can improve hopcount, but most times you
will still get a poor performance and your
>protocol will be blamed.
>
>Unless 802.15.4 is totally different (I don't think so) I would
strongly suggest thinking about something
>better than hopcount for your mandatory metric. At least that's the
message I can tell from OLSR.
>
>Henning Rogge
>
>-- Those who cannot learn from history are doomed to repeat it.