Subject: [Roll] The need for multiplicative metrics and other comments on draft-ietf-roll-routing-metrics-05

From: Mukul Goyal <[email-masked]>
Date: Sun, 28 Mar 2010 01:36:32 -0500 (CDT)

Here are some comments on draft-ietf-roll-routing-metrics-05. Not sure if people have already identified these issues.

1) I am concerned about the fact that the metrics draft does not currently allow a metric to be declared "multiplicative" in nature.

The natural way to aggregate the link-level reliabilities into a path-level reliability is by multiplication.

Quoating from section 4.3.1 ("Link Quality Level Reliability Metric") in the metrics draft:

"Aggregated LQL Value: when used an an additive metric (A=0x00), the
   aggregated LQL value reports the sum of all the LQL values for all
   links along the path.  When used to report a minimum (A=0x02), the
   field reports the minimum LQL value of all links along the path."

Aggregating the "Link Quality Levels" by adding them together does not make any sense. This allows two routes, with very different end-to-end reliabilities, to have same aggregated LQL values.

2) The beginning text in Section 4.3 (Link Reliability) identifies external and multipath interefence as the reasons for poor link reliability. I think that external interference should be described a little more. For CSMA based MAC layers, too much contention for channel access is also a major cause for high packet loss rates, which should be mentioned as well.

3) There are two typos in the draft:

1. At the beginning of section 4.3.1: 

"The Link Quality Level (LQL) object is used to quantify the link
   reliability using a discrete value, from 0 to 3 where 0 indicates
   that the link quality level is unknown and 1 reports the highest link
   quality level."

1 should be replaced by 3.

2. Towards the end of 4.3.2:

"The ETX object may be used as a constraint or a path metric.  For
   example, an Objective Function may indicate that the ETX must not be
   below some specified value."

Should be: ETX must not be more than some specified value.

Thanks
Mukul

---

From: Robert Cragie <[email-masked]>
Date: Sun, 28 Mar 2010 07:47:53 -0700

Hi Mukul,

Multiplicative metrics make sense if the metric is a probability. If the 
metric is on a logarithmic scale, the sum amounts to a product anyway so 
it may be sufficient to keep it as an additive metric. In the scale from 
1 to 3, perhaps it would be necessary to define what 2 represents, so 
maybe 4.3.1 needs to be clarified.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com <http://www.gridmerge.com/>

On 27/03/2010 11:36 PM, Mukul Goyal wrote:
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>
>

---

From: Yoav Ben-Yehezkel <[email-masked]>
Date: Sun, 28 Mar 2010 19:31:51 +0300

Hi,

Just a quick question, is 1 reports the highest or lowest link quality
level?

It seems contradicting in the text.

"

4.3.1.  The Link Quality Level Reliability Metric

   The Link Quality Level (LQL) object is used to quantify the link

   that the link quality level is unknown and *1 reports the highest link*

*   quality level.*  The mechanisms and algorithms used to compute the LQL

   is implementation specific and outside of the scope of this document.

"

Whereas in the following text it says:

"

   The format of the LQL Type 1 sub-object is as follows

     0 1 2 3 4 5 6 7

    +-+-+-+-+-+-+-+-+

    |Val| Counter   |

    +-+-+-+-+-+-+-+-+

    Figure 12: LQL Type 1 sub-Object format

*   Val: LQL value from 0 to 3 where 0 means undetermined and 1 indicates*

*   the lowest link quality.*

   Counter: number of links.

"

So – which is it?

Anyway, WRT to reliability and LQL - there’s a problem with long good paths
(in the following assume 1 indicates the good link). The multiplication of
any number of good links will remain 1, where in fact the reliability will
drop significantly after a few hops. Also the value 0 indicating unknown
will immediately cause the multiplication to be 0 – i.e. unknown (which
could make some sense, though in summation it should do no difference to the
aggregation). Could there be a problem with the definitions?

Just a nice trick - to get the same results as in option 1 (counting 1/2/3),
one can make a multiplication of primes (say 2, 3, 5), and aggregate (using
multiplication or summation of logs) the divisors of the aggregated value
would be the counters of 2,3,5 which maps to 1/2/3 counters, respectively. I
don’t think this is the intent though.

Thoughts?

Yoav

*From:* [email-masked] [mailto:[email-masked]] *On
Behalf Of *Robert
Cragie
*Sent:* Sunday, March 28, 2010 5:48 PM
*To:* [email-masked]
*Subject:* Re: [Roll] The need for multiplicative metrics and other comments
on draft-ietf-roll-routing-metrics-05

Hi Mukul,

Multiplicative metrics make sense if the metric is a probability. If the
metric is on a logarithmic scale, the sum amounts to a product anyway so it
may be sufficient to keep it as an additive metric. In the scale from 1 to
3, perhaps it would be necessary to define what 2 represents, so maybe 4.3.1
needs to be clarified.

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 (0) 1924 910888
http://www.gridmerge.com

Here are some comments on draft-ietf-roll-routing-metrics-05. Not sure
if people have already identified these issues.

1) I am concerned about the fact that the metrics draft does not
currently allow a metric to be declared "multiplicative" in nature.

The natural way to aggregate the link-level reliabilities into a
path-level reliability is by multiplication.

Quoating from section 4.3.1 ("Link Quality Level Reliability Metric")
in the metrics draft:

Aggregating the "Link Quality Levels" by adding them together does not
make any sense. This allows two routes, with very different end-to-end
reliabilities, to have same aggregated LQL values.

2) The beginning text in Section 4.3 (Link Reliability) identifies
external and multipath interefence as the reasons for poor link
reliability. I think that external interference should be described a
little more. For CSMA based MAC layers, too much contention for
channel access is also a major cause for high packet loss rates, which
should be mentioned as well.

   quality level."

Thanks

Mukul

Roll mailing list

[email-masked]

---

From: Henning Rogge <[email-masked]>
Date: Sun, 28 Mar 2010 18:58:34 +0200

Am Sonntag 28 März 2010 08:36:32 schrieb Mukul Goyal:
> Here are some comments on draft-ietf-roll-routing-metrics-05. Not sure if
> people have already identified these issues.
> 
> 1) I am concerned about the fact that the metrics draft does not currently
> allow a metric to be declared "multiplicative" in nature.
> 
You can transform any multiplicative metric into an additive one and the other 
way around by applying a logarithm or exponential function.

Henning Rogge

-- 
1) You can't win.
2) You can't break even.
3) You can't leave the game.
— The Laws of Thermodynamics, summarized