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

Don Sturek <d.sturek@att.net> Tue, 12 June 2012 13:48 UTC

Return-Path: <d.sturek@att.net>
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 C2ED721F8562 for <roll@ietfa.amsl.com>; Tue, 12 Jun 2012 06:48:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.607
X-Spam-Level:
X-Spam-Status: No, score=-1.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992]
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 wgjTtAwoHcpx for <roll@ietfa.amsl.com>; Tue, 12 Jun 2012 06:48:03 -0700 (PDT)
Received: from nm4.bullet.mail.ac4.yahoo.com (nm4.bullet.mail.ac4.yahoo.com [98.139.52.201]) by ietfa.amsl.com (Postfix) with SMTP id 0B77921F8554 for <roll@ietf.org>; Tue, 12 Jun 2012 06:48:02 -0700 (PDT)
Received: from [98.139.52.195] by nm4.bullet.mail.ac4.yahoo.com with NNFMP; 12 Jun 2012 13:48:02 -0000
Received: from [68.142.200.227] by tm8.bullet.mail.ac4.yahoo.com with NNFMP; 12 Jun 2012 13:48:02 -0000
Received: from [66.94.237.119] by t8.bullet.mud.yahoo.com with NNFMP; 12 Jun 2012 13:48:02 -0000
Received: from [127.0.0.1] by omp1024.access.mail.mud.yahoo.com with NNFMP; 12 Jun 2012 13:48:02 -0000
X-Yahoo-Newman-Id: 393667.4161.bm@omp1024.access.mail.mud.yahoo.com
Received: (qmail 47014 invoked from network); 12 Jun 2012 13:48:02 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1339508882; bh=g2SmUFq68iu7+te0rzGznC735kdkuF+dEad1tPyqyXA=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=fGUPIFHbg4aIGcl0+3nevDHaMnu3XMROILaCTBHE0ccfnN8jgTCVDRVdyyrCf1S2XhDcbRsMgwYSEVA2yJcaAFPsl3uTB+0YCyIGd2a1a/9PVbh2BkAV8uf1gK5KOQXRWU2hF7nOnaqWQZrE0TjegHNuWhWFua8PQ6Sfk1CZZss=
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: 5uJ8SicVM1nVTW3FMh1yDQWX6GI6CASjExbMolB3ywqy_oM 2IFcXKCNgfAVUHy2S624jmboA2IUhBhyJOyy14QL.gPNahpIDWnzKci1DBwI XMcAAaL0UOLjUmsHdLeLw4aOirvTTvMGXgLR.Kl1Wvwd42MZohjakpxIhgXc 1uFyvOYnvQzYosoLjp65izyzkvz5hG.bNlabggiXqaXArzL9m6E4tXYatyN1 KieFWrXYfzz1.DF_PLHe.72VwdpByF..RZSb7LrCDGIVByQ8X.F22hzcBnzo lN7lsVK2sk6snOQu45a5wznwU6KI1fw_.pMN4LxCHeIHyZYFYiP5cYDnK_k. RrDyYIk3XQw.VcdrN_gd7rJIvz8mtZljWW6yf5j4vmCVpQIhg87SpsxwI4Iy 3Gz8io4olQnUK_w17mkNAeQ3Obue_w9w0ddY-
X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo-
Received: from [172.16.1.120] (d.sturek@209.226.25.155 with login) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 12 Jun 2012 06:48:01 -0700 PDT
User-Agent: Microsoft-MacOutlook/14.2.2.120421
Date: Mon, 11 Jun 2012 13:27:03 -0700
From: Don Sturek <d.sturek@att.net>
To: Brian Haberman <brian@innovationslab.net>, Omprakash Gnawali <gnawali@cs.uh.edu>
Message-ID: <CBFBA265.16E67%d.sturek@att.net>
Thread-Topic: [Roll] Ralph's DISCUSS on MRHOF spec
In-Reply-To: <4FD137A4.3080801@innovationslab.net>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: 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: Tue, 12 Jun 2012 13:48:03 -0000

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