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

Ralph Droms <> Fri, 08 June 2012 20:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3478E21F84E1 for <>; Fri, 8 Jun 2012 13:10:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lESd0l0Zw4yC for <>; Fri, 8 Jun 2012 13:10:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6CA4F21F84DE for <>; Fri, 8 Jun 2012 13:10:03 -0700 (PDT)
Received: by vbbez10 with SMTP id ez10so1488229vbb.31 for <>; Fri, 08 Jun 2012 13:10:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=2c2QgLY/XYLePjSCbwlQZLTxaZ0zBtIcrRZodBBnv0Y=; b=uzdZvAad08mMpOUJqqtOXAV/UGQ+Py03uuYX0CGmGi54wOh4Twny6XH/3WkRo8aMHm xWqZkQFAcedDYsYWAHXr+5CExza4gmnSQFz9ncF8nUoq1X380de7vwWHPn/fE0Rhf29b FA1iYF7DH2bDZi5Bj78e8NdqzJfEzgBHgdet4V1XQdsq5V8W3tK0Sckan3bubtG/zMxw +vtgcdEo79glHBGPK+XU+u+Xz9075ru2WMBRBz/Y5iLP8Dpx5wIYjrSfGjQkq//8dXP9 h2lXjfGTFzyPXW1meqzRtTHadWIetzE9Cnft10llEFy/tNNgIMXQ2anQLzqQjGRzT1qx YABQ==
Received: by with SMTP id p20mr6542934vdj.129.1339186202681; Fri, 08 Jun 2012 13:10:02 -0700 (PDT)
Received: from [] ([]) by with ESMTPS id g10sm11339864vdk.2.2012. (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Jun 2012 13:10:01 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset="us-ascii"
From: Ralph Droms <>
In-Reply-To: <>
Date: Fri, 08 Jun 2012 16:09:58 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <>
To: "Pascal Thubert (pthubert)" <>
X-Mailer: Apple Mail (2.1278)
Cc: roll <>
Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 08 Jun 2012 20:10:04 -0000

On Jun 8, 2012, at 4:03 PM 6/8/12, Pascal Thubert (pthubert) wrote:

> Hi Phil
> Let's separate two issues:
> 1) OCPs should not have metric flexibility
> 2) There should be multiple MRHOFs, for different metric combinations
> We decided against 1) in the design phase due to conversations JP had with some RPL users. The argument was that there are situations where you might want to dynamically shift the operation of the network. E.g., you have an OF that optimizes for two metrics, primary and secondary. You have a RPL network designed for monitoring physical security and reporting potential intrusions. In the monitoring phase, energy is the primary metric, with latency second. In the reporting/alert phase, latency is the primary metric and energy is the secondary metric. 
> If we decide 1), then it's not possible to do the above approach unless you include two separate OFs. Furthermore, let's say you want to just use energy? Or just use latency? You lose flexibility. The point is that this is a one way street. If you allow metric flexibility, then you can define OFs that only support one metric. If you do not allow metric flexibility, then you cannot define OFs that are flexible with respect to metrics.
> [Pascal] If there is a well-defined logic in an OF that plays with coefficients to ponder latency and battery, then we have a single OCP that represents that logic. Overtime, the coefficients might evolve so that a battery-depleted devices gets less packets though. I'm perfectly fine with that. But note that from the start the OF supports both metrics, even if at a given point of time the coefficient can be 0 for one of those.

Agreed - not every OF has to encode its single metric in its OCP.  But for some OFs, like MRHOF, it might make sense.

> With respect to 2), I'd love to hear from the folks implementing MRHOF whether they think this is a good idea. Are there cases where the flexibility is useful? ETX is stated as the least common denominator through a SHOULD. My worry right now is that we're pursuing a not-unreasonable-but-mostly-hypothetical concern. As I said before, asking the question is great, but we don't want to reverse years of agreed-upon-reasoning and tradeoff decisions without careful thought.
> [Pascal] Agreed with the mostly hypothetical. Is anyone using another metric than ETX? But " years of agreed-upon-reasoning and tradeoff decisions" might be slightly exaggerated...

I'm still confused about what is hypothetical.  MRHOF is defined for 5 possible metrics (or maybe 3).  Is it the case that only ETX is really going to be used?

- Ralph

> Cheers,
> Pascal
> Phil
> _______________________________________________
> Roll mailing list