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

[Omprakash Gnawali <[e-mail]>]

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