Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec

From: Michael Richardson <[email-masked]>
Date: Mon, 04 Jun 2012 10:33:57 -0400

>>>>> "Mukul" == Mukul Goyal <[email-masked]> writes:
    Mukul> Hi Michael

    Mukul> This would be my response to the questions Ralph asked.

Thanks for this message.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works 
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/

---

From: Ralph Droms <[email-masked]>
Date: Mon, 4 Jun 2012 12:31:34 -0400

On May 26, 2012, at 1:26 AM 5/26/12, Mukul Goyal wrote:

> Hi Michael
> 
> This would be my response to the questions Ralph asked.
> 
> Thanks
> Mukul

Mukul - thanks for responding to my questions...

> [Ralph]
> 1.  Why is one objective function defined for several potential
> metrics?  The details of MRHOF seem to preclude the establishment of
> several RPL instances in an LLN, each of which uses MRHOF with a
> different selected metric.
> 
> [Mukul]
> It is certainly possible to establish multiple RPL Instances in an LLN with MRHOF (or any other OF) as the OF. These RPL Instances may or may not use different routing metrics. An RPL Instance is associated with one particular OF as per RFC 6550. The OF converts the aggregated routing metric values to a rank value. Whether a particular OF could work with a particular metric depends on the OF. E.g. MRHOF specification says that MRHOF only works with additive metrics. So, the choice of routing metrics to be used in a particular DODAG (identified by the DODAGID) inside a particular RPL Instance may depend on the particular OF being used but, in general, the choice of OF and the choice of routing metrics are separate/independent issues.

My question here is why a single objective function "MRHOF" is defined to use several different metrics.  My understanding is that any specific RPL instance will use one metric as its "selected metric" for MRHOF.  Another way to organize the objective functions would be to define a different OF number for each metric, binding the OF number to the selected metric.

> [Ralph]
> 2. How are the nodes in the RPL instance informed about the selected
> metric?  My understanding of RPL is that only the objective function
> is included in the DIO received as an advertisement for a particular
> RPL instance, which means a node can't know the selected metric for
> that RPL instance and can't meaningfully decide among multiple RPL
> instances all using MRHOF as the objective function.
> 
> As a followup to (1), if there were a way to encode the selected
> metric for a RPL instance in the DAO, a node would be able to select
> which RPL instance to use for a particular type of traffic.
> 
> [Mukul]
> The root of a DODAG includes the selected metric objects in the Metric Container Option(s) inside its DIO. The nodes that join this DODAG include the same metric objects in their DIOs and so on. Thats how the nodes come to know which routing metrics are in use in a particular DODAG in a particular RPL Instance. 

As I wrote above, my understanding is that a particular RPL instance that specifies MRHOF will use one metric as the selected metric across the entire RPL instance.  Is it the case that a node includes only the metric object for the selected metric in a DIO (or no metric object in the case of ETX as the selected metric)?  Does a receiving node infer the selected metric for the RPL instance from the existence of a single metric in the DIO or does a node need to be explicitly provisioned to know the selected metric for each RPL instance?  Are these details specified in draft-ietf-roll-minrank-hysteresis-of-10?

Or, am I confused about the binding between a DIO and a RPL instance?

> [Ralph]
> 
> 3. Based on (1) and (2), would configuration and selection issues be
> ameliorated if the five candidate selected metrics were each assigned
> a separate objective function?  Use of a separate OF code point for
> each of the five possible selected metrics would allow multiple RPL
> instances.
> 
> [Mukul]
> Multiple RPL instances with same OF are already allowed. The whole idea behind OF is to separate the rank selection logic from the routing metrics.

OK, but if multiple RPL instances use MRHOF, there is no way for a node to determine which metric is the selected metric for the various RPL instances.

> [Ralph]
> 4. Related to the above, I don't see anything in section 6 about
> managing the selected metric.  Don't all of the nodes that join a RPL
> instance using MRHOF have to be configured to use the same selected
> metric?
> 
> [Mukul]
> Yes. As mentioned above, the root of a DODAG selects which routing metrics would be used and includes these metric objects inside the Metric Container inside the DIO. A node can join this DAG only if it supports the routin metrics being used.

You refer to "routing metrics".  Isn't it the case that a specific RPL instance uses only one metric as the selected metric across all nodes in the RPL instance?

Are the nodes configured in the "installer provisioning" (section 6.1) or do nodes infer the selected metric from the metric included in the DIO?

> [Ralph]
> 5. In section 3.2.2:
> 
>   a
>   node MAY use a different objective function to select which of these
>   neighbors should be considered to have the lowest cost.
> 
> seems to contradict the statement in the Introduction that "all nodes
> in a network use a common OF."  Should "different objective function"
> be replaced with "some other selection criteria?"
> 
> [Mukul]
> That makes sense to me.

