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

Mukul Goyal <mukul@uwm.edu> Fri, 08 June 2012 04:09 UTC

Return-Path: <prvs=4996a14c8=mukul@uwm.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 DD9AC11E8176 for <roll@ietfa.amsl.com>; Thu, 7 Jun 2012 21:09:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.479
X-Spam-Level:
X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, 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 ON2hYvhW3Brz for <roll@ietfa.amsl.com>; Thu, 7 Jun 2012 21:09:39 -0700 (PDT)
Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id 06E9911E8175 for <roll@ietf.org>; Thu, 7 Jun 2012 21:09:36 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap4EAAx60U9/AAAB/2dsb2JhbABFDoVEsh8BAQEDAQEBASBLCwwPDgMEAQEBAgINGQIpKAgGE4d9AwYFC6ZLiHANSokABIEjiSJhhG6BEgOIQIxej3uCJ1c
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 60426E6A8D; Thu, 7 Jun 2012 23:09:36 -0500 (CDT)
X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu
Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxneUJtXsQLd; Thu, 7 Jun 2012 23:09:36 -0500 (CDT)
Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id F0759E6A72; Thu, 7 Jun 2012 23:09:35 -0500 (CDT)
Date: Thu, 07 Jun 2012 23:09:35 -0500
From: Mukul Goyal <mukul@uwm.edu>
To: Philip Levis <pal@cs.stanford.edu>
Message-ID: <714073396.628993.1339128575855.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <4FFC4E5C-03CA-43D3-9220-DABDD52102FB@cs.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [99.20.249.193]
X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995)
X-Authenticated-User: mukul@uwm.edu
Cc: Haberman Brian <brian@innovationslab.net>, Stiemerling Martin <mstiemerling@googlemail.com>, roll <roll@ietf.org>, 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, 08 Jun 2012 04:09:40 -0000

I agree with Philip.

Thanks
Mukul

----- Original Message -----
From: "Philip Levis" <pal@cs.stanford.edu>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Cc: "Haberman Brian" <brian@innovationslab.net>, "roll" <roll@ietf.org>, "Stiemerling Martin" <mstiemerling@googlemail.com>, "Michael Richardson" <mcr@sandelman.ca>
Sent: Thursday, June 7, 2012 11:02:23 PM
Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec


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


I agree that this is a good question to ask. I disagree that now is an appropriate time to answer it definitively; we currently have only one OCP. We made a concrete and deliberate design decision. I'd argue we should stick with it to at least see it play out a bit more. E.g., once MRHOF is actually a proposed standard and we have significant experience using it. It's so critical in systems design to not waffle on design decisions, otherwise you end up with a contradictory and messy system. You do want to correct, but not lightly and only when the benefits of the change significantly outweigh the costs. I'm not at all sure this is the case here.

Phil

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll