Subject: Re: [Roll] Moving forward with the protocol work

From: Mukul Goyal <[email-masked]>
Date: Thu, 30 Jul 2009 08:17:45 -0500 (CDT)

Mischa,

>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.

When you say a solution, it seems that you want one particular protocol. I am OK with RPL as a protocol even though it has deficiencies (such as P2P routing). But, the implication of giving it the WG status seems to be that RPL would be the _framework_ on which all future ROLL work would be based. I am not in support of the use of RPL as a framework unless it eliminates its current tight coupling with DAGs (a, rather heavy duty, loop prevention mechanism).  

>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.

I agree. I was surprised to see such heavy emphasis in RPL on loop prevention. It should be possible for an LLN application to use a simple mechanism to deal with loops or decide not to deal with loops at all. RPL does not allow that. With RPL, you have to use DAGs, which is a very restrictive and very heavy duty loop prevention mechanism.

>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.

Absolutely, P2P routing requirement is well within 95 percentile domain. I guess other folks will affirm this. Meeting this requirement is not as difficult as it may seem (even within RPL).

>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 agree there is a concern if the overhead of running IP is worth the benefits.

> I am in favour of adopting draft-dt-roll-rpl-01 as a WG document.

Unfortunately, I can not support such a move at present.

Thanks
Mukul

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: Zach Shelby <[email-masked]>
Date: Thu, 30 Jul 2009 18:02:43 +0300

Hi,

Mukul Goyal wrote:
> When you say a solution, it seems that you want one particular protocol. I am OK with RPL as a protocol even though it has deficiencies (such as 
P2P routing). But, the implication of giving it the WG status seems to 
be that RPL would be the _framework_ on which all future ROLL work would 
be based. I am not in support of the use of RPL as a framework unless it 
eliminates its current tight coupling with DAGs (a, rather heavy duty, 
loop prevention mechanism).

The goal of the WG from my understanding, is to produce *one* protocol 
in the current charter. RPL is definitely suitable as a starting point 
for that protocol (JP said foundation, not framework). I completely 
support this approach.

 From the industry point of view we need a single solution, which 
fulfills application requirements sufficiently and thus can be widely 
deployed commercially.

Regarding loop prevention, so what if RPL does a better job than is 
necessary? Does it break some requirement doing that? If so, we should 
fix it. There are other reasons for using DAGs than just loop prevention.

Zach

-- 
http://www.sensinode.com
http://zachshelby.org - My blog “On the Internet of Things”
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

---

From: "Don Sturek" <[email-masked]>
Date: Thu, 30 Jul 2009 09:43:57 -0700

Hi Mischa and Mukul,

One thing I would like to add are the following 95% quantile issues:
1)  No flooding to establish routes (since we all know this does not scale
very well)
2)  No "order (n)" increase of storage to support routing (where "order(n)"
means we don't have a requirement to maintain route state information that
scales with the number of routing paths a given device supports).

What I would like to see is the following:
1)  Limit/avoid flooding and maintenance of route state information along
the routing path.
2)  Optimize P2P (I think it would be worthwhile to have a separate thread
that just discusses this topic and defines it with respect to the ROLL
effort).  For example, it would be nice to define exactly what we mean by
optimized P2P:   low overhead in the network to set up (no flooding), no
route state storage requirements along the route, minimize route
cost/hop/etc. and here it would be nice to understand our definition.
3)  Scales and meets various data transmission patterns (MP2P, MP2P with
return acknowledgement, P2P)

It would be nice to discuss these design goals with respect to the
requirements we have in place and then evaluate the proposals on the table
in this light.

Don

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mukul Goyal
Sent: Thursday, July 30, 2009 6:18 AM
To: Mischa Dohler
Cc: ROLL WG
Subject: Re: [Roll] Moving forward with the protocol work

Mischa,

When you say a solution, it seems that you want one particular protocol. I
am OK with RPL as a protocol even though it has deficiencies (such as P2P
routing). But, the implication of giving it the WG status seems to be that
RPL would be the _framework_ on which all future ROLL work would be based. I
am not in support of the use of RPL as a framework unless it eliminates its
current tight coupling with DAGs (a, rather heavy duty, loop prevention
mechanism).  

I agree. I was surprised to see such heavy emphasis in RPL on loop
prevention. It should be possible for an LLN application to use a simple
mechanism to deal with loops or decide not to deal with loops at all. RPL
does not allow that. With RPL, you have to use DAGs, which is a very
restrictive and very heavy duty loop prevention mechanism.

Absolutely, P2P routing requirement is well within 95 percentile domain. I
guess other folks will affirm this. Meeting this requirement is not as
difficult as it may seem (even within RPL).

I agree there is a concern if the overhead of running IP is worth the
benefits.

Thanks
Mukul

---

From: [email-masked]
Date: Thu, 30 Jul 2009 15:59:30 -0500

Zach,

When the design team was formed it stated its plan was to develop a core 
routing specification that met the needs of all the requirement 
specifications and then ancillary specifications to meet the specific 
needs for each of the requirements.  RPL as currently written seems 
perfectly suitable for the MP2P requirement, yet not too suitable for P2P 
requirement.  Could we repackage RPL so that its base spec contains only 
the generic routing requirements such as 1) using varied metrics to define 
path preferences, 2) OCP to advertise path strategy and 3) trickle to 
cleanly vary periodic requirements.  Then RPL-1 could be then enhancements 
for MP2P applications and would include the DAG.  This would allow us to 
define a different extension, RPL-2, for P2P requirements that need not be 
DAG based.

JP has promised that if I just shut-up and give the DT some time, they 
will provide a solid P2P solution.  I am willing to do that.  However, I 
would hate to start compromising the MP2P solution to wedge in a 
sub-optimal P2P solution.  Maybe we can have our cake and eat it too if we 
simply repackage the specs a bit.

Jerry

Zach Shelby <[email-masked]> 
Sent by: [email-masked]
07/30/2009 10:02 AM

To
Mukul Goyal <[email-masked]>
cc
ROLL WG <[email-masked]>
Subject
Re: [Roll] Moving forward with the protocol work

Hi,

> When you say a solution, it seems that you want one particular protocol. 
I am OK with RPL as a protocol even though it has deficiencies (such as 

Zach

-- 
http://www.sensinode.com
http://zachshelby.org - My blog ?On the Internet of Things?
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

---

From: "Ryusuke Masuoka" <[email-masked]>
Date: Thu, 30 Jul 2009 17:21:21 -0400

Hi, ROLL WG members, 

In order to move ahead and for us to determine what we/DADR can
contribute, we (Fujitsu) would like to do the following.

At the ROLL meeting, we realized that many people are interested in
802.15.4 radio. Our current implementation is on 802.11b radio (1
Mbps) and two wireless characteristics are different. We thought that
many ROLL members could not determine how good DADR would be when it
is applied to 802.15.4 radio. In that regard: 

(1) We will provide PER (packet error rate) and other wireless
  characteristics for both 802.11b (which we already have) and 802.15.4
  radios in a couple of weeks.

(2) We will share our DADR 802.15.4 radio implementation experiment
  results by the end of August or in early September.

  It would be a rather small (50 nodes or so) and preliminary with
  experiment assumptions, (average) hops, data reachability, etc.  (We
  plan to do a larger experiments (in the order of hundreds of nodes),
  but it will be somewhat later.)

  As this is done as a part of system test for customer deployment, we
  are not sure we can accommodate them all, but please let us know
  what kinds of things/conditions/assumptions we should
  incorporate/consider/make in this experiment. We would appreciate
  your input very much.
 
We also plan to see which LLN requirements DADR meets or not, according
to: 

  Overview of Existing Routing Protocols for Low Power and Lossy Networks
  draft-ietf-roll-protocols-survey-07

so that we can better determine which parts of DADR are useful or not. 

We will try to be as fair as possible. However, if someone can
volunteer to do this, that would be great as we can get a third-party
evaluation, we would appreciate it very much and we will support the
person/group with the information necessary. (... but I am afraid that
everyone other than us is too busy for this.)

Regards,

Ryu

---

From: Zach Shelby <[email-masked]>
Date: Fri, 31 Jul 2009 00:55:30 +0300

Jerry,

[email-masked] wrote:
> perfectly suitable for the MP2P requirement, yet not too suitable for 
> P2P requirement.  Could we repackage RPL so that its base spec contains 
> only the generic routing requirements such as 1) using varied metrics to 
> define path preferences, 2) OCP to advertise path strategy and 3) 
> trickle to cleanly vary periodic requirements.  Then RPL-1 could be then 
> enhancements for MP2P applications and would include the DAG.  This 
> would allow us to define a different extension, RPL-2, for P2P 
> requirements that need not be DAG based.

We all agree that RPL currently only contains basic P2P support using 
the DV state built up on the DAG. I also agree with you that the wording 
on keeping DV state in routers (within memory constraints) should be 
fixed (easy). There is definitely consensus that the next version needs 
a solid P2P mechanism. There is no reason that an additional P2P feature 
would be suboptimal with the DAG - I see them as being complimentary.

