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

Mukul Goyal <mukul@uwm.edu> Fri, 29 June 2012 19:00 UTC

Return-Path: <prvs=520c6ee4b=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 373D521F889E for <roll@ietfa.amsl.com>; Fri, 29 Jun 2012 12:00:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Level:
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, J_CHICKENPOX_62=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 knYKFAJnb+6K for <roll@ietfa.amsl.com>; Fri, 29 Jun 2012 12:00:15 -0700 (PDT)
Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE6B21F8892 for <roll@ietf.org>; Fri, 29 Jun 2012 12:00:13 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ap4EANn67U9/AAAB/2dsb2JhbABFDoVMtBsBAQEEAQEBIEsLDA8RBAEBAQICDRkCKSgIBhOHfQMLC6kDiUQFCEqJAASBIIkzZIR4gRIDiEqMaYsDhQCCJlc
Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 1D8CA1FD014; Fri, 29 Jun 2012 14:00:13 -0500 (CDT)
X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu
Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h72y-u1RrS6r; Fri, 29 Jun 2012 14:00:12 -0500 (CDT)
Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 86C711FD013; Fri, 29 Jun 2012 14:00:12 -0500 (CDT)
Date: Fri, 29 Jun 2012 14:00:12 -0500 (CDT)
From: Mukul Goyal <mukul@uwm.edu>
To: Omprakash Gnawali <gnawali@cs.uh.edu>
Message-ID: <283139735.80026.1340996412381.JavaMail.root@mail17.pantherlink.uwm.edu>
In-Reply-To: <CAErDfUTf-0VFhrAe+Dkbrq68K4XHmwQRw0_KKq5DsCd-PKEWOA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
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: Brian Haberman <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, 29 Jun 2012 19:00:18 -0000

>It is clear that we will benefit by explicitly stating how to tell
what metric+OF is used in the network. Unless there is any objection,
I will will proceed with the explanation that metric selection is
indicated by the presence of the metric in the container and OF
selection by OCP. For example, MRHOF(ETX) will use OF for MRHOF and
ETX will be in the metric container.

I agree except that, for MRHOF, absence of a metric container means that ETX is the metric in use.

Thanks
Mukul

----- Original Message -----
From: "Omprakash Gnawali" <gnawali@cs.uh.edu>
To: "Panos Trakadas" <trakadasp@yahoo.gr>
Cc: "Stiemerling Martin" <mstiemerling@googlemail.com>om>, "Brian Haberman" <brian@innovationslab.net>et>, "roll" <roll@ietf.org>rg>, "Michael Richardson" <mcr@sandelman.ca>
Sent: Friday, June 29, 2012 12:54:05 PM
Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec

Sorry, I should have been clearer. I was asking if we have a consensus
that it is the combination of:

1. metric in the DIO, and
2. OCP

that will tell us which metric+OF we have decided to use.

Most thought that this is the case but there were some with the
opinion that it might be clearer to use  separate OCP for each
metric,OF combination.

It is clear that we will benefit by explicitly stating how to tell
what metric+OF is used in the network. Unless there is any objection,
I will will proceed with the explanation that metric selection is
indicated by the presence of the metric in the container and OF
selection by OCP. For example, MRHOF(ETX) will use OF for MRHOF and
ETX will be in the metric container.

There was a separate discussion on allocating some OCP for
proprietary/private OFs that people might want to have but that is a
separate discussion.

- om_p

On Fri, Jun 29, 2012 at 10:43 AM, Panos Trakadas <trakadasp@yahoo.gr> wrote:
> Well, IMO it depends on the specific user requirements set by the root node.
> It could be a nice idea to investigate the metrics (and techniques like hysteresis or composition) that would commonly be used in each one of the application areas that RPL is targeting (more as a proposition/guideline for the developers).
> To be honest, we have already started reading the respective RFCs and the AMI draft to figure out the appropriate metrics per application domain in order to include them in the next version of metrics-composition draft.
> Panos
>
>
> On 29 Jun 2012, at 19:21, Omprakash Gnawali <gnawali@cs.uh.edu> wrote:
>
> 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
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll