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

Ralph Droms <rdroms.ietf@gmail.com> Thu, 07 June 2012 19:48 UTC

Return-Path: <rdroms.ietf@gmail.com>
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 ACE3621F8670 for <roll@ietfa.amsl.com>; Thu, 7 Jun 2012 12:48:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.385
X-Spam-Level:
X-Spam-Status: No, score=-103.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 7ICd-+IUi8sB for <roll@ietfa.amsl.com>; Thu, 7 Jun 2012 12:48:31 -0700 (PDT)
Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE5B21F8680 for <roll@ietf.org>; Thu, 7 Jun 2012 12:48:31 -0700 (PDT)
Received: by vcqp1 with SMTP id p1so598896vcq.31 for <roll@ietf.org>; Thu, 07 Jun 2012 12:48:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=hEmTl3YRny8en/jBpjIsA3gJ6JdQXmSYtyM7M0hItn0=; b=wggkJyLTqepaz6wME9pq6Xda8VVnBKEq8SnEbJxd5hW7BpyZ8U6w3rpqPSgKniBlcQ EStD0UECb3DPFMfgDap9wNmm0nXmvPM2KeGsa7ljcOtL741OzE7esaOwa1h813/2lx/V bgAbnEK8h2wQ3pht9J/eI1mPSnd4aJ0hhACuQlqKroF9Wwsj5IDXBYIpNbCof5uFpdgf BR07rnF19HJ10viSGdDOqqSME2T/8Z+4Jd9WZXIVt8p9Aa9/OrWKEaYhcU9KJ39t+6Ec 0Cp1sOI6yw4zW74yw1SRaIW0xSiW1SbFEd6z0Ne78sMrnYd9QYG/UdlqrJx4DmTZ4c8h IZaA==
Received: by 10.220.153.80 with SMTP id j16mr3327709vcw.55.1339098510454; Thu, 07 Jun 2012 12:48:30 -0700 (PDT)
Received: from bxb-vpn3-696.cisco.com (198-135-0-233.cisco.com. [198.135.0.233]) by mx.google.com with ESMTPS id i10sm5909894vdw.21.2012.06.07.12.48.26 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Jun 2012 12:48:28 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset=us-ascii
From: Ralph Droms <rdroms.ietf@gmail.com>
In-Reply-To: <53E28E3B-4C73-4BD3-BCFE-2C669FC3FA1D@cs.stanford.edu>
Date: Thu, 7 Jun 2012 15:48:24 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <CAC8E858-8215-4BC8-98C6-962109324BED@gmail.com>
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>
To: Philip Levis <pal@cs.stanford.edu>
X-Mailer: Apple Mail (2.1278)
Cc: Haberman Brian <brian@innovationslab.net>, 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 19:48:31 -0000

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.

- Ralph

> 
> Phil
>