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

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 <gnawali@cs.uh.edu> 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 <d.sturek@att.net> 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" <brian@innovationslab.net> wrote:

On 6/7/12 6:12 PM, Omprakash Gnawali wrote:
On Thu, Jun 7, 2012 at 4:49 PM, Pascal Thubert (pthubert)
<pthubert@cisco.com>  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
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll