Re: [Roll] MUSTing P2P states

[JP Vasseur <[e-mail]>]

On Jul 30, 2009, at 7:53 PM, Anders Brandt wrote:

> comment inline ...
>
> Cheers,
>   Anders
>
> Fra: [e-mail] på vegne af Pascal Thubert (pthubert)
> Sendt: to 30-07-2009 19:29
> Til: [e-mail]; [e-mail]
> Cc: ROLL WG; [e-mail]
> Emne: [Roll] MUSTing P2P states [was RE: Moving forward with the  
> protocolwork]
>
> 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.
>
> ABR> But will a smart product have access to the tools needed to  
> determine some transit nodes
>        and build some (more optimal) source routes to avoid having  
> to walk all the way to the top?
>        I agree with Jerry that battery life time will be severely  
> affected if not having some (relatively)
>        direct connections between sensor and controller. This also  
> applies to the home control domain.

(co-chair hat off). Completely agreeing and again this is clearly  
spelled out in the requirements documents.

>
> 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: [e-mail] [mailto:[e-mail]] On Behalf  
> Of Don Sturek
> Sent: jeudi 30 juillet 2009 19:00
> To: [e-mail]
> Cc: 'ROLL WG'; [e-mail]
> 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: [e-mail] [mailto:[e-mail]]
> Sent: Thursday, July 30, 2009 9:44 AM
> To: [e-mail]
> Cc: 'Mischa Dohler'; 'ROLL WG'; [e-mail]
> 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" <[e-mail]>
> 07/30/2009 11:12 AM
>
> Please respond to
> <[e-mail]>
> To
> <[e-mail]>, "'Mischa Dohler'" <[e-mail]>
> cc
> "'ROLL WG'" <[e-mail]>, <[e-mail]>
> 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: [e-mail] [mailto:[e-mail]] On Behalf  
> Of [e-mail]
> Sent: Thursday, July 30, 2009 8:58 AM
> To: Mischa Dohler
> Cc: ROLL WG; [e-mail]
> 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 <[e-mail]>
> Sent by: [e-mail]
> 07/29/2009 04:18 PM
>
>
> To
> JP Vasseur <[e-mail]>
> cc
> ROLL WG <[e-mail]>
> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/roll
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
>
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll