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

Omprakash Gnawali <gnawali@cs.uh.edu> Fri, 29 June 2012 16:22 UTC

Return-Path: <gnawali@cs.uh.edu>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07E6B21F877A for <roll@ietfa.amsl.com>; Fri, 29 Jun 2012 09:22:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.377
X-Spam-Level:
X-Spam-Status: No, score=-5.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7W-KJi4CwQIN for <roll@ietfa.amsl.com>; Fri, 29 Jun 2012 09:22:04 -0700 (PDT)
Received: from dijkstra.cs.uh.edu (dijkstra.cs.uh.edu [129.7.240.12]) by ietfa.amsl.com (Postfix) with ESMTP id BFEE521F86A5 for <roll@ietf.org>; Fri, 29 Jun 2012 09:22:03 -0700 (PDT)
Received: from localhost (dijkstra.cs.uh.edu [127.0.0.1]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id 3606D23CAB5 for <roll@ietf.org>; Fri, 29 Jun 2012 11:22:00 -0500 (CDT)
X-Virus-Scanned: amavisd-new at cs.uh.edu
Received: from dijkstra.cs.uh.edu ([127.0.0.1]) by localhost (dijkstra.cs.uh.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id siPefawbJYt0 for <roll@ietf.org>; Fri, 29 Jun 2012 11:21:55 -0500 (CDT)
Received: from it.cs.uh.edu (www2.cs.uh.edu [129.7.240.6]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id D8C2B23CA8F for <roll@ietf.org>; Fri, 29 Jun 2012 11:21:55 -0500 (CDT)
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by it.cs.uh.edu (Postfix) with ESMTP id 1060F2A280C0 for <roll@ietf.org>; Fri, 29 Jun 2012 11:21:07 -0500 (CDT)
Received: by dacx6 with SMTP id x6so4760342dac.31 for <roll@ietf.org>; Fri, 29 Jun 2012 09:21:58 -0700 (PDT)
Received: by 10.68.193.195 with SMTP id hq3mr7853704pbc.30.1340986917952; Fri, 29 Jun 2012 09:21:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.66.9.202 with HTTP; Fri, 29 Jun 2012 09:21:36 -0700 (PDT)
In-Reply-To: <CBFBA265.16E67%d.sturek@att.net>
References: <4FD137A4.3080801@innovationslab.net> <CBFBA265.16E67%d.sturek@att.net>
From: Omprakash Gnawali <gnawali@cs.uh.edu>
Date: Fri, 29 Jun 2012 09:21:36 -0700
Message-ID: <CAErDfUQZQ7ONZf0Q30USHtyvX-O6NMmC-CWCaRNxFU+538=vrw@mail.gmail.com>
To: Don Sturek <d.sturek@att.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Brian Haberman <brian@innovationslab.net>, roll <roll@ietf.org>, Stiemerling Martin <mstiemerling@googlemail.com>, Michael Richardson <mcr@sandelman.ca>
Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jun 2012 16:22:05 -0000

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
>
>