Subject: [Roll] [roll] #24: Discussion P2P

From: "roll issue tracker" <[email-masked]>
Date: Mon, 08 Mar 2010 10:11:27 -0000

#24: Discussion  P2P
-----------------------------------+----------------------------------------
 Reporter:  jpv@…                  |       Owner:  abr@…          
     Type:  task                   |      Status:  new            
 Priority:  major                  |   Milestone:                 
Component:  building-routing-reqs  |     Version:                 
 Severity:  Candidate WG Document  |    Keywords:                 
-----------------------------------+----------------------------------------
 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
 =============

 We need some reactive mechanism to reach lamps before the user decides
 to sue our companies.
 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
 _____________________________________

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/24>
roll <http://tools.ietf.org/wg/roll/>

---

From: "roll issue tracker" <[email-masked]>
Date: Mon, 08 Mar 2010 10:13:56 -0000

#24: Discussion  P2P
Component:  rpl                    |     Version:                 
Changes (by jpv@…):

  * component:  building-routing-reqs => rpl

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/24#comment:1>
roll <http://tools.ietf.org/wg/roll/>