Re: [Roll] MUSTing P2P states [was RE: Moving forward with the protocol work]
"Don Sturek" <d.sturek@att.net> Thu, 30 July 2009 20:39 UTC
Return-Path: <d.sturek@att.net>
X-Original-To: roll@core3.amsl.com
Delivered-To: roll@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7AC928C194 for <roll@core3.amsl.com>; Thu, 30 Jul 2009 13:39:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.149
X-Spam-Level:
X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8ptqchoj6d7 for <roll@core3.amsl.com>; Thu, 30 Jul 2009 13:39:54 -0700 (PDT)
Received: from smtp121.sbc.mail.re3.yahoo.com (smtp121.sbc.mail.re3.yahoo.com [66.196.96.94]) by core3.amsl.com (Postfix) with SMTP id 3AE0A3A68E8 for <roll@ietf.org>; Thu, 30 Jul 2009 13:39:54 -0700 (PDT)
Received: (qmail 95812 invoked from network); 30 Jul 2009 20:33:16 -0000
Received: from unknown (HELO Studio) (d.sturek@78.64.18.91 with login) by smtp121.sbc.mail.re3.yahoo.com with SMTP; 30 Jul 2009 20:33:14 -0000
X-YMail-OSG: 1T9Vf9gVM1nzmbPXOpDSn46J7BFshG0OHuF3Jm.iWIFRrrITuGS3ZM_5jpgktiOmk_aMf8.VNCSA.7Z4Q8.DH3W09mOn8ZW0JEf9zKBUFH0fuK_6tAiqXfqNZ3P4qbDvx9wnRd46GC3HrH_iQArWvgYfS52l8tnUDqW2TPOsIYT177Y3ICx69Bi0fO5ztj7SymB6Gq8XWjTyqBU2lT5cAkjxVrveuzouXzUjyR6GtFfVBlqq_OGkGnEil_sA2vkytmvai2alsmQ.isgFDtHwq8ZxW.x_T6kLm0OCE6ItN38-
X-Yahoo-Newman-Property: ymail-3
From: Don Sturek <d.sturek@att.net>
To: "'Pascal Thubert (pthubert)'" <pthubert@cisco.com>, Jerald.P.Martocci@jci.com
References: <014401ca1130$8c7c9e00$a575da00$@sturek@att.net><OF07B2215E.8CF400CD-ON86257603.00597B11-86257603.005BF4BD@jci.com> <01a201ca1137$28d48410$7a7d8c30$@sturek@att.net> <7892795E1A87F04CADFCCF41FADD00FC07DC2EDB@xmb-ams-337.emea.cisco.com>
In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC07DC2EDB@xmb-ams-337.emea.cisco.com>
Date: Thu, 30 Jul 2009 13:33:07 -0700
Message-ID: <00a901ca1154$f5085710$df190530$@sturek>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AA_01CA111A.48A97F10"
X-Mailer: Microsoft Office Outlook 12.0
thread-index: AcoRNQitCa77pr4CSbifjDHMLIBt6AAANpJgAADviOAABplL4A==
Content-Language: en-us
Cc: 'ROLL WG' <roll@ietf.org>, roll-bounces@ietf.org
Subject: Re: [Roll] MUSTing P2P states [was RE: Moving forward with the protocol work]
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: d.sturek@att.net
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Thu, 30 Jul 2009 20:39:54 -0000
Hi Pascal, Thanks for your note. I think it needs to be made clear to all contributors of the various requirements documents (urban, home, building, etc) how their specific requirements are addressed in the RPL draft. Otherwise, we won't find enough consensus on the document to have it as a baseline for ROLL. Is there a way to clearly state to Jerry and the authors of the building automation requirements how P2P is enabled (what they have to do in RPL to make it work) and what impact this has (added resources to hold state information, re-propagation of Destination Advertisements, etc.). I think part of the discussion is pointing out that not everyone can map the RPL draft to how the various requirements are being met. Once we understand what is available in terms of P2P support, and what the implications are, then we can figure out if RPL is acceptable as a baseline across all market areas and whether more work can then focus on improving P2P support, loop avoidance, etc. Don From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] Sent: Thursday, July 30, 2009 10:30 AM To: d.sturek@att.net; Jerald.P.Martocci@jci.com Cc: ROLL WG; roll-bounces@ietf.org Subject: MUSTing P2P states [was RE: [Roll] Moving forward with the protocol work] Hi Don: You're correct. If the DAO states are enabled everywhere, the first common parent will route down to the destination. But the doc cannot MUST keeping states in all nodes at the protocol level because there are some use cases where that makes no sense. There might even be a case where no data whatsoever is unicast to the devices, in which case even storing source route paths at the root would be ridiculous. An example of that would be environmental monitoring using widespread cheap sensors. It seems to me that this discussion is caused by a confusion between what belongs to protocol and what belongs to product and deployment. The protocol gives you tools, and then you have to use them intelligently in the products you build. Another confusion I've seen here is that between the rough consensus to get WG Doc and a ballot at IEEE or others. The call here is NOT a ballot. This is just to create a foundation for the WG to work on. So obviously the doc does not have everything ironed out. The question is rather whether the doc is a good foundation for that work at it appears that many people agree on that. Cheers, Pascal From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Don Sturek Sent: jeudi 30 juillet 2009 19:00 To: Jerald.P.Martocci@jci.com Cc: 'ROLL WG'; roll-bounces@ietf.org Subject: Re: [Roll] Moving forward with the protocol work Hi Jerry, I may have misread the RPL proposal. I thought the Destination Address notifications allowed the DAG root to route back down to a device in the DAG and that feature enabled P2P in all cases. I thought also the Destination Address notifications for devices with lower depth/rank could be used by devices within a DAG to more efficiently reroute P2P traffic within the DAG (not optimally, just "more efficiently than sending the packet all the way to the DAG root first). I thought in all cases P2P was supported (just without a mechanism to minimize the hop count). Could someone from the DT comment on the assumptions above? Did I understand that optimizing P2P for building controls is mainly about minimizing hop counts? If a building controls solution could choose between optimizing hop count for P2P and flooding the network to find the optimal P2P hop count, would it choose to flood the network? I think it is the lack of network flooding to establish routes and the minimal storage of route state information along the route that I found so attractive about RPL... Don From: Jerald.P.Martocci@jci.com [mailto:Jerald.P.Martocci@jci.com] Sent: Thursday, July 30, 2009 9:44 AM To: d.sturek@att.net Cc: 'Mischa Dohler'; 'ROLL WG'; roll-bounces@ietf.org Subject: RE: [Roll] Moving forward with the protocol work Hi Don, As I read the draft, RPL doesn't currently guarantee p2p communication regardless of hop count. Only if some node higher in the DAG elects to provide a path back down the DAG to the destination then there is p2p path. RPL doesn't mandate this even for the LBR. Hence a packet could squirt all the way up to the LBR and still be dropped since the LBR itself has no route defined to the destination. You need to keep in mind that the LLN devices are primarily a building controllers that 'moonlight' as a router; it's not a router that happens to also do building control. The likelihood that a controller sitting higher in the DAG being altruist and defining pathways to all possible sub-DAG devices is nil. As for hops, this is very important too. Not so much for latency. The time constant for most building HVAC control loops is in minutes so having a packet arrive at its destination a tad late is not too concerning. (NOTE: Fire and lighting applications are much more time critical). The problem is that the source device, typically a battery powered sensor must stay awake and leave its receiver active until the packet has migrated to its destination and the application ACK has been received. This will reduce battery life at least 10x. As for scalability, a typical PAN in a commercial building is limited to a floor which may require upwards to 250 LLN nodes. Sure we could have defined the PAN to be the entire complex and then require 10K nodes as do the other requirement specs. Empirical testing however determined that managing 250 nodes on a single wireless domain was difficult enough with regard to channel management, interference and hop count. Limiting PAN size to a floor seems to be the right balance point for complexity and flexibility. Jerry "Don Sturek" <d.sturek@att.net> 07/30/2009 11:12 AM Please respond to <d.sturek@att.net> To <Jerald.P.Martocci@jci.com>, "'Mischa Dohler'" <mischa.dohler@cttc.es> cc "'ROLL WG'" <roll@ietf.org>, <roll-bounces@ietf.org> Subject RE: [Roll] Moving forward with the protocol work Hi Jerry, I think RPL does support P2P but does not optimize the number of hops. I think that is the central issue you and Mukul are bringing up. I do question whether optimizing hops is really necessary. I think most applications (including building controls) can take advantage of a solution that well supports MP2P and P2MP with extensions to provide P2P capability (admittedly not optimized for hop count/cost but then also without nearly the overhead of packet flooding or storage of state information that optimized P2P solutions impose). I really don't see that trying (once again as they have in MANET for some time) to find a single protocol that efficiently implements P2P and scales while addressing the various data transmission patterns will result in anything other than the same set of solutions we have today (distance vector with flooding, link state routing and its derivatives, source routing and its derivatives). Don From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jerald.P.Martocci@jci.com Sent: Thursday, July 30, 2009 8:58 AM To: Mischa Dohler Cc: ROLL WG; roll-bounces@ietf.org Subject: Re: [Roll] Moving forward with the protocol work Hi Mischa, Nearly all communication in a commercial building facility management system is point to point. I'm surprised the other three requirements don't also have a strong p2p requirement. Back in the early 80's prior to processor based sensors, we deployed 'dumb sensors' that would simply upload their current environmental information to a centralized minicomputer. This centralized model was not scalable nor fault tolerant. That is if the minicomputer 'blew a gasket', the entire building went out of control. As soon as it was economically viable, we decentralized control by moving it down into the rooms. Now each room was controlled independently with an array of room sensors and room controllers. Now if a controller failed, only the room might lose control, not the entire complex. The room controllers were then further controlled by higher level controllers. This distributed architecture has been in place for 25 years and is the mainstay of building control. My point is that is the Commercial Market the LLN is not just a path for moving data nortbound. Most of the packets sent on the LLN are destined to other nodes on the LLN. They all require application ACKs. About 20% of the packets are destined to the LBR and onwards. These are event packets being sent to the higher layers for further analysis. If we don't support a robust p2p protocol option in ROLL, we will knock out the Building Market in its entirety which means at best you will only solve 75% of the need. Jerry Mischa Dohler <mischa.dohler@cttc.es> Sent by: roll-bounces@ietf.org 07/29/2009 04:18 PM To JP Vasseur <jvasseur@cisco.com> cc ROLL WG <roll@ietf.org> Subject Re: [Roll] Moving forward with the protocol work JP, all, We should use this early design stage to come up with one solution - one solution which is not necessarily optimum for all cases but for the (e.g.) 95% quantile. The PHY guys learned to live with such an approach. The MAC folks are getting there and we should take our chance now. 95% means clearly to concentrate on the core issues, of which loop detection/avoidance, p2p and security are somehow still open. I do understand the concept of loops arising. I have doubts that with the dynamics of typical ROLL networks, these will give us headaches within this 95% application quantile. I have read tons of papers produced in the last decade on routing in ROLL-type networks. Loop detection and avoidance was clearly not something people (including those doing practical rollouts and running their companies today) were worried about too much. Unless somebody provides me with a convincing study, I propose to merely adopt some simple and possibly sub-optimum heuristics and then forget about it. P2P seems to worry some of us (sorry, Jerry, for having forgotten about the p2p paragraph). However, again, are we talking about the 95% quantile here? Furthermore, how much p2p exactly are you talking about? Any node truly to any node? Are we back to pure ad hoc then? I guess if IETF couldn't provide us with a magic ultra low power solution for ad hoc networks in past years, then chances are slim that this will work out now. Unless somebody provides me with a convincing study that adopting a general p2p ROLL protocol will not jeopardize the efficiency of the 95% quantile applications, I propose to adopt some simple and possibly sub-optimum heuristics and then forget about it. Security is an important issue. Now that we are at it, I sampled quite a large number of companies at an M2M event in Paris a few months ago organized by Orange where we met with JP and others. The large majority of companies present there explicitly told me that - for a very varying set of reasons - they would never let IP run over their ROLL-type networks. The sheer majority did suprise me. We still have a lot of work ahead. I am in favour of adopting draft-dt-roll-rpl-01 as a WG document. Mischa. JP Vasseur wrote: > Dear WG, > > First of all, thanks for all the time and energy you all have devoted > during the past few weeks on the protocol work. There was excellent > followup discussion at the physical WG meeting. > > To the question "Do you think that RPL provides an adequate foundation > for the ROLL routing protocol work", there was clearly a good consensus > in the WG meeting. It was also recognized there are still several open > issues for which we WILL need help from many WG contributors, including > the authors of other documents. > > Could you please confirm (or not) the adoption of draft-dt-roll-rpl-01 > as a WG document ? > > Then we will of course move to the next step. > > Thanks, > > JP and David > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll
- Re: [Roll] Moving forward with the protocol work Mukul Goyal
- Re: [Roll] Moving forward with the protocol work Kris Pister
- Re: [Roll] Moving forward with the protocol work Carlos Jesús Bernardos Cano
- Re: [Roll] Moving forward with the protocol work Jerald.P.Martocci
- Re: [Roll] Moving forward with the protocol work Mischa Dohler
- [Roll] Moving forward with the protocol work JP Vasseur
- Re: [Roll] Moving forward with the protocol work Don Sturek
- Re: [Roll] Moving forward with the protocol work JP Vasseur
- Re: [Roll] Moving forward with the protocol work Julien Abeille (jabeille)
- Re: [Roll] Moving forward with the protocol work Robert Power
- Re: [Roll] Moving forward with the protocol work dominique.barthel
- Re: [Roll] Moving forward with the protocol work Samita Chakrabarti
- Re: [Roll] Moving forward with the protocol work Mathilde Durvy (mdurvy)
- Re: [Roll] Moving forward with the protocol work Laurent Toutain
- Re: [Roll] Moving forward with the protocol work Teco Boot
- Re: [Roll] Moving forward with the protocol work Tzeta Tsao
- Re: [Roll] Moving forward with the protocol work Alexandru Petrescu
- Re: [Roll] Moving forward with the protocol work Zach Shelby
- Re: [Roll] Moving forward with the protocol work Richard Kelsey
- [Roll] Data Is NOT Retained at the Node in DADR Ryusuke Masuoka
- Re: [Roll] Moving forward with the protocol work Roger Alexander
- Re: [Roll] Moving forward with the protocol work Hamid Mukhtar
- Re: [Roll] Moving forward with the protocol work Robert Cragie
- Re: [Roll] Moving forward with the protocol work JP Vasseur
- Re: [Roll] Moving forward with the protocol work Anders Brandt
- Re: [Roll] Moving forward with the protocol work Jerald.P.Martocci
- Re: [Roll] Moving forward with the protocol work Pascal Thubert (pthubert)
- Re: [Roll] Moving forward with the protocol work Jaudelice de Oliveira
- Re: [Roll] Moving forward with the protocol work Theodore Zahariadis
- Re: [Roll] Moving forward with the protocol work Tim Winter
- Re: [Roll] Moving forward with the protocol work Umair Bussi
- Re: [Roll] Moving forward with the protocol work Samita Chakrabarti
- Re: [Roll] Moving forward with the protocol work Mischa Dohler
- Re: [Roll] Moving forward with the protocol work JP Vasseur
- Re: [Roll] Moving forward with the protocol work Shoichi Sakane
- Re: [Roll] Moving forward with the protocol work Samita Chakrabarti
- Re: [Roll] Moving forward with the protocol work JP Vasseur
- Re: [Roll] Moving forward with the protocol work edward.j.beroset
- Re: [Roll] Moving forward with the protocol work Mukul Goyal
- Re: [Roll] Moving forward with the protocol work Emmanuel Baccelli
- Re: [Roll] Moving forward with the protocol work Mukul Goyal
- Re: [Roll] Moving forward with the protocol work Zach Shelby
- Re: [Roll] Moving forward with the protocol work Mukul Goyal
- Re: [Roll] Moving forward with the protocol work Jerald.P.Martocci
- Re: [Roll] Moving forward with the protocol work Don Sturek
- Re: [Roll] Moving forward with the protocol work JP Vasseur
- Re: [Roll] Moving forward with the protocol work Julien Abeille (jabeille)
- Re: [Roll] Moving forward with the protocol work Don Sturek
- Re: [Roll] Moving forward with the protocol work Don Sturek
- Re: [Roll] Moving forward with the protocol work Jerald.P.Martocci
- Re: [Roll] Moving forward with the protocol work Don Sturek
- [Roll] P2P discussion [ was RE: Moving forward wi… Pascal Thubert (pthubert)
- Re: [Roll] Moving forward with the protocol work Matthew.Anderson
- [Roll] MUSTing P2P states [was RE: Moving forward… Pascal Thubert (pthubert)
- Re: [Roll] MUSTing P2P states [was RE: Moving for… JP Vasseur
- Re: [Roll] MUSTing P2P states [was RE: Moving for… Anders Brandt
- Re: [Roll] MUSTing P2P states JP Vasseur
- Re: [Roll] Moving forward with the protocol work Jerald.P.Martocci
- Re: [Roll] Moving forward with the protocol work Jerald.P.Martocci
- Re: [Roll] MUSTing P2P states [was RE: Moving for… Don Sturek
- [Roll] UPDATED: Moving forward with the protocol … Don Sturek
- Re: [Roll] Moving forward with the protocol work Jerald.P.Martocci
- [Roll] Determining DADR Contributions Ryusuke Masuoka
- Re: [Roll] Moving forward with the protocol work Zach Shelby
- [Roll] Moving forward with the protocol work Matthew.Anderson
- [Roll] Moving forward with the protocol work M Anand
- Re: [Roll] Moving forward with the protocol work Mischa Dohler
- Re: [Roll] Moving forward with the protocol work dominique.barthel
- Re: [Roll] Moving forward with the protocol work Mukul Goyal
- Re: [Roll] Moving forward with the protocol work Don Sturek
- Re: [Roll] Moving forward with the protocol work Pascal Thubert (pthubert)
- Re: [Roll] Moving forward with the protocol work Mukul Goyal
- Re: [Roll] Moving forward with the protocol work Mukul Goyal
- Re: [Roll] Moving forward with the protocol work Don Sturek
- Re: [Roll] Moving forward with the protocol work Alexandru Petrescu
- Re: [Roll] Moving forward with the protocol work Don Sturek
- Re: [Roll] Moving forward with the protocol work Kris Pister
- Re: [Roll] Moving forward with the protocol work JP Vasseur
- Re: [Roll] Moving forward with the protocol work JP Vasseur
- [Roll] Fwd: Moving forward with the protocol work JP Vasseur
- Re: [Roll] Moving forward with the protocol work JP Vasseur
- Re: [Roll] Moving forward with the protocol work JP Vasseur
- Re: [Roll] Moving forward with the protocol work JP Vasseur
- [Roll] Why a DAG? (was Re: Moving forward with th… Jonathan Hui
- Re: [Roll] Moving forward with the protocol work Jonathan Hui
- Re: [Roll] Moving forward with the protocol work Pete St. Pierre
- [Roll] good vs perfect and best and the rest. was… Pascal Thubert (pthubert)
- Re: [Roll] Determining DADR Contributions JP Vasseur
- Re: [Roll] Why a DAG? (was Re: Moving forward wit… Alexandru Petrescu
- Re: [Roll] Why a DAG? (was Re: Moving forward wit… Jonathan Hui
- Re: [Roll] Moving forward with the protocol work Mukul Goyal
- Re: [Roll] Moving forward with the protocol work JP Vasseur