Subject: [Roll] Suggestions for RPL Simplificiation

From: Tim Winter <[email-masked]>
Date: Fri, 25 Sep 2009 10:08:53 -0400

WG,

At the interim meeting we plan to address the issue of simplifying RPL, both in
presentation and in the protocol itself.

In this scope, we have come up with the following list:

  - Complexity in presentation
      + (reworking the draft)

  - Complexity in protocol
      + Multi-DAG
      + Incremental Complexity
          * (DAG Inwards -> DAG+DAO -> Multi-DAG)
          * (Rank Increment 1..16)
          * (Asymmetrical Links)
      + Timers

WG, implementors- what else would you like to see on this list?  Please append
your ideas/concerns.

Thanks,

- RPL Authors

---

From: Mukul Goyal <[email-masked]>
Date: Fri, 25 Sep 2009 09:48:11 -0500 (CDT)

I guess one obvious issue raised again recently: why have loop avoidance as integral part of the basic protocol and not as add-on. If loop avoidance becomes add-on feature, there is no need for DAG ranks and the basic protocol would be quite simple.

Thanks
Mukul
----- Original Message -----
From: "Tim Winter" <[email-masked]>
To: "ROLL WG" <[email-masked]>
Sent: Friday, September 25, 2009 9:08:53 AM GMT -06:00 US/Canada Central
Subject: [Roll] Suggestions for RPL Simplificiation

WG,

  - Complexity in protocol
      + Multi-DAG
      + Incremental Complexity

Thanks,

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

---

From: Richard Kelsey <[email-masked]>
Date: Fri, 25 Sep 2009 11:27:29 -0400

Date: Fri, 25 Sep 2009 09:48:11 -0500 (CDT)
   From: Mukul Goyal <[email-masked]>

   I guess one obvious issue raised again recently: why have loop
   avoidance as integral part of the basic protocol and not as add-on. If
   loop avoidance becomes add-on feature, there is no need for DAG ranks
   and the basic protocol would be quite simple.

It seems to me that loop avoidance is the core utility
provided by the base RA-DIO.  If you take that away there
isn't much left.

That being said, could the OCP (Object Code Point) be
allowed to overrule the DAGRank restrictions?  The current
DAGRank restrictions could be made an option, perhaps one
indicated by a flag bit in the RA-DIO or in the OCP value.

                           -Richard Kelsey

---

From: Mukul Goyal <[email-masked]>
Date: Fri, 25 Sep 2009 10:36:51 -0500 (CDT)

>provided by the base RA-DIO.  If you take that away there

I would think that core utility of DIO is to carry node's path cost to DAG root.

Thanks
Mukul
 
----- Original Message -----
From: "Richard Kelsey" <[email-masked]>
To: "Mukul Goyal" <[email-masked]>
Cc: [email-masked], [email-masked]
Sent: Friday, September 25, 2009 10:27:29 AM GMT -06:00 US/Canada Central
Subject: Re: [Roll] Suggestions for RPL Simplificiation

                           -Richard Kelsey

---

From: Mukul Goyal <[email-masked]>
Date: Fri, 25 Sep 2009 10:39:11 -0500 (CDT)

This is adding more complexity (rather than simplifying things).

Thanks
Mukul

                           -Richard Kelsey

---

From: Richard Kelsey <[email-masked]>
Date: Fri, 25 Sep 2009 12:02:47 -0400

Date: Fri, 25 Sep 2009 10:08:53 -0400
   From: Tim Winter <[email-masked]>

   WG,

     - Complexity in protocol
         + Multi-DAG
         + Incremental Complexity

I don't understand the ordering:

Multi-DAG and DAG+DAO seem orthogonal, in that there
is no dependence between them that I can see.

Here is my own list of possible simplifications:

 - Move DAOs out of the core protocol.  They are not always
   needed and there are alternatives that are better suited
   to some networks (record route + source route, for
   example).  I think that the DAO can itself be simpler,
   but I would rather move it out and then simplify it.

 - Remove some of the bells and whistles from RA-DIO:
    - DAGPreference
    - BootTimeRandom
    - PathDigest
    - NodePreference
   While these are all useful in some situations, I don't
   think that there is a strong enough case for having them
   in the core.  They seem more like nice-to-haves than
   must-haves.

 - I am dubious about section 5.7 (Candidate DAG Parent
   States and Stability).  In the past I have always
   maintained loop-free DAGs using only the sequence number
   and DAGRank.  Are the optimizations described in section
   5.7 worth the extra complexity?  Waiting until the
   sequence number changes to move down within a DAG
   may sometimes be slow, but the rule can be described
   in a single sentence.
                                -Richard Kelsey

