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

Brian Haberman <> Thu, 07 June 2012 23:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7A69E11E80EE for <>; Thu, 7 Jun 2012 16:22:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.499
X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PaZUnRtFC1Zn for <>; Thu, 7 Jun 2012 16:22:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D061E11E8088 for <>; Thu, 7 Jun 2012 16:22:14 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTP id ACEC3880C7; Thu, 7 Jun 2012 16:22:14 -0700 (PDT)
Received: from Littlejohn.local ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTP id B185614003A; Thu, 7 Jun 2012 16:22:13 -0700 (PDT)
Message-ID: <>
Date: Thu, 07 Jun 2012 19:22:12 -0400
From: Brian Haberman <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Omprakash Gnawali <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 11 Jun 2012 10:55:05 -0700
Cc: Stiemerling Martin <>, Michael Richardson <>, roll <>
Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Jun 2012 23:22:28 -0000

On 6/7/12 6:12 PM, Omprakash Gnawali wrote:
> On Thu, Jun 7, 2012 at 4:49 PM, Pascal Thubert (pthubert)
> <>  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.