OK.

> [Ralph]
> 6. In section 5, are the RECOMMENDED values appropriate for all
> selected metrics or just for ETX?  Are there any references that might
> be cited that would give background on the working group experience
> with ETX and the development of the recommended values?
> 
> 7. In section 6.1, why not "MUST support the DODAG Configuration
> option?"  I don't see any RFC 2119 requirements on the implementation
> of the DODAG Configuration option (which would appera to be an
> oversight), but I don't understand how a node can operate in a RPL
> instance without, for example, being able to determine the Objective
> Function used by that instance.
> 
> [Mukul]
> That particular statement indeed sounds redundant to me. I think every RPL implementation MUST understand the DODAG Configuration Option.

OK.

- Ralph

---

From: Mukul Goyal <[email-masked]>
Date: Tue, 5 Jun 2012 03:29:46 -0500 (CDT)

Hi Ralph

******************************************************************************
[Ralph1]
> different selected metric.
[Mukul1]
> It is certainly possible to establish multiple RPL Instances in an LLN with MRHOF (or any other OF) as the OF. These RPL Instances may or may not use different routing metrics. An RPL Instance is a…

[Ralph2]

[Mukul2]
An OF is a function and hence is supposed to be independent of the variables (the metrics) on which it operates. If we were to link an OF with a particular metric, we would end up with a very large number of OFs.

****************************************************************************************************

[Ralph1]
> which RPL instance to use for a particular type of traffic.
[Mukul1]
> The root of a DODAG includes the selected metric objects in the Metric Container Option(s) inside its DIO. The nodes that join this DODAG include the same metric objects in their DIOs and so on. Th…

[Ralph2]
As I wrote above, my understanding is that a particular RPL instance that specifies MRHOF will use one metric as the selected metric across the entire RPL instance.  Is it the case that a node includes only the metric object for the selected metric in a DIO (or no metric object in the case of ETX as the selected metric)?

[Mukul2]
Yes. Only the "metric object" corresponding to the selected metric should be included in the metric container. What purpose would any other "metric object" serve? The metric container can still contain other "constraint" objects. If the MRHOF draft does not say so, it should. If the metric container were to contain multiple "metric objects", a node implementing MRHOF would not know which metric is the "selected" one.

[Ralph2]
  Does a receiving node infer the selected metric for the RPL instance from the existence of a single metric in the DIO

[Mukul2]
Yes that is how it should work in my opinion.

[Ralph2]
 or does a node need to be explicitly provisioned to know the selected metric for each RPL instance? 

[Mukul2]
Requiring explicit provisioning of the selected metric does not make sense when the alternative is so easy - just require the meric container to carry one metric object, the one for the selected metric.

[Ralph2]
 Are these details specified in draft-ietf-roll-minrank-hysteresis-of-10?

[Mukul2]
No. They should be.

[Ralph2]

[Mukul2]
I think you are not confused. MRHOF spec should be clear in this respect.

***********************************************************************************
[Ralph1]
> each of the five possible selected metrics would allow multiple RPL
[Mukul1]
> Multiple RPL instances with same OF are already allowed. The whole idea behind OF is to separate the rank selection logic from the routing metrics.

[Ralph2]

[Mukul2]
I think the selected metric can easily be identified by requiring it to be the only metric in the metric container. Linking an OF to a particular metric does not seem like a good idea because it would mean exponential increase in the number of OFs as more "rank calculation rules" and more metrics come in use.

*********************************************************************************

[Ralph1]
> instance using MRHOF have to be configured to use the same selected

[Mukul1]
> Yes. As mentioned above, the root of a DODAG selects which routing metrics would be used and includes these metric objects inside the Metric Container inside the DIO. A node can join this DAG only…

[Ralph2]
You refer to "routing metrics".  Isn't it the case that a specific RPL instance uses only one metric as the selected metric across all nodes in the RPL instance? Are the nodes configured in the "installer provisioning" (section 6.1) or do nodes infer the selected metric from the metric included in the DIO?

[Mukul2]
When I said "routing metrics", I was referring to how, in general, the routing metrics in use in a particular instance are identified. You are right, MRHOF works with one selected metric and not multiple metrics. You are also right that Section 6 should say some thing about managing the selected metric. Even if the selected metric is to be identified as the only metric in the metric container, the Manageability section should still say some thing to the effect that all nodes that are supposed to join a particular instance using a particular selected metric must have inbuilt support for that metric.  

***************************************************************************************************

Thanks
Mukul

OK.

OK.

- Ralph

---