---

From: Richard Kelsey <[email-masked]>
Date: Fri, 25 Sep 2009 12:13:38 -0400

Date: Fri, 25 Sep 2009 10:39:11 -0500 (CDT)
   From: Mukul Goyal <[email-masked]>

   RK>That being said, could the OCP (Object Code Point) be
   RK>allowed to overrule the DAGRank restrictions?  The current
   RK>DAGRank restrictions could be made an option, perhaps one
   RK>indicated by a flag bit in the RA-DIO or in the OCP value.

I was suggesting two separate things:
 1) Allowing the OCP to overrule the DAGRank restrictions.
 2) Indicating whether the OCP did so by setting a flag in
    the RA-DIO.
Are you saying that both of these add complexity, or just
that (2) does?  I don't see that (1) adds any complexity,
as the meaning of the DAGRank is completely in the hands
of the OCP already.
                               -Richard Kelsey

---

From: [email-masked]
Date: Fri, 25 Sep 2009 11:21:11 -0500

RPL-01/02 is no longer clear to me how much of its complexity would simply 
drop off if the application was simplified.  That is, if I was satisfied 
with a single DAG, a single LBR and a single cost metric on a small LLN, 
would much of the complexity melt away?  Unfortunately, my feeling is no. 
It seems like we have 'baked in' the complexity into the specification. 
Maybe the DT could analyze this. 

The spec calls for the RPL nucleus to be the intersection of the 
requirements; then extensions to meet specific requirements.  This hasn't 
happened.  This makes us all look at the overall spec is being overloaded. 
 We should consider repackaging RPL as originally planned.  Then a given 
application would only see the functionality it requires.

Food for thought.

Jerry

Tim Winter <[email-masked]> 
Sent by: [email-masked]
09/25/2009 09:09 AM

To
ROLL WG <[email-masked]>
cc

Subject
[Roll] Suggestions for RPL Simplificiation

WG,

At the interim meeting we plan to address the issue of simplifying RPL, 
both in
presentation and in the protocol itself.

  - Complexity in protocol
      + Multi-DAG
      + Incremental Complexity

WG, implementors- what else would you like to see on this list?  Please 
append
your ideas/concerns.

Thanks,

- RPL Authors

---

From: Mukul Goyal <[email-masked]>
Date: Fri, 25 Sep 2009 11:34:45 -0500 (CDT)

Richard

>as the meaning of the DAGRank is completely in the hands

You seem to like loop avoidance as basic protocol feature but also want in the same basic protocol a facility to override loop avoidance rules. That seems complex to me. I think that it will be better to not have loop avoidance in the basic protocol at all.

Thanks
Mukul

---

From: [email-masked]
Date: Fri, 25 Sep 2009 11:35:15 -0500

I agree with Mukal.

DAGs are great loop-less structures for collection networks (i.e. MP2P). 
They are not so great for control networks (i.e. P2P).  Why can't DAGs be 
an extension for MP2P solutions leaving a simpler solution for P2P?

Jerry

Mukul Goyal <[email-masked]> 
Sent by: [email-masked]
09/25/2009 10:37 AM

To
Richard Kelsey <[email-masked]>
cc
[email-masked]
Subject
Re: [Roll] Suggestions for RPL Simplificiation

>provided by the base RA-DIO.  If you take that away there

I would think that core utility of DIO is to carry node's path cost to DAG 
root.

Thanks
Mukul
 
----- Original Message -----
From: "Richard Kelsey" <[email-masked]>
To: "Mukul Goyal" <[email-masked]>
Cc: [email-masked], [email-masked]
Sent: Friday, September 25, 2009 10:27:29 AM GMT -06:00 US/Canada Central
Subject: Re: [Roll] Suggestions for RPL Simplificiation

                           -Richard Kelsey

---

From: Richard Kelsey <[email-masked]>
Date: Fri, 25 Sep 2009 13:04:02 -0400

Mukul,

   Date: Fri, 25 Sep 2009 11:34:45 -0500 (CDT)
   From: Mukul Goyal <[email-masked]>

   You seem to like loop avoidance as basic protocol feature but also
   want in the same basic protocol a facility to override loop avoidance
   rules. That seems complex to me. I think that it will be better to not
   have loop avoidance in the basic protocol at all.

