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

Omprakash Gnawali <gnawali@cs.uh.edu> Thu, 07 June 2012 23:24 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 7439111E80E4 for <roll@ietfa.amsl.com>; Thu, 7 Jun 2012 16:24:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.717
X-Spam-Level:
X-Spam-Status: No, score=-5.717 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 OcYNL1wXVr2F for <roll@ietfa.amsl.com>; Thu, 7 Jun 2012 16:24:44 -0700 (PDT)
Received: from dijkstra.cs.uh.edu (dijkstra.cs.uh.edu [129.7.240.12]) by ietfa.amsl.com (Postfix) with ESMTP id BE2C811E8088 for <roll@ietf.org>; Thu, 7 Jun 2012 16:24:44 -0700 (PDT)
Received: from localhost (dijkstra.cs.uh.edu [127.0.0.1]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id A075423CAFE for <roll@ietf.org>; Thu, 7 Jun 2012 18:24:41 -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 2ngXknwu3SpL for <roll@ietf.org>; Thu, 7 Jun 2012 18:24:41 -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 4DF8C23CAFF for <roll@ietf.org>; Thu, 7 Jun 2012 18:24:38 -0500 (CDT)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by it.cs.uh.edu (Postfix) with ESMTP id 6A8402A280CF for <roll@ietf.org>; Thu, 7 Jun 2012 18:22:11 -0500 (CDT)
Received: by eaaq13 with SMTP id q13so675165eaa.31 for <roll@ietf.org>; Thu, 07 Jun 2012 16:24:39 -0700 (PDT)
Received: by 10.14.95.67 with SMTP id o43mr2192694eef.13.1339111478959; Thu, 07 Jun 2012 16:24:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.180.101.168 with HTTP; Thu, 7 Jun 2012 16:24:18 -0700 (PDT)
In-Reply-To: <4FD137A4.3080801@innovationslab.net>
References: <831338825.521366.1338009982543.JavaMail.root@mail17.pantherlink.uwm.edu> <8EFE80AF-3E7C-494E-8237-C63E6ECDAE7E@gmail.com> <53E28E3B-4C73-4BD3-BCFE-2C669FC3FA1D@cs.stanford.edu> <CAC8E858-8215-4BC8-98C6-962109324BED@gmail.com> <E045AECD98228444A58C61C200AE1BD806E78F8F@xmb-rcd-x01.cisco.com> <CAErDfUQu3SMMMTOAeorOP+tD6UhESPh0Xjiw-xq7hjgT12NM6Q@mail.gmail.com> <4FD137A4.3080801@innovationslab.net>
From: Omprakash Gnawali <gnawali@cs.uh.edu>
Date: Thu, 7 Jun 2012 18:24:18 -0500
Message-ID: <CAErDfURHaEQEMFr2crrODeTjbj_595y0nNjMJ4kZrOsd2YO5dg@mail.gmail.com>
To: Brian Haberman <brian@innovationslab.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: Stiemerling Martin <mstiemerling@googlemail.com>, Michael Richardson <mcr@sandelman.ca>, roll <roll@ietf.org>
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: Thu, 07 Jun 2012 23:24:45 -0000

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

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