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

[Omprakash Gnawali <[e-mail]>]

On Thu, Jun 7, 2012 at 6: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.

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