From: Philip Levis <[email-masked]>
Date: Wed, 6 Jun 2012 07:43:04 -0700

Responses inline.

> My question here is why a single objective function "MRHOF" is defined to use several different metrics.  My understanding is that any specific RPL instance will use one metric as its "selected met…

This was a design decision made early in RPL. There were two options: OFs are metric-specific, or OFs can be general with respect to metrics. The design team concluded the second approach was better, as the former would lead to a possibly huge number of OFs that would be hard to manage.

Phil

---

From: Ralph Droms <[email-masked]>
Date: Thu, 7 Jun 2012 15:48:24 -0400

> This was a design decision made early in RPL. There were two options: OFs are metric-specific, or OFs can be general with respect to metrics. The design team concluded the second approach was bette…

Now that a real OF has actually been designed and specified, perhaps this would be a good time to reconfirm that design decision.

Given that MRHOF is a pretty general objective function, and works over 5 (or perhaps 3) metrics, 16 bits would seem to provide plenty of code points for metric-specific OFs.

A bigger issue, I think, is expressing the semantics or behavior of an OF in its OCP.  I read section 18.6 of RFC 6550 to indicate that a node will use information including the OF (as indicated by the OCP) to compare against the node's policy for joining a DODAG.  As an aside, is there a reason why a node would choose to join a specific DODAG within a RPL Instance and on what basis would it make that choice?  Anyway, wouldn't the selected metric  used by MRHOF in a particular RPL Instance be a useful parameter for the policy rules?  For example, I can imagine a node preferring to join a RPL Instance providing minimal latency over one providing best ETX.  If the OCP is metric-specific, that selected metric will be immediately available for the policy rules.

- Ralph

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 7 Jun 2012 21:49:08 +0000

[Pascal] I agree with Ralph here. I fail to be convinced that there will an explosion of OCPs if we fail to factorize the metrics. But I see how the device implementation can be simplified if the OCP says it all. Also, we do not want to force a device that implements MRHOF to have to implement all metrics in the I-D. Conversely, say we extend MrHof to other metrics with further work, wouldn't it become OCP 2 anyway? I wouldn't mind blocking OCP 1..9 for current and future MrHof metric variations.

Cheers,
 
- Ralph

> Phil

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

---

From: Omprakash Gnawali <[email-masked]>
Date: Thu, 7 Jun 2012 18:24:18 -0500

On Thu, Jun 7, 2012 at 6:22 PM, Brian Haberman <[email-masked]> wrote:
> On 6/7/12 6:12 PM, Omprakash Gnawali wrote:
>>
>> On Thu, Jun 7, 2012 at 4:49 PM, Pascal Thubert (pthubert)
>> <[email-masked]>  wrote:
>>>
>>>
>>>>> My question here is why a single objective function "MRHOF" is
>>>>> defined to use several different metrics.  My understanding is
>>>>> that any specific RPL instance will use one metric as its
>>>>> "selected metric" for MRHOF.  Another way to organize the
>>>>> objective functions would be to define a different OF number
>>>>> for each metric, binding the OF number to the selected metric.
>>>>
>>>>
>>>> This was a design decision made early in RPL. There were two
>>>> options: OFs are metric-specific, or OFs can be general with
>>>> respect to metrics. The design team concluded the second approach
>>>> was better, as the former would lead to a possibly huge number of
>>>> OFs that would be hard to manage.
>>>
>>>
>>> Now that a real OF has actually been designed and specified,
>>> perhaps this would be a good time to reconfirm that design
>>> decision.
>>>
>>> Given that MRHOF is a pretty general objective function, and works
>>> over 5 (or perhaps 3) metrics, 16 bits would seem to provide plenty
>>> of code points for metric-specific OFs.
>>>
>>> A bigger issue, I think, is expressing the semantics or behavior of
>>> an OF in its OCP.  I read section 18.6 of RFC 6550 to indicate that
>>> a node will use information including the OF (as indicated by the
>>> OCP) to compare against the node's policy for joining a DODAG.  As
>>> an aside, is there a reason why a node would choose to join a
>>> specific DODAG within a RPL Instance and on what basis would it
>>> make that choice?  Anyway, wouldn't the selected metric  used by
>>> MRHOF in a particular RPL Instance be a useful parameter for the
>>> policy rules?  For example, I can imagine a node preferring to join
>>> a RPL Instance providing minimal latency over one providing best
>>> ETX.  If the OCP is metric-specific, that selected metric will be
>>> immediately available for the policy rules.
>>>
>>>
>>> [Pascal] I agree with Ralph here. I fail to be convinced that there
>>> will an explosion of OCPs if we fail to factorize the metrics. But
>>> I see how the device implementation can be simplified if the OCP
>>> says it all. Also, we do not want to force a device that implements
>>> MRHOF to have to implement all metrics in the I-D. Conversely, say
>>> we extend MrHof to other metrics with further work, wouldn't it
>>> become OCP 2 anyway? I wouldn't mind blocking OCP 1..9 for current
>>> and future MrHof metric variations.
>>
>>
>> Just one clarification - MRHOF does not require the devices to
>> support all the metrics listed in the I-D. All it says is it must
>> implement at least one metric.
>
>
> Excuse the pedantic question, but won't there be an issue if half the
> devices in an RPL instance implement one metric and the other half implement
> a different metric?  This would seem to force users to select all their
> devices based on which metric they want to use.

