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

Ralph Droms <rdroms.ietf@gmail.com> Fri, 08 June 2012 20:08 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 6A2A911E8138 for <roll@ietfa.amsl.com>; Fri, 8 Jun 2012 13:08:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhmVHdjmwV75 for <roll@ietfa.amsl.com>; Fri, 8 Jun 2012 13:08:39 -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 0DFD611E812C for <roll@ietf.org>; Fri, 8 Jun 2012 13:08:17 -0700 (PDT)
Received: by vcqp1 with SMTP id p1so1415693vcq.31 for <roll@ietf.org>; Fri, 08 Jun 2012 13:08:17 -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=M8rgKVFMYNDGEfYS4AVumsP9GHmF23AHFkS4D4l64KI=; b=m/xHbJfU8xniDmKvllDS4ji8T3fOLwF0SxLfa4JmdeMGYUoEDvp2FHmsRQZwuBwhvX +UtaBLyQzAa7xhnXB2EyyT7//RhI5kbnIhl1LhHHkYFcHio5MUTJNWg5k8mkBHwzJWw6 L08V6HtYHPLSwKnQA8vRgOMFX4b5e/WV+wE1PGfgfDaEWaUdUqsfUp5J09Dvkw9pwXV9 BoDlPo0QwX4I825/DjMDDr4DiYa4HMgWWNk8NgGTqvdNnKwpBZkNjcUctwS17PQUa45o pjIs0Ri6jStP8yTW0Xgoflzw4ZwqHfodN0DLEZiLtMPQlooPUEm8NX0MhVZrPoZ5nU9x RFfg==
Received: by 10.220.39.206 with SMTP id h14mr7310668vce.63.1339186097191; Fri, 08 Jun 2012 13:08:17 -0700 (PDT)
Received: from [161.44.65.173] ([161.44.65.173]) by mx.google.com with ESMTPS id ek5sm11329265vdb.5.2012.06.08.13.08.15 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Jun 2012 13:08:15 -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: <CC2E67E8-B983-4101-83C8-3AB996F72023@cs.stanford.edu>
Date: Fri, 08 Jun 2012 16:08:12 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <058F9835-D819-49CB-B704-2BB9D1EB8902@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> <CAC8E858-8215-4BC8-98C6-962109324BED@gmail.com> <E045AECD98228444A58C61C200AE1BD806E78F8F@xmb-rcd-x01.cisco.com> <4FFC4E5C-03CA-43D3-9220-DABDD52102FB@cs.stanford.edu> <5395.1339164690@marajade.sandelman.ca> <5ABEAC00-EE4E-4B10-9127-8D8727135051@gmail.com> <CC2E67E8-B983-4101-83C8-3AB996F72023@cs.stanford.edu>
To: Philip Levis <pal@cs.stanford.edu>
X-Mailer: Apple Mail (2.1278)
Cc: 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: Fri, 08 Jun 2012 20:08:40 -0000

On Jun 8, 2012, at 1:28 PM 6/8/12, Philip Levis wrote:

> 
> On Jun 8, 2012, at 9:31 AM, Ralph Droms wrote:
> 
>> 
>> On Jun 8, 2012, at 10:11 AM 6/8/12, Michael Richardson wrote:
>> 
>>> 
>>>>>>>> "Philip" == Philip Levis <pal@cs.stanford.edu> writes:
>>>  Philip> I agree that this is a good question to ask. I disagree that
>>>  Philip> now is an appropriate time to answer it definitively; we
>>>  Philip> currently have only one OCP. We made a concrete and
>>>  Philip> deliberate design decision. I'd argue we should stick with
>>>  Philip> it to at least see it play out a bit more. E.g., once MRHOF
>>>  Philip> is actually a proposed standard and we have significant
>>>  Philip> experience using it. It's so critical in systems design to
>>> 
>>> I think what you are saying is that splitting MRHOF into multiple OCPs
>>> in the future would not be so difficult a thing to do.
>> 
>> Yeah, but once the code is deployed, nobody is going to make changes.
>> 
>>> There is a coding simplicity in what we have now, and we should be
>>> conscious of the constraints of our devices.
>> 
>> I'll push back a little - inferring the metric from the received DIO is certainly no simpler than learning the metric directly from the OCP...
> 
> 
> Ralph,
> 
> 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.

I have to say this is the first I've heard, based on the specs I've reviewed to date, of an OF that would dynamically change its behavior. 

Why wouldn't RPL Instances - one optimized for low latency and one optimized for low energy - be an acceptable and simpler solution?  How would the metric be changed atomically?  How would nodes be notified that the metric had changed?

Metric flexibility seems like a hypothetical that needs more thought and additional mechanism in RPL to become real.  In any event, I'll clarify that I wasn't thinking that every the OCP for every OF encode the metric for that OF.  It seemed, in the case of MRHOF, that a separate OCP for each metric might solve the problem of indicating the selected metric to a receiving node.

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

We may not be talking about the same issue, as I don't quite understand your question about flexibility.  Can you say more about it?

Do we agree that the selected metric for a RPL Instance using MRHOF needs to be indicated to the receiving node for the node to make a policy decision about whether to join the RPL Instance?

- Ralph
  

> Phil
> 
> 
> 
> Phil
>