> sub-optimal P2P solution.  Maybe we can have our cake and eat it too if 
> we simply repackage the specs a bit.

This is just -01 of this draft, so JP is right ;-) The DT was clear this 
is an early draft and that P2P is coming. So... on the P2P front, it 
would be great to see contributions to the WG on how to include suitable 
P2P support to RPL. The thing about a WG document - is that we work 
together on it.

Zach

> Jerry
> 
> 
> 
> 
> *Zach Shelby <[email-masked]>*
>  > When you say a solution, it seems that you want one particular 
> protocol. I am OK with RPL as a protocol even though it has deficiencies 
> (such as

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain 
legally privileged information. If you are not the intended recipient, 
please contact the sender and delete the e-mail from your system without 
producing, distributing or retaining copies thereof.

---

From: JP Vasseur <[email-masked]>
Date: Fri, 31 Jul 2009 18:09:11 +0200

On Jul 30, 2009, at 11:55 PM, Zach Shelby wrote:

>> When the design team was formed it stated its plan was to develop a  
>> core routing specification that met the needs of all the  
>> requirement specifications and then ancillary specifications to  
>> meet the specific needs for each of the requirements.  RPL as  
>> currently written seems perfectly suitable for the MP2P  
>> requirement, yet not too suitable for P2P requirement.  Could we  
>> repackage RPL so that its base spec contains only the generic  
>> routing requirements such as 1) using varied metrics to define path  
>> preferences, 2) OCP to advertise path strategy and 3) trickle to  
>> cleanly vary periodic requirements.  Then RPL-1 could be then  
> We all agree that RPL currently only contains basic P2P support  
> using the DV state built up on the DAG. I also agree with you that  
> the wording on keeping DV state in routers (within memory  
> constraints) should be fixed (easy). There is definitely consensus  
> that the next version needs a solid P2P mechanism. There is no  
> reason that an additional P2P feature would be suboptimal with the  
> DAG - I see them as being complimentary.

Correct.

>
>> JP has promised that if I just shut-up and give the DT some time,  
>> they will provide a solid P2P solution.  I am willing to do that.   
>> However, I would hate to start compromising the MP2P solution to  
>> wedge in a sub-optimal P2P solution.  Maybe we can have our cake  
>> and eat it too if we simply repackage the specs a bit.
>
> This is just -01 of this draft, so JP is right ;-) The DT was clear  
> this is an early draft and that P2P is coming. So... on the P2P  
> front, it would be great to see contributions to the WG on how to  
> include suitable P2P support to RPL. The thing about a WG document -  
> is that we work together on it.
>

This is perfectly correct.

JP.

>> protocol. I am OK with RPL as a protocol even though it has  
>> deficiencies (such as
> This e-mail and all attached material are confidential and may  
> contain legally privileged information. If you are not the intended  
> recipient, please contact the sender and delete the e-mail from your  
> system without producing, distributing or retaining copies thereof.

---

From: "Pete St. Pierre" <[email-masked]>
Date: Fri, 31 Jul 2009 12:11:54 -0700

ROLL-ers -

I'd also like to throw my support behind accepting the RPL draft as a  
WG document.  It is very clearly an -01 draft and has areas that have  
been acknowledged by the DT and many on this list as needing work.

The fact that there has already been a wealth of discussion within  
this list of how to address these deficiencies gives me the feeling  
there is pretty wide felt support for the basic design represented  
within the draft.

When the DT was formed, there was some concern expressed on the list  
that a small group was being "sub-chartered" to go work on the  
problem.  Now that the individual submission document has been  
completed by this "tiger team", we've had the opportunity to review  
the work as a group.  Thanks to Pascal and Jonathan for the  
presentation this week at the WG meeting.

Now that the initial DT has completed a first pass, I think the time  
is right to close up work on the DT mailing list and move forward as a  
group, continuing the discussions on this list, with appropriate  
subject lines as JP has suggested/requested.

I also don't believe that this closes the door on a second protocol  
that may be weighted toward addressing the P2P scenario more  
efficiently.  However, think we need to fully explore 1 solution  
before we become fractured and run off in too many different directions.

Clearly it's the responsibility of JP and David as co-chairs to decide  
where the consensus lies, but I look forward to work moving forward  
quickly on at least one solution to address the routing needs required  
by this unique class of applications.

Just my $.02 (or very small fraction of a Kroner)
...Pete