If metrics are not the same, the nodes can work as leaf. The I-D says
nodes SHOULD support ETX so there is a hope that the networks might
support ETX.

- om_p

---

From: Philip Levis <[email-masked]>
Date: Thu, 7 Jun 2012 21:02:23 -0700

> [Pascal] I agree with Ralph here. I fail to be convinced that there will an explosion of OCPs if we fail to factorize the metrics. But I see how the device implementation can be simplified if the O…

I agree that this is a good question to ask. I disagree that now is an appropriate time to answer it definitively; we currently have only one OCP. We made a concrete and deliberate design decision. I'd argue we should stick with it to at least see it play out a bit more. E.g., once MRHOF is actually a proposed standard and we have significant experience using it. It's so critical in systems design to not waffle on design decisions, otherwise you end up with a contradictory and messy system. You do want to correct, but not lightly and only when the benefits of the change significantly outweigh the costs. I'm not at all sure this is the case here.

Phil

---

From: Mukul Goyal <[email-masked]>
Date: Thu, 7 Jun 2012 23:09:35 -0500 (CDT)

I agree with Philip.

Thanks
Mukul

----- Original Message -----
From: "Philip Levis" <[email-masked]>
To: "Pascal Thubert (pthubert)" <[email-masked]>
Cc: "Haberman Brian" <[email-masked]>, "roll" <[email-masked]>, "Stiemerling Martin" <[email-masked]>, "Michael Richardson" <[email-masked]>
Sent: Thursday, June 7, 2012 11:02:23 PM
Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec

Phil

---

From: Ralph Droms <[email-masked]>
Date: Fri, 8 Jun 2012 06:39:46 -0400

> I agree that this is a good question to ask. I disagree that now is an appropriate time to answer it definitively; we currently have only one OCP. We made a concrete and deliberate design decision.…

What are the costs of the change?

Without encoding the metric in the OCP, how does a node know what metric is in use in an advertised RPL Instance.  How does a node choose which RPL Instance(s) to join without learning which metrics are in use?

- Ralph

---

From: Mukul Goyal <[email-masked]>
Date: Fri, 8 Jun 2012 06:16:35 -0500 (CDT)

>Without encoding the metric in the OCP, how does a node know what metric is in use in an advertised RPL Instance.

The metrics inside the metric container inside the DIOs it receives from its candidate parents. Only the DAG root needs to be configured regarding merics in use. Other nodes would know the metrics in use by looking inside the metric container of the DIOs they receive.

Mukul

>  How does a node choose which RPL Instance(s) to join without learning which metrics are in use?

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Fri, 8 Jun 2012 07:18:54 -0400

> The metrics inside the metric container inside the DIOs it receives from its candidate parents. Only the DAG root needs to be configured regarding merics in use. Other nodes would know the metrics…

Is the receiving node supposed to infer that the selected metric for a RPL Instance using MRHOF is the one metric container included in the DIO (or, in the case of ETX, there is no metric container)?

- Ralph

---

From: Mukul Goyal <[email-masked]>
Date: Fri, 8 Jun 2012 06:22:37 -0500 (CDT)

>Is the receiving node supposed to infer that the selected metric for a RPL Instance using MRHOF is the one metric container included in the DIO (or, in the case of ETX, there is no metric container)?

In my opinion, yes.

Mukul 

----- Original Message -----
From: "Ralph Droms" <[email-masked]>
To: "Mukul Goyal" <[email-masked]>
Cc: "Ralph Droms" <[email-masked]>, "Stiemerling Martin" <[email-masked]>, "Michael Richardson" <[email-masked]>, "roll" <[email-masked]>, "Haberman Brian" <[email-masked]>, "Philip Levis" <[email-masked]>
Sent: Friday, June 8, 2012 6:18:54 AM
Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Fri, 8 Jun 2012 07:24:38 -0400

