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

From: Panos Trakadas <[email-masked]>
Date: Fri, 29 Jun 2012 18:43:22 +0100 (BST)

Well, IMO it depends on the specific user requirements set by the root node. 
It could be a nice idea to investigate the metrics (and techniques like hysteresis or composition) that would commonly be used in each one of the application areas that RPL is targeting (more as a proposition/guideline for the developers). 
To be honest, we have already started reading the respective RFCs and the AMI draft to figure out the appropriate metrics per application domain in order to include them in the next version of metrics-composition draft.
Panos

On 29 Jun 2012, at 19:21, Omprakash Gnawali <[email-masked]> wrote:

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

- om_p

On Mon, Jun 11, 2012 at 1:27 PM, Don Sturek <[email-masked]> wrote:
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

On 6/7/12 4: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:

On Jun 6, 2012, at 10:43 AM 6/6/12, Philip Levis wrote:

Responses inline.

On Jun 4, 2012, at 9:31 AM, Ralph Droms 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.

Regards,
Brian

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

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

---

From: Omprakash Gnawali <[email-masked]>
Date: Fri, 29 Jun 2012 10:54:05 -0700

Sorry, I should have been clearer. I was asking if we have a consensus
that it is the combination of:

1. metric in the DIO, and
2. OCP

that will tell us which metric+OF we have decided to use.

Most thought that this is the case but there were some with the
opinion that it might be clearer to use  separate OCP for each
metric,OF combination.

It is clear that we will benefit by explicitly stating how to tell
what metric+OF is used in the network. Unless there is any objection,
I will will proceed with the explanation that metric selection is
indicated by the presence of the metric in the container and OF
selection by OCP. For example, MRHOF(ETX) will use OF for MRHOF and
ETX will be in the metric container.

There was a separate discussion on allocating some OCP for
proprietary/private OFs that people might want to have but that is a
separate discussion.

- om_p

---

From: Mukul Goyal <[email-masked]>
Date: Fri, 29 Jun 2012 14:00:12 -0500 (CDT)

I agree except that, for MRHOF, absence of a metric container means that ETX is the metric in use.

Thanks
Mukul

----- Original Message -----
From: "Omprakash Gnawali" <[email-masked]>
To: "Panos Trakadas" <[email-masked]>
Cc: "Stiemerling Martin" <[email-masked]>, "Brian Haberman" <[email-masked]>, "roll" <[email-masked]>, "Michael Richardson" <[email-masked]>
Sent: Friday, June 29, 2012 12:54:05 PM
Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec

- om_p

---

From: Omprakash Gnawali <[email-masked]>
Date: Fri, 29 Jun 2012 12:05:38 -0700

> I agree except that, for MRHOF, absence of a metric container means that ETX is the metric in use.

Agree. Thanks for the reminder.

- om_p

---

From: Ralph Droms <[email-masked]>
Date: Fri, 29 Jun 2012 16:13:14 -0400

> Agree. Thanks for the reminder.

OK ... that's not the design decision I would have made, but a design decision is not an issue to hold a Discuss on.

A corollary of this design decision is that there can be at most one (in the case of ETX as the metric, zero) metric in the container.  The draft will need some editing to be consistent about that constraint.

- Ralph