Re: [Roll] Moving forward with the protocol work

[[e-mail]]

I may have misread the draft myself!!!  I saw nothing in the draft that 
mandates that a node provides downward links to its sub-DAG.  It said it 
optional could, it didn't say it must, not even for the LBR.  Hence p2p 
communication seems to be based only on if a node higher in the DAG is 
gracious enough to help.  I too would like to hear from the DT on this.  I 
submitted it as one of my review comments.

Frankly, (I know I am preciously close to being blasphemous now) I have 
not seen flooding the network as a big issue in our current 
implementations.  I would much prefer an algorithm that does not require 
broadcasts.  However, to date I have seen nothing that tells me a 
asynchronous broadcast needed when new route discovery is required is any 
worse than constant 1-hop RAs, DIOs and DAOs on a periodic basis by every 
node.  Again, keep in mind that my PANS only need to have 250 nodes.

Again, as i stated much of the HVAC control in a building can live with 
additional latencies.  If someone resets the temp sensor in a room it's 
not imperative that the A/C gets actuated immediately.  However, this is 
not true for lighting.  If someone turns on the lights, they need the 
lights to kick on in msecs, not seconds.  Same is true for Smoke and Fire 
control.

In the commercial world we have been deploying wired 
sensor/actuator/controller networks for 40 years.  The devices on these 
networks were completely accessible to all other devices.  If I sent a 
message to a device, it was deterministic how long I should wait around 
for a reply.  If I needed to broadcast, I could broadcast.  This network 
had all the same accoutrements as other enterprise networks.  The packets 
were smaller, the security was thinner and the speed was slower; but 
overall connectivity was the same.  As we move toward WSN, we need the 
same communication flexibility.

I apologize to the WG for this continued diatribe.  I am really not trying 
to throw a monkey wrench into the works. 

Jerry






"Don Sturek" <[e-mail]> 
07/30/2009 12:00 PM
Please respond to
<[e-mail]>


To
<[e-mail]>
cc
"'Mischa Dohler'" <[e-mail]>, "'ROLL WG'" <[e-mail]>, 
<[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