Personally, I like like loop avoidance being a basic
protocol feature.  I understand that you and others would
prefer that it not be.  In the hope of finding a compromise
I was suggesting that it be included in the core in such a
way that those that did not want to use it could ignore it
entirely.

I am much more concerned with the complexity of a simple
application built using RPL than with the complexity of the
specification itself.  Having optional features increases
the complexity of the document but does not affect
applications that do not use them.  If the goal is a
simple specification, then yes, making something optional
does increase the complexity.
                                  -Richard Kelsey

---

From: Geoff Mulligan <[email-masked]>
Date: Sun, 27 Sep 2009 08:55:15 -0600

I agree with Jerry and Mukul.  This seems to be getting overly complex.
It is great that at the interim you are going to look at reducing the
complexity.

Since I won't be there, please do not forget that all networks are not
collection networks.  The use cases showed the need for control networks
(which are generally P2P).

RPL seems to be so focused on collection networks that we are losing
sight on something that will work for control and p2p networks.

If DAGs, loop avoidance, and the rest don't provide a solution for P2P
then we will need another protocol for these control networks.

Jerry has said this repeatedly, but it seems to keep getting
concatenated to /dev/null. 

	geoff

On Fri, 2009-09-25 at 11:35 -0500, [email-masked] wrote:
> 
> I agree with Mukal. 
> 
> DAGs are great loop-less structures for collection networks (i.e.
> MP2P).  They are not so great for control networks (i.e. P2P).  Why
> can't DAGs be an extension for MP2P solutions leaving a simpler
> solution for P2P? 
> 
> Jerry 
> 
> 
> 
> 
> 
> Re: [Roll]
> Suggestions for
> RPL
> Simplificiation

---

From: JP Vasseur <[email-masked]>
Date: Mon, 28 Sep 2009 12:06:33 +0200

Hi Richard,

> does increase the complexity.

Yes I share you analysis. The goal is not to have a simple  
specification but a simple protocol
where modules/options/features would be used, as needed. We had also  
comments on the
number of pages ... note that a good number of pages are "Protocol  
Overview" and Appendices.

I also believe that loop avoidance should be part of the core  
specification but there is plenty
of room for simplification such as the Multi-DAG issues, as also  
pointed out by Thomas.

Please, all continue to drop suggestion, we will then make a summary  
of the proposals in order
to start freezing the spec.

Thanks.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Mon, 28 Sep 2009 12:13:44 +0200

Hi Richard,

> is no dependence between them that I can see.

They are orthogonal.

>  but I would rather move it out and then simplify it.

Well, my take on this is that DAO are really needed in many situations,
thus a good reason IMO for keeping it as part of the core specification.
Sill we could simplify several of the associated "features" and simplify
it.

>  in the core.  They seem more like nice-to-haves than

Agree. The RA-DIO message structure is flexible enough for these
options to be added as needed.

>  may sometimes be slow, but the rule can be described

Not sure we could remove this, it is more of a necessary feature than
really an optimization ...

Cheers.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Mon, 28 Sep 2009 12:16:29 +0200

Hi,

> concatenated to /dev/null.

Just to make sure that we're on the same page. RPL is a not collection  
network routing
protocol. It does fully support P2P and these applications will not  
left on the side. This
is why we added multicast NA-DAO in rev-02.

JP.

>> I would think that core utility of DIO is to carry node's path cost  
>> to
>> DAG root.
>>
>> Thanks
>> Mukul
>>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 28 Sep 2009 14:23:57 +0200

>> is no dependence between them that I can see.

The point was incremental complexity. DAG inwards for only default route
inwards is easy. 
Add DAO and it gets more complex, mostly if you want multipath outwards
as well.
MultiDAG increases the complexity to a new degree, as illustrated in
some threads already.

Where do we draw the line?

Pascal

---

From: Richard Kelsey <[email-masked]>
Date: Mon, 28 Sep 2009 12:19:14 -0400

Date: Mon, 28 Sep 2009 14:23:57 +0200
   From: "Pascal Thubert (pthubert)" <[email-masked]>

   The point was incremental complexity. DAG inwards for
   only default route inwards is easy.

   Add DAO and it gets more complex, mostly if you want
   multipath outwards as well.

   MultiDAG increases the complexity to a new degree, as
   illustrated in some threads already.

Pascal,

The problems of MultiDAG are inherent in DAO as well.
The same situations arise for DAG+DAO as for DAG+DAG.

