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

"Pascal Thubert (pthubert)" <> Fri, 08 June 2012 20:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 57CEA11E8138 for <>; Fri, 8 Jun 2012 13:03:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YHiIv7B-JdZz for <>; Fri, 8 Jun 2012 13:03:53 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C9F1611E80DC for <>; Fri, 8 Jun 2012 13:03:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2490; q=dns/txt; s=iport; t=1339185804; x=1340395404; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/Q6u4RnngMm9Kwe+dHFf1hcA6DTuKbZMZJYTSq8y9xA=; b=PzoAnyKXy3OgTilzDU1LMoDfhaWgtcLLJ8tH5SIrAh4LmdDtCFitJYRB YqUcQkY0NVfvqQ87NUi1aWAv5MbyYeaChVgOTt94nZqQ0byJd1OPelfC/ fAjZ48B2C3zjRGDUSwb7I9L5T5Y1LnHdaWntaPrNGpkcRDcAS/Hu8SQwR g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAFpa0k+tJV2b/2dsb2JhbABFDrRJgQeCGQEBBAEBAQ8BJzQLEAIBCA4UFBAnCyUCBAENBQgah2kLmRefXgSLK4UbYAOjM4Fmgic5
X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="90847039"
Received: from ([]) by with ESMTP; 08 Jun 2012 20:03:23 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id q58K3Njc032456 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Jun 2012 20:03:23 GMT
Received: from ([]) by ([]) with mapi id 14.02.0298.004; Fri, 8 Jun 2012 15:03:23 -0500
From: "Pascal Thubert (pthubert)" <>
To: Philip Levis <>, Ralph Droms <>
Thread-Topic: [Roll] Ralph's DISCUSS on MRHOF spec
Thread-Index: AQHNRZwXU3Zy3u1cZ0ORHM+g2HZO3Zbw1ouA
Date: Fri, 08 Jun 2012 20:03:22 +0000
Deferred-Delivery: Fri, 8 Jun 2012 20:03:00 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-tm-as-product-ver: SMEX-
x-tm-as-result: No--40.164800-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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:03:54 -0000

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.

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...




Roll mailing list