Re: [Roll] Ralph's DISCUSS on MRHOF spec
Philip Levis <pal@cs.stanford.edu> Fri, 08 June 2012 17:28 UTC
Return-Path: <pal@cs.stanford.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 7CA8221F8911 for <roll@ietfa.amsl.com>; Fri, 8 Jun 2012 10:28:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 leRsvzdj4Hos for <roll@ietfa.amsl.com>; Fri, 8 Jun 2012 10:28:20 -0700 (PDT)
Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id E598B21F88F9 for <roll@ietf.org>; Fri, 8 Jun 2012 10:28:20 -0700 (PDT)
Received: from 23-24-194-1-static.hfc.comcastbusiness.net ([23.24.194.1] helo=[192.168.1.106]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from <pal@cs.stanford.edu>) id 1Sd2yw-0007EA-Uv; Fri, 08 Jun 2012 10:28:19 -0700
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset="us-ascii"
From: Philip Levis <pal@cs.stanford.edu>
In-Reply-To: <5ABEAC00-EE4E-4B10-9127-8D8727135051@gmail.com>
Date: Fri, 08 Jun 2012 10:28:18 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <CC2E67E8-B983-4101-83C8-3AB996F72023@cs.stanford.edu>
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>
To: Ralph Droms <rdroms.ietf@gmail.com>
X-Mailer: Apple Mail (2.1257)
X-Scan-Signature: 26b8f8cb9d50f38c95a96ded60a4c5d6
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 17:28:21 -0000
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. 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. Phil Phil
- [Roll] Ralph's DISCUSS on MRHOF spec Mukul Goyal
- Re: [Roll] Ralph's DISCUSS on MRHOF spec Michael Richardson
- Re: [Roll] Ralph's DISCUSS on MRHOF spec Ralph Droms
- Re: [Roll] Ralph's DISCUSS on MRHOF spec Mukul Goyal
- Re: [Roll] Ralph's DISCUSS on MRHOF spec Philip Levis
- Re: [Roll] Ralph's DISCUSS on MRHOF spec Ralph Droms
- Re: [Roll] Ralph's DISCUSS on MRHOF spec Pascal Thubert (pthubert)
- Re: [Roll] Ralph's DISCUSS on MRHOF spec Omprakash Gnawali
- Re: [Roll] Ralph's DISCUSS on MRHOF spec Philip Levis
- Re: [Roll] Ralph's DISCUSS on MRHOF spec Mukul Goyal
- Re: [Roll] Ralph's DISCUSS on MRHOF spec Ralph Droms
- Re: [Roll] Ralph's DISCUSS on MRHOF spec Mukul Goyal
- Re: [Roll] Ralph's DISCUSS on MRHOF spec Ralph Droms
- Re: [Roll] Ralph's DISCUSS on MRHOF spec Mukul Goyal
- Re: [Roll] Ralph's DISCUSS on MRHOF spec Ralph Droms
- Re: [Roll] Ralph's DISCUSS on MRHOF spec Mukul Goyal
- Re: [Roll] Ralph's DISCUSS on MRHOF spec Ralph Droms
- Re: [Roll] Ralph's DISCUSS on MRHOF spec Michael Richardson
- Re: [Roll] Ralph's DISCUSS on MRHOF spec Ralph Droms
- Re: [Roll] Ralph's DISCUSS on MRHOF spec Philip Levis
- Re: [Roll] Ralph's DISCUSS on MRHOF spec Michael Richardson
- Re: [Roll] Ralph's DISCUSS on MRHOF spec Pascal Thubert (pthubert)
- Re: [Roll] Ralph's DISCUSS on MRHOF spec Pascal Thubert (pthubert)
- Re: [Roll] Ralph's DISCUSS on MRHOF spec Ralph Droms
- Re: [Roll] Ralph's DISCUSS on MRHOF spec Ralph Droms
- Re: [Roll] Ralph's DISCUSS on MRHOF spec Philip Levis
- Re: [Roll] Ralph's DISCUSS on MRHOF spec Philip Levis
- Re: [Roll] Ralph's DISCUSS on MRHOF spec JP Vasseur
- Re: [Roll] Ralph's DISCUSS on MRHOF spec Michael Richardson
- Re: [Roll] Ralph's DISCUSS on MRHOF spec Brian Haberman
- [Roll] Enhanced RPL functionality on J-Sim platfo… Panos Trakadas
- Re: [Roll] Ralph's DISCUSS on MRHOF spec Don Sturek
- Re: [Roll] Enhanced RPL functionality on J-Sim pl… Ulrich Herberg
- [Roll] Σχετ: Enhanced RPL functionality on J-Sim … Panos Trakadas
- Re: [Roll] Ralph's DISCUSS on MRHOF spec Omprakash Gnawali
- Re: [Roll] Ralph's DISCUSS on MRHOF spec Panos Trakadas
- Re: [Roll] Ralph's DISCUSS on MRHOF spec Omprakash Gnawali
- Re: [Roll] Ralph's DISCUSS on MRHOF spec Mukul Goyal
- Re: [Roll] Ralph's DISCUSS on MRHOF spec Omprakash Gnawali
- Re: [Roll] Ralph's DISCUSS on MRHOF spec Ralph Droms