>> Is the receiving node supposed to infer that the selected metric for a RPL Instance using MRHOF is the one metric container included in the DIO (or, in the case of ETX, there is no metric containe…

Where is that behavior explicitly described in the relevant specifications?

- Ralph

---

From: Mukul Goyal <[email-masked]>
Date: Fri, 8 Jun 2012 06:27:07 -0500 (CDT)

>Where is that behavior explicitly described in the relevant specifications?

It is not. It should be.

Mukul

---

From: Ralph Droms <[email-masked]>
Date: Fri, 8 Jun 2012 08:05:09 -0400

>> Where is that behavior explicitly described in the relevant specifications?

OK, having *some* way for a node to determine the selected metric for MRHOF in an advertised RPL Instance tells me how MRHOF can provide the necessary information for the policy decision in section 18.6 of RFC 6550.

I would encourage some more discussion about metric-encoded OCPs.  Seems to me the metric is of at least as much importance (more important, in my opinion) in choosing a RPL Instance as the way in which the DODAG is constructed based on that metric (i.e., the computation part of the OF).  If I were trying to get a packet from a node to the LBR, I'd be much more interested in the ETX or the latency than whether the path is computed with hysteresis.

- Ralph

---

From: Michael Richardson <[email-masked]>
Date: Fri, 08 Jun 2012 10:11:30 -0400

>>>>> "Philip" == Philip Levis <[email-masked]> writes:
    Philip> I agree that this is a good question to ask. I disagree that
    Philip> now is an appropriate time to answer it definitively; we
    Philip> currently have only one OCP. We made a concrete and
    Philip> deliberate design decision. I'd argue we should stick with
    Philip> it to at least see it play out a bit more. E.g., once MRHOF
    Philip> is actually a proposed standard and we have significant
    Philip> experience using it. It's so critical in systems design to

I think what you are saying is that splitting MRHOF into multiple OCPs
in the future would not be so difficult a thing to do.

There is a coding simplicity in what we have now, and we should be
conscious of the constraints of our devices.

---

From: Ralph Droms <[email-masked]>
Date: Fri, 8 Jun 2012 12:31:19 -0400

> in the future would not be so difficult a thing to do.

Yeah, but once the code is deployed, nobody is going to make changes.

> conscious of the constraints of our devices.

I'll push back a little - inferring the metric from the received DIO is certainly no simpler than learning the metric directly from the OCP...

- Ralph

---

From: Philip Levis <[email-masked]>
Date: Fri, 8 Jun 2012 10:28:18 -0700

> I'll push back a little - inferring the metric from the received DIO is certainly no simpler than learning the metric directly from the OCP...

Ralph,

Let's separate two issues:

1) OCPs should not have metric flexibility
2) There should be multiple MRHOFs, for different metric combinations

We decided against 1) in the design phase due to conversations JP had with some RPL users. The argument was that there are situations where you might want to dynamically shift the operation of the network. E.g., you have an OF that optimizes for two metrics, primary and secondary. You have a RPL network designed for monitoring physical security and reporting potential intrusions. In the monitoring phase, energy is the primary metric, with latency second. In the reporting/alert phase, latency is the primary metric and energy is the secondary metric. 

If we decide 1), then it's not possible to do the above approach unless you include two separate OFs. Furthermore, let's say you want to just use energy? Or just use latency? You lose flexibility. The point is that this is a one way street. If you allow metric flexibility, then you can define OFs that only support one metric. If you do not allow metric flexibility, then you cannot define OFs that are flexible with respect to metrics.

With respect to 2), I'd love to hear from the folks implementing MRHOF whether they think this is a good idea. Are there cases where the flexibility is useful? ETX is stated as the least common denominator through a SHOULD. My worry right now is that we're pursuing a not-unreasonable-but-mostly-hypothetical concern. As I said before, asking the question is great, but we don't want to reverse years of agreed-upon-reasoning and tradeoff decisions without careful thought.

Phil

Phil

---

From: Michael Richardson <[email-masked]>
Date: Fri, 08 Jun 2012 15:14:01 -0400

>>>>> "Philip" == Philip Levis <[email-masked]> writes:
    Philip> We decided against 1) in the design phase due to
    Philip> conversations JP had with some RPL users. The argument was
    Philip> that there are situations where you might want to
    Philip> dynamically shift the operation of the network. E.g., you
    Philip> have an OF that optimizes for two metrics, primary and
    Philip> secondary. You have a RPL network designed for monitoring
    Philip> physical security and reporting potential intrusions. In the
    Philip> monitoring phase, energy is the primary metric, with latency
    Philip> second. In the reporting/alert phase, latency is the primary
    Philip> metric and energy is the secondary metric.  

I agree with the scenario.

How would an (already deployed) node know which metric it is supposed to
start optimizing for?  I believe that intermediate nodes need to make
the same optimization as the node which has the event ("intrusion")
which it wishes to report.

