Subject: Re: [Roll] Roll Digest, Vol 26, Issue 10

From: Yoav Ben-Yehezkel <[email-masked]>
Date: Mon, 8 Mar 2010 10:39:17 +0200

Hi,

I agree in general that P2P needs to be handled better for time critical
applications and that time critical applications require either on-demand
routing or on-demand routing repair mechanisms (if proactive routing fails
there's no time to wait for it to be fixed eventually).

It would also be helpful if ROLL defines a heuristic for joining a DODAG
based on an applicative criteria (whether the root is interesting to the
application)? For example, a bulb will be a root and switches operating
the bulb will be a leaf nodes in that DODAG. That has a good chance of
working in most cases and significantly reduces the amounts of floods
required.

Thanks,
Yoav

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
<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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.ietf.org/mail-archive/web/roll/attachments/20100308/8c78866f/a
ttachment.htm>

------------------------------

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

End of Roll Digest, Vol 26, Issue 10
************************************

---

From: Yoav Ben-Yehezkel <[email-masked]>
Date: Mon, 8 Mar 2010 10:48:16 +0200

Sorry about bad subject in previous email.

This is in response to:
Date: Mon, 8 Mar 2010 09:19:32 +0100
From: "Anders Brandt" <[email-masked]>
Subject: [Roll] P2P performance with current RPL proposal
To: "ROLL WG" <[email-masked]>

Thanks,
Yoav

-----Original Message-----
From: Yoav Ben-Yehezkel [mailto:[email-masked]]
Sent: Monday, March 08, 2010 10:39 AM
To: [email-masked]'
Cc: [email-masked]'
Subject: RE: Roll Digest, Vol 26, Issue 10

Hi,

Thanks,
Yoav

Hello

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

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

Thanks,
  Anders