Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document

Philip Levis <pal@cs.stanford.edu> Sat, 10 September 2011 21:22 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 E9BD521F84EC for <roll@ietfa.amsl.com>; Sat, 10 Sep 2011 14:22:55 -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 u6sHZnCs-6tP for <roll@ietfa.amsl.com>; Sat, 10 Sep 2011 14:22:55 -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 6535E21F84E1 for <roll@ietf.org>; Sat, 10 Sep 2011 14:22:55 -0700 (PDT)
Received: from [76.14.66.110] (helo=[192.168.0.103]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from <pal@cs.stanford.edu>) id 1R2V2k-0000pD-5P; Sat, 10 Sep 2011 14:24:54 -0700
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="windows-1252"
From: Philip Levis <pal@cs.stanford.edu>
In-Reply-To: <0F84189A-987B-47A0-A732-9668F8469BAF@thomasclausen.org>
Date: Sat, 10 Sep 2011 14:24:55 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <178F3A34-5018-44B4-B348-69DC37964F51@cs.stanford.edu>
References: <1593431155.140676.1314734802999.JavaMail.root@mail05.pantherlink.uwm.edu> <1831033C-FE54-4B15-BC8B-B4C8E230AFD1@thomasclausen.org> <0621F6C4-B7AA-4E04-9021-CE5CC9B8A888@cisco.com> <609341E6-F4B1-483B-8306-05265023C840@thomasclausen.org> <D1B95B1C-6445-4FCA-AF26-BD5CBD873D18@cisco.com> <0F84189A-987B-47A0-A732-9668F8469BAF@thomasclausen.org>
To: Thomas Heide Clausen <IETF@ThomasClausen.org>
X-Mailer: Apple Mail (2.1084)
X-Scan-Signature: 882c50607b8592e4560fe9069cd502a5
Cc: roll WG <roll@ietf.org>
Subject: Re: [Roll] Adoption of draft-goyal-roll-rpl-compression as a new ROLL WG document
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: Sat, 10 Sep 2011 21:22:56 -0000

On Aug 31, 2011, at 10:08 AM, Thomas Heide Clausen wrote:

> 
> On Aug 31, 2011, at 19:05 , JP Vasseur wrote:
> 
>> 
>> On Aug 31, 2011, at 6:57 PM, Thomas Heide Clausen wrote:
>> 
>>> 
>>> On Aug 31, 2011, at 18:41 , JP Vasseur wrote:
>>> 
>>> >
>>> > On Aug 31, 2011, at 5:55 PM, Thomas Heide Clausen wrote:
>>> >
>>> >> I would actually argue that RPL and P2P-RPL are two entirely different protocols (albeit sharing some commonalities in the overall message structure).
>>> >>
>>> >> There are ways of making multiple routing protocols co-exist on the same routers (and in the same network). However I am not sure that it is such  a good idea to do so in a LLN.
>>> >>
>>> >> I've always found it odd that P2P traffic was not supported in RPL -- and really, dog-leg routing through a DODAG root and using source routing isn't (efficiently) supporting P2P.
>>> >
>>> > Thomas,
>>> >
>>> > I cannot let you say this … you perfectly know that the core specification of RPL supports P2P traffic.
>>> 
>>> Ah, but you must, JP, you must.
>>> 
>>> Note that I said in the above that RPL supports P2P traffic by way of dog-leg routing through the DODAG root, then source routing -- that's the _only_ way P2P is supported, guaranteed to work across all the different RPL-flavors (storing/non-storing with/without RPL-P2P, …) that the WG is exploring.
>>> 
>> Well the sentence was, to say the least, strangely worded … As you know, you go via the root only if you deploy non-storing.
>> 
> 
> Well, given the state requirements for storing-mode in networks larger than a few handful of routers, non-storing mode seems to be the only realistic choice for the lions share of deployments that I am aware of. 
> 
> Thus, dog-leg-source-routing is pretty much the only viable option - and you must admit that it's not a particularly elegant or efficient option at that?

Thomas,

In the mesh space, I'm less concerned with "elegant," which is based on taste and mental conception, than "works," which means it's practical and actually solves problems. You know as well as I do how wireless mesh research (and even proposed standards!) is a graveyard of elegant solutions which don't work.  

Up-down routing may not be very efficient in the data plane, it's true: but it has significant benefits in terms of the size and cost of maintaining routing tables, in terms of RAM, state management complexity, and control traffic. There are plenty of deployments today which use it because it's simple and practical. From the perspective of an elegant idea for the academy, it's not very appealing; but I trust the engineers I've spoken with on how attractive it is as a practical solution. It's clear that if P2P traffic between nodes distant from roots is the dominant traffic pattern, one might want something more efficient (hence the P2P work); but many networks are simpler data collection networks with smaller amounts of P2P traffic, and ignoring their needs seems mistaken to me.

Phil