(Maybe I'm wrong, cause my the parent selection code in my
implementation currently says, "return 1;")

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 8 Jun 2012 19:18:37 +0000

Hi Michael:

My understanding is that it is simpler to just check the OCP than first match the OCP in the config option and then go figure the metric in the metric option.
Not that it is a huge overhead but I fail to understand why you claim that the single OCP is simpler.
And no, I do not see that splitting in a future when implementations are already shipping will be easy; 
a mixed deployment would have to fall back to legacy from the root down, meaning that it will hardly ever evolve. 
LLN Devices that we install now some of the deployments (eg industrial) are expected last for 20+ years with minimum (no) intervention on them but maybe battery changes.

Cheers,

Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: vendredi 8 juin 2012 16:12
To: [email-masked]
Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec

I think what you are saying is that splitting MRHOF into multiple OCPs in the future would not be so difficult a thing to do.

There is a coding simplicity in what we have now, and we should be conscious of the constraints of our devices.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 8 Jun 2012 20:03:22 +0000

Hi Phil

[Pascal] If there is a well-defined logic in an OF that plays with coefficients to ponder latency and battery, then we have a single OCP that represents that logic. Overtime, the coefficients might evolve so that a battery-depleted devices gets less packets though. I'm perfectly fine with that. But note that from the start the OF supports both metrics, even if at a given point of time the coefficient can be 0 for one of those.

[Pascal] Agreed with the mostly hypothetical. Is anyone using another metric than ETX? But " years of agreed-upon-reasoning and tradeoff decisions" might be slightly exaggerated...

Cheers,

Pascal

Phil

---

From: Ralph Droms <[email-masked]>
Date: Fri, 8 Jun 2012 16:08:12 -0400

> If we decide 1), then it's not possible to do the above approach unless you include two separate OFs. Furthermore, let's say you want to just use energy? Or just use latency? You lose flexibility.…

I have to say this is the first I've heard, based on the specs I've reviewed to date, of an OF that would dynamically change its behavior. 

Why wouldn't RPL Instances - one optimized for low latency and one optimized for low energy - be an acceptable and simpler solution?  How would the metric be changed atomically?  How would nodes be notified that the metric had changed?

Metric flexibility seems like a hypothetical that needs more thought and additional mechanism in RPL to become real.  In any event, I'll clarify that I wasn't thinking that every the OCP for every OF encode the metric for that OF.  It seemed, in the case of MRHOF, that a separate OCP for each metric might solve the problem of indicating the selected metric to a receiving node.

> With respect to 2), I'd love to hear from the folks implementing MRHOF whether they think this is a good idea. Are there cases where the flexibility is useful? ETX is stated as the least common den…

We may not be talking about the same issue, as I don't quite understand your question about flexibility.  Can you say more about it?

Do we agree that the selected metric for a RPL Instance using MRHOF needs to be indicated to the receiving node for the node to make a policy decision about whether to join the RPL Instance?

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Fri, 8 Jun 2012 16:09:58 -0400

> [Pascal] If there is a well-defined logic in an OF that plays with coefficients to ponder latency and battery, then we have a single OCP that represents that logic. Overtime, the coefficients might…

Agreed - not every OF has to encode its single metric in its OCP.  But for some OFs, like MRHOF, it might make sense.

> [Pascal] Agreed with the mostly hypothetical. Is anyone using another metric than ETX? But " years of agreed-upon-reasoning and tradeoff decisions" might be slightly exaggerated...

I'm still confused about what is hypothetical.  MRHOF is defined for 5 possible metrics (or maybe 3).  Is it the case that only ETX is really going to be used?

- Ralph

---

From: Philip Levis <[email-masked]>
Date: Fri, 8 Jun 2012 15:35:28 -0700

> [Pascal] I agree with Ralph here. I fail to be convinced that there will an explosion of OCPs if we fail to factorize the metrics. But I see how the device implementation can be simplified if the O…

Well, here was your argument for it:

Begin forwarded message:

