Subject: [Roll] metric ordering according to draft-ietf-roll-routing-metrics-08

From: Omprakash Gnawali <[email-masked]>
Date: Fri, 9 Jul 2010 16:17:08 -0700

"8.
...
   When the DAG Metric Container contains several aggregated metrics,
   they are to be used as tie-brakers in the order that they appear in
   the DAG Metric Container.  A node propagating a DAG Metric Container
   MUST keep the order of metric objects unchanged.

   An example of such use of multiple aggregated metrics is the
   following: Hop-Count as the primary criterion, LQL as the secondary
   criterion and Fanout Ratio as the ultimate tie-braker.  In such a
   case, the Hop-Count, LQL and Fanout Ratio metric objects need to
   appear in that order in the DAG Metric Container.

..."

Is the semantics behind the ordering intentional?

A packet could be forwarded from a node that prefers to use one set of
objective to a node that prefers to use a different objective. For
example, from a low power energy scavenging sensor to a powered node.
Not allowing the nodes to change the order allows a node to dictate
the relative importance of this metric to rest of the network without
regard to their preference.

If we had already considered that scenario and determined to be not
important, it might be worth making the last sentence in the following
paragraph stronger - are there other cases besides those mentioned in
8 and 3.2?

"2.
...
   Note that the Routing Metric/Constraint objects defined in this
   document can appear in any order in the DAG Metric Container.
   However, for some of them, the order is significant (as described in
   Section 8 and Section 3.2, for example).
"

- om_p

---

From: <[email-masked]>
Date: Tue, 13 Jul 2010 15:38:21 +0200

Hello Omprakash,

Thanks for your time reading the draft and commenting.

Yes, the semantic behind ordering is intentional. Some priority mechanism was needed and we proposed to use order of appearance in the packet as the semantic. We welcome comments on that use, especially if this is improper practice in the IP world.

Regarding nodes making their own decisions on objective, that's a different issue. I don't see that a node by itself should have the right to prefer one objective versus another one. It is my understanding that the RPL instance dictates what the objective is, and the nodes that join that instance have to adhere to it or become leaf nodes. Am I mistaken here?

So far, to my knowledge, there is no case in the -08 draft, other than the ones listed in 8 and 3.2, where order matters.
We have strong langage with MUSTs in these paragraphs, the text "the order is significant" you quote is just a forewarning early in the draft.

Thanks again, and comments welcome from all.
Best,

Dominique

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Omprakash Gnawali
Envoyé : samedi 10 juillet 2010 01:17
À : ROLL WG
Objet : [Roll] metric ordering according todraft-ietf-roll-routing-metrics-08

"8.
...

..."

A packet could be forwarded from a node that prefers to use one set of objective to a node that prefers to use a different objective. For example, from a low power energy scavenging sensor to a powered node.
Not allowing the nodes to change the order allows a node to dictate the relative importance of this metric to rest of the network without regard to their preference.

If we had already considered that scenario and determined to be not important, it might be worth making the last sentence in the following paragraph stronger - are there other cases besides those mentioned in
8 and 3.2?

"2.
...

- om_p
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: Omprakash Gnawali <[email-masked]>
Date: Mon, 19 Jul 2010 07:04:47 -0700

The ordering results in something other than OF deciding how to
compute paths. As a result, in some cases OFs will perform path
selection, and in some other cases, metric ordering will. This could
be confusing.

- om_p

---

From: Mukul Goyal <[email-masked]>
Date: Mon, 19 Jul 2010 11:32:51 -0500 (CDT)

I agree. I think that the metric container should simply be a set of metrics/constraints objects. The order of appearance of these objects inside the metric container should not have any inherent significance other than to identify the object. The objective function should assign any semantic significance to the order of objects inside the metric container.

Thanks
Mukul 

----- Original Message -----
From: "Omprakash Gnawali" <[email-masked]>
To: "dominique barthel" <[email-masked]>
Cc: [email-masked]
Sent: Monday, July 19, 2010 9:04:47 AM
Subject: Re: [Roll] metric ordering according todraft-ietf-roll-routing-metrics-08

- om_p

On Tue, Jul 13, 2010 at 6:38 AM, <[email-masked]>
wrote:
> Yes, the semantic behind ordering is intentional. Some priority
> mechanism was needed and we proposed to use order of appearance in the
> packet as the semantic. We welcome comments on that use, especially if
> this is improper practice in the IP world.
>
> Regarding nodes making their own decisions on objective, that's a
> different issue. I don't see that a node by itself should have the
> right to prefer one objective versus another one. It is my
> understanding that the RPL instance dictates what the objective is,
> and the nodes that join that instance have to adhere to it or become
> leaf nodes. Am I mistaken here?
>
> So far, to my knowledge, there is no case in the -08 draft, other than
> the ones listed in 8 and 3.2, where order matters.
> We have strong langage with MUSTs in these paragraphs, the text "the
> order is significant" you quote is just a forewarning early in the
> draft.
>
> ...   When the DAG Metric Container contains several aggregated
> metrics,   they are to be used as tie-brakers in the order that they
> appear in
> ...   Note that the Routing Metric/Constraint objects defined in this
> _______________________________________________ Roll mailing list
> [email-masked]
_______________________________________________ Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: JP Vasseur <[email-masked]>
Date: Tue, 20 Jul 2010 17:49:34 +0200

Hi,

On Jul 13, 2010, at 3:38 PM, <[email-masked]> <[email-masked] 

> mechanism was needed and we proposed to use order of appearance in  
> the packet as the semantic. We welcome comments on that use,  
> especially if this is improper practice in the IP world.
>

It is not improper. Still WG feed-back on this issue is welcome ?

Further, comments on Section 8 are really welcome:

8.  Metric usage

    This section describes how metrics carried in the DAG Metric
    Container shall be used.

    When the DAG Metric Container contains a single aggregated metric
    (scalar value), the order relation to select the best path is
    implicitely derived from the metric type.  For example, lower is
    better for Hop Count, Link Latency, ETX and Fanout Ratio.  For Node
    Energy or Throughput, higher is better.

    An exemple of using such a single aggregated metric is optimizing
    routing for node energy.  The Node Energy metric (E-E field) is
    aggregated along pathes with an explicit min function (A field), and
    the best path is selected through an implied Max function because  
the
    metric is Energy.

    The use of compound metrics, such as a polynomial function of
    individual metric values, will be described in a future revision of
    this document.

    The use of recorded metrics will be described in a future revision  
of
    this document.

> leaf nodes. Am I mistaken here?

You are correct. This is specified in the RPL spec.

>
> So far, to my knowledge, there is no case in the -08 draft, other  
> than the ones listed in 8 and 3.2, where order matters.
> A packet could be forwarded from a node that prefers to use one set  
> of objective to a node that prefers to use a different objective.  
> For example, from a low power energy scavenging sensor to a powered  
> node.
> the relative importance of this metric to rest of the network  
> without regard to their preference.
>
> important, it might be worth making the last sentence in the  
> following paragraph stronger - are there other cases besides those  
> mentioned in
> 8 and 3.2?
>
> "2.
> ...