Suppose we have the following sub-DAG with A as the
root of the sub-DAG.  D has two parents, of which
B is the preferred parent.

    A
   / \
  B   C
   \ /
    D
    |
    E

>From DAOs:
  -A knows that B is the next hop to E
  -B knows that D is the next hop to E

Then D switches to C as its preferred parent and E goes off
somewhere else.  No DAG ranks change and the DAO-derived
information on A and B is still there.  (D does send a new
DAO, including a no-DAO for E, but it sents it to C.  A
receives the no-DAO for E from C, but C is not A's next hop
for E, so this has no effect.)

When A sends a packet to E it goes around the loop
A->B->D->C->A.  A and B use their DAO-derived next hops to
to route the packet to D.  D and C use their default routes
send the packet back up to A again.

DAO is not simpler than multi-DAG.

                              -Richard Kelsey

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 28 Sep 2009 18:54:35 +0200

Hi Richard:

This is a different loop than what multiple DAG will cause. 
Multiple DAG create loops between DAGs that can only be solved by
adding/comparing metrics between DAGs. 

There's no such a thing inside a single DAG. Only un-matching states
waiting for resolution.

That specific loop is similar though more complex than the traditional
~DAO loss.

The resolution happens when B times out DAOs from E, as if a ~DAO from D
was lost.
In the meantime we could use a loop detection of some form... 

Here, a simple RPF at D will find that it receives a packet from a node
that could be the next hop for that packet, so the traditional CTP
detection applies, as for simpler ~DAO loss.

Cheers,  

Pascal

>-----Original Message-----
>From: Richard Kelsey [mailto:[email-masked]]
>Sent: lundi 28 septembre 2009 18:19
>To: Pascal Thubert (pthubert)
>Cc: JP Vasseur (jvasseur); [email-masked]

---

From: Emmanuel Baccelli <[email-masked]>
Date: Mon, 28 Sep 2009 19:25:52 +0200

Hi all,

up until now the RPL draft was still in its "rapid initial growth" phase,
and kept on adding elements of text and structure. It's fine, but now we
have come to a point where it is important to take a step back, and identify
the current backbone of the specification, with three purposes in mind:

- eliminate redundancies and text that does not belong in a protocol
specification document
- spell out what RPL does
- spell out what RPL does not

In my opinion, such an approach is necessary now, in order to get to a
specification that can be implemented and successfully tested for
interoperability soon. These steps are also crucial in determining whether
any companion "building blocks" are needed to address some left-out core
requirements.

If we do not make this an effort now, ending up with a bloated and
issue-prone specification 4 months down the line (when we submit to the
IESG), has a probability that is rather high.

If those who have been vocal about simplifying the RPL draft meant something
along the above lines, then I totally agree with them, and I hope that we
can significantly progress in this direction at the Interim meeting in
Geneva this week.

Cheers,
Emmanuel

---

From: JP Vasseur <[email-masked]>
Date: Mon, 28 Sep 2009 20:05:34 +0200

Hi Emmanuel,

On Sep 28, 2009, at 7:25 PM, Emmanuel Baccelli wrote:

> Hi all,
>
> up until now the RPL draft was still in its "rapid initial growth"  
> phase, and kept on adding elements of text and structure. It's fine,  
> but now we have come to a point where it is important to take a step  
> back, and identify the current backbone of the specification, with  
> three purposes in mind:
>
> In my opinion, such an approach is necessary now, in order to get to  
> a specification that can be implemented and successfully tested for  
> interoperability soon. These steps are also crucial in determining  
> whether any companion "building blocks" are needed to address some  
> left-out core requirements.
>

This is 100% in line with the "proposed next steps" email that I sent  
out.
See all the emails on the subject matter.

> issue-prone specification 4 months down the line (when we submit to  
> the IESG), has a probability that is rather high.
>
> If those who have been vocal about simplifying the RPL draft meant  
> something along the above lines, then I totally agree with them, and  
> I hope that we can significantly progress in this direction at the  
> Interim meeting in Geneva this week.
>

Excellent, thanks Emmanuel.

JP.

> Cheers,
> Emmanuel
>
>
>
>
>
>
>
>
>
>
>
> On Mon, Sep 28, 2009 at 2:23 PM, Pascal Thubert (pthubert) <[email-masked] 
> > wrote:
> >>    - Complexity in protocol
> >>        + Multi-DAG
> >>        + Incremental Complexity