> From: "Pascal Thubert (pthubert)" <[email-masked]>
> Subject: RE: rank and metric in DIOs
> Date: November 6, 2009 12:52:54 AM PST
> To: "Jonathan Hui" <[email-masked]>, "Richard Kelsey" <[email-masked]>
> Cc: <[email-masked]>
> 
> Hi Jonathan:
> 
> I do not think we need to enforce anything. The gear box protects the
> future. I think we must leave the core spec abstract on that. And since
> the burden is on the OCP anyway, what's the point?
> 
> OTOH, we can design an OCP / metric where the metric has the properties
> that is proposed here. In that case, the OCP should be simpler. OCP zero
> is a bit like that if you look at it :) Maybe our disagreement is only
> what is in the base spec (the generic thing) and what goes in a specific
> instantiation (the OCP).
> 
> I can wholeheartedly accept Richard's way of start simple and solid, and
> then build over it if that's how more people can catch up with our work
> for both understanding and implementation. As a next step for an OCP>0,
> it is certainly a good thing to do. I'd support that, even more gladly
> if we base it on ETX. 
> 
> Personally I think that this proposal yields limitations that will soon
> appear inacceptable for a number of use cases where you have more
> metrics, not necessarily incremental, fast varying, and logic to wrap
> that up. So we MUST NOT make it generic. Some of those metrics you need
> to propagate, but you do not want to change the rank and restart
> trickle.
> 
> I listed the properties of the rank several times already. Its stability
> (long time constant is only one of those properties). 
> 
> A list (probably incomplete) of the differences:
> 
> - its type: it is a scalar
> - its function: it is a relative coordinate, not a cost or a distance to
> root.
> - its granularity: it is coarse grained to enable siblings
> - its range with a short infinite
> - its properties: rank is strictly monotonic, and increments from parent
> rank + OCP stuff, not like the metrics themselves increment or
> propagate. How would you play with throughput or jitter?
> - universal and very abstract: we can always default to OCP0. I have
> uses cases where I could actually do that successfully, like cars in a
> parking lot.
> 
> I think that the OCP job to turn its knowledge of the requirements, the
> environment and the ranks of parents into a rank cannot be generalized.
> Leaving that operation out of RPL base spec is actually making it
> simpler.
> 
> I'd be glad to add some words in RPL base spec on those rank properties
> though...

Phil

---

From: Philip Levis <[email-masked]>
Date: Fri, 8 Jun 2012 15:42:51 -0700

Response inline.

> [Pascal] Agreed with the mostly hypothetical. Is anyone using another metric than ETX? But " years of agreed-upon-reasoning and tradeoff decisions" might be slightly exaggerated...

What I meant here is that the rest of the protocol has been designed assuming this is the case. There are other things we might have done were there a strong binding between the two. For example, if an OCP defines the metric container and there isn't flexibility, there would be little need for a general metric container object: an OF could define it. 

I'll repeat what I said before: we should ask this question, but should not answer it definitively now. Making a significant change right now based on concerns -- which haven't been voiced by any implementers -- seems like a dangerous road to tread. I mean, come on, let's evaluate the design and evolve it from practice, not from the sofa.

Phil

---

From: JP Vasseur <[email-masked]>
Date: Sat, 9 Jun 2012 10:21:37 +0200

[snip]

> Do we agree that the selected metric for a RPL Instance using MRHOF needs to be indicated to the receiving node for the node to make a policy decision about whether to join the RPL Instance?

JP> Absolutely !

Thanks.

JP.

---

From: Michael Richardson <[email-masked]>
Date: Sun, 10 Jun 2012 19:49:16 -0400

>>>>> "Pascal" == Pascal Thubert <(pthubert)" <[email-masked]>> writes:
    Pascal> My understanding is that it is simpler to just check the OCP
    Pascal> than first match the OCP in the config option and then go
    Pascal> figure the metric in the metric option. 

I don't understand.

    Pascal> Not that it is a huge overhead but I fail to understand why
    Pascal> you claim that the single OCP is simpler. 

I don't claim it, I'm trying to understand what you are saying.

    Pascal> And no, I do not see that splitting in a future when
    Pascal> implementations are already shipping will be easy;  

okay.

    Pascal> a mixed deployment would have to fall back to legacy from
    Pascal> the root down, meaning that it will hardly ever evolve.  
    Pascal> LLN Devices that we install now some of the deployments (eg
    Pascal> industrial) are expected last for 20+ years with minimum
    Pascal> (no) intervention on them but maybe battery changes. 

I don't expect any deployed device to change.
They won't change for a new OF or OCP, etc. 
What would happen is that new deployments might use it.

---

From: Brian Haberman <[email-masked]>
Date: Thu, 07 Jun 2012 19:22:12 -0400

Excuse the pedantic question, but won't there be an issue if half the 
devices in an RPL instance implement one metric and the other half 
implement a different metric?  This would seem to force users to select 
all their devices based on which metric they want to use.

Regards,
Brian

---

From: Panos Trakadas <[email-masked]>
Date: Tue, 12 Jun 2012 08:36:51 +0100 (BST)

