Subject: Re: [Roll] P2P performance with current RPL proposal

From: Mukul Goyal <[email-masked]>
Date: Mon, 8 Mar 2010 16:34:57 -0600 (CST)

We have done a performance comparison between P2P routing along a DAG versus shortest path routing:

 http://www.cs.uwm.edu/~mukul/draft-goyal-roll-p2p-performance-00.pdf

These results clearly indicate that the average and the worst-case performance of DAG-based P2P routing is particularly bad for source-destination pairs that are closeby in terms of shortest path routing.

So, TTL-limited flooding to discover shortest paths to nearby destinations definitely makes sense.  

Thanks
Mukul

----- Original Message -----
From: "Kris Pister" <[email-masked]>
To: "Anders Brandt" <[email-masked]>
Cc: "ROLL WG" <[email-masked]>
Sent: Monday, March 8, 2010 1:44:56 PM GMT -06:00 US/Canada Central
Subject: Re: [Roll] P2P performance with current RPL proposal

Anders - if we take JP's suggestion to make The Lamp a DODAG root, and take Phoebus' recommendation that we use path diversity to improve end-to-end reliability, do you see a chance of success? 
In my experience, with diverse paths and order-minutes updates you get extremely high reliability. 

I have no aversion to TTL-limited floods as a part of a solution either.  I'm open to ideas on how to bring those in as (presumably infrequently used) options. 

ksjp 

Anders Brandt wrote: 

Hello 
  
I would like to probe the temperature of the WG on using DAOs to 
support P2P. 
  
The building and home application spaces (and maybe others) have 
a few clearly defined requirements. 
It is not obvious to me how the current RPL proposal (cRPLp) can 
satisfy those requirements: 

In both cases it is the worst case scenario that hurts: 

P2P routing inside the PAN 
========================== 
cRPLp has no way of routing inside the PAN if you need more than 
one repeater. cRPLp has to go all the way to the top (maybe 4 hops up) 
and down again (maybe 4 hops down) to get just 2 hops to the side. 
  
The consequence is high latency and high levels of background noise 
for nodes just outside the direct radio range. 
At the same time  the risk of meeting a failing link is 4 times higher => 
latency may be much more than 4 times larger. 
  
Latency may sound like a minor issue but it actually translates directly 
into lower battery lifetime. In the above (very realistic) example, 
the battery lifetime is reduced to 25% of what it should be. 
  
We have lots of battery devices sending into the network: 
* PIR sensors turning on lights 
* Door locks sending alarms 
* Door/window sensors starting chimes 

* Smoke sensors triggering an alarm system 

  
Response time 
============= 
The latency issue is important. 
When a user (real human being) presses a light button the user expects 
the light to turn on. 
cRPLp proposes that nodes in the tree periodically advertises their 
presence using DAOs. 
The periodicity is a real beast: 
Thanks to Trickle, the rate of updates in a (apparently) stable network 
is low. This is good since it leaves bandwidth for data. 
But it is not good if existing routes to my lamp fail and I do not get 
new routes to my lamp until it decides to send out a new DAO. 
My user will (with a good reason) not tolerate waiting for minutes for 
the light to turn on. 
  
I have met two arguments to counter this concern: 
  
A1: Well, your lamp can always send a DAO when it detects a problem. 
  My answer: 
  True, except that my lamp does not intend to send anything 
  so it will never experience any problems from its side of the network. 
  
A2: Well, you can increase the DAO rate to sub-second updates. 
  My answer: 
  Oh no. I get a very high degree of management traffic which 
  limits my available bandwidth, increases the risk of collisions and 
  even run the risk of violating EU legislation requiring me to only 
  transmit in less than 1% of the time: 
  http://focus.ti.com/lit/an/swra048/swra048.pdf 
  868 - 868.6 MHz: <1% 
  
  Reactiveness is hard to achieve via polling. 

If you agree that this seems to be critical issues please raise your 
voice on the list. 
  
Going forward 
============= 
  
W e need some reactive mechanism to reach lamps before the user decides 
to sue our compan ies. 
So is this possible? I think so. 

Existing commercial (non-IP) solutions are capable of re-routing quickly 
if they really have to. 
  
Let me try scoping the requirements to a potential solution: 
(no different from the req. docs for home and building) 
  
* P2P routing in any direction independent of the tree. 
  
* On-demand P2P route discovery if requested by a real-time critical app. 
  Data collection apps may be able to just wait for the next DAO update. 
  
* Limited range of discovery mechanism: max 4 repeaters. 
  A TTL field may limit the scope of the repeaters. 
  
* Suboptimal routing and traffic bursts are accepted in exchange 
  for quick route repair. But only as an exception. 

Just as an example, one existing home control technology uses a 
(source routing) variant of AODV for quick route repair. 
Nothing comes for free. The price is flooding - but not just flooding: 
Managed flooding using a distributed algorithm running in all 
participating nodes. 
The algorithm dampens the flooding in a time, volume and range perspective. 
Some similar mechanism could be built into RPL for quick route repair. 

If  anyone have alternative proposals , please bring it to the list. 
Now is the time. 

Thanks, 
  Anders 
_______________________________________________
Roll mailing list [email-masked] https://www.ietf.org/mailman/listinfo/roll 
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: Mukul Goyal <[email-masked]>
Date: Mon, 8 Mar 2010 16:49:37 -0600 (CST)

Working group may also want to seriously consider the possibility of modifying its charter to allow a distance-vector protocol with controlled flooding in addition to RPL.

May I re-present one such protocol:

http://www.cs.uwm.edu/~mukul/draft-goyal-roll-dv-01.txt

Distance vector protocols are as old as the internet. So, it is not some thing that people dont have operational experience with.

Thanks
Mukul 
----- Original Message -----
From: "Mukul Goyal" <[email-masked]>
To: "Kris Pister" <[email-masked]>
Cc: "ROLL WG" <[email-masked]>
Sent: Monday, March 8, 2010 4:34:57 PM GMT -06:00 US/Canada Central
Subject: Re: [Roll] P2P performance with current RPL proposal

Thanks
Mukul

----- Original Message -----
From: "Kris Pister" <[email-masked]>
To: "Anders Brandt" <[email-masked]>
Cc: "ROLL WG" <[email-masked]>
Sent: Monday, March 8, 2010 1:44:56 PM GMT -06:00 US/Canada Central
Subject: Re: [Roll] P2P performance with current RPL proposal

ksjp 

Anders Brandt wrote: 

Hello 

  

  
  
Response time 
============= 

  

  
  
Going forward 
============= 

  

  

  
Thanks, 
  Anders