Dear all,
Following the exchange of emails during the last days regarding MRHOF and in general the on-going discussion on metrics composition and multiple instances support, we would like to inform you that we uploaded a powerful simulation platform of RPL, enhanced with several metrics (and about 30 OFs), composition approaches and support of multiple instances at the google code repository (http://code.google.com/p/rpl-jsim-platform/downloads/list).
This work has started within FP7 project VITRO, as there was no open source code for running simulations of RPL.
The source code is, in general, in line with RPL specs (we tried to reflect some changes, as development started on version 13 of RPL RFC).

For convenience, we provide an installation guide for j-sim and rpl source code as well as detailed explanation for several examples included in the source code (ROLL_examples folder in the downloaded zip file).
Please notice that this simulation platform introduces a trust-aware routing metric, called Packets Forwarding Indication (PFI) and supports the composition of multiple metrics (ETX, HC, RSSI, RE) in accordance to the draft-zahariadis-roll-metrics-composition document.
Please do not hesitate to contact us for further information or clarifications.
We also proceed with implementing enhanced functionality on real motes. Please see relevant videos on youtube: 

http://www.youtube.com/watch?v=jscSdMbDRA0&feature=plcp
http://www.youtube.com/watch?v=VzO_DyXz8vw&feature=plcp
http://www.youtube.com/watch?v=14ldt3-VVuw&feature=plcp
or visit VITRO project website (http://www.vitro-fp7.eu/).

Best Regards,
Panos Trakadas.

---

From: Don Sturek <[email-masked]>
Date: Mon, 11 Jun 2012 13:27:03 -0700

Hi Brian,

>From our experience implementing RPL and MrHOF, all devices in a RPL
instance MUST implement the same OF.

I think this is why there is so much discussion on the reflector on how to
convey the OF to the prospective joining devices.

Don

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 12 Jun 2012 13:56:13 -0700

Hi,

it's always good to have open-source implementations. Thank you!

On a quick glance, it seems that you define one objective function
code per OF+metric (i.e., for a single objective function multiple
variations per metric). Have I understood your code correctly in that
regards?

Best
Ulrich

On Tue, Jun 12, 2012 at 12:36 AM, Panos Trakadas <[email-masked]> wrote:
> Dear all,
> Following the exchange of emails during the last days regarding MRHOF and in
> general the on-going discussion on metrics composition and multiple
> instances support, we would like to inform you that we uploaded a powerful
> simulation platform of RPL, enhanced with several metrics (and about 30
> OFs), composition approaches and support of multiple instances at the google
> code repository (http://code.google.com/p/rpl-jsim-platform/downloads/list).
> The source code is, in general, in line with RPL specs (we tried to reflect
> some changes, as development started on version 13 of RPL RFC).
> For convenience, we provide an installation guide for j-sim and rpl source
> code as well as detailed explanation for several examples included in the
> source code (ROLL_examples folder in the downloaded zip file).
> Please notice that this simulation platform introduces a trust-aware routing
> metric, called Packets Forwarding Indication (PFI) and supports the
> composition of multiple metrics (ETX, HC, RSSI, RE) in accordance to the
> draft-zahariadis-roll-metrics-composition document.

---

From: Panos Trakadas <[email-masked]>
Date: Wed, 13 Jun 2012 06:19:52 +0100 (BST)

Hi Ulrich,
Yes. Our implementation defines 29 different ways to construct DODAGs, according to the application- or user-specific requirements. 

This is achieved through the selected Objective Code Point (OCPs), defined in RFC6550 as "an identifier that indicates
which Objective Function the DODAG uses". As an example, using OCP = 0, the DODAG will be built on Hop-Count metric, while using OCP = 1, the DODAG is based on ETX. As a more complex example, OCP = 15 defines an OF where HC is the dominant metric (highest precedence) and remaining energy is the second (tie-breaking) metric. Almost any combination of the supported metrics set (HC, ETX, RSSI, RE, PFI) defines an OCP and a respective OF.

The OCPs are mentioned in the tcl examples and defined in the jsim-1.3\src\drcl\inet\protocol\rpl\RPL_ObjFunctions.java.In that sense, each OCP defines a different OF that maximizes (or minimizes) the Rank value (depending on whether the metrics are maximizable or minimizable). 
BR,
Panos.

________________________________
 Απο: Ulrich Herberg <[email-masked]>
Προς: Panos Trakadas <[email-masked]> 
Κοιν.: roll <[email-masked]> 
Στάλθηκε: 11:56 μ.μ. Τρίτη, 12 Ιουνίου 2012
Θεμα: Re: [Roll] Enhanced RPL functionality on J-Sim platform
 
Hi,

Best
Ulrich

---

From: Omprakash Gnawali <[email-masked]>
Date: Fri, 29 Jun 2012 09:21:36 -0700

Do we have a resolution on this topic - how to select OF+metric to be used?

- om_p