Re: [Roll] RPL Design Questions

[Philip Levis <pal at cs.stanford.edu>]

On Oct 7, 2009, at 3:43 PM, Tim Winter wrote:

>   WG,
>
>   As discussed at the interim meeting, implementer feedback has
>   indicated that the RPL protocol as proposed appears complex, both in
>   description and actual FSM.
>
>   Our plan of action is to, by end of month, deliver a -04 that will
>   contain actual (non-editorial) changes.  The intent of this mail is
>   a poll over a period of 2 weeks, to help design the functional
>   changes.
>
>   In this spirit, we would like the WG to work on the following
>   questions:
>
>   Question A:  Should RPL make use of the currently proposed local
>      repair mechanism (DAG splitting and merging)?
>
>         [NO implies that DAG repairs shall be coordinated globally  
> with
>         the use of DAG Sequence Number; the related mechanisms are to
>         be expanded for -04]

YES.


>   Question B:  Should RPL make use of a hold-up timer and related
>      states/procedures to reduce churn by coordinating the DAG merge?
>
>         [NO implies RPL allows nodes to move (jump) between DAGs with
>         little coordination to reduce complexity of specification/
>         implementation (perhaps w/ Optional hold-up mechanism)].


NO.


>   Question C:  Should RPL make use of a hold-down timer and related
>      states/procedures to limit flapping when removing DAG Parents /
>      leaving DAGs
>
>         [NO implies RPL allows nodes to freely remove/add DAG Parents
>         as and when they are able in order to reduce complexity of
>         specification/implementation (perhaps w/ Optional hold-down
>         mechanism).

NO.

In my opinion, currently the draft specifies too many mechanisms  
designed to improve efficiency, with little experimental evidence on  
their comparative tradeoffs or value (if any). They are based on a  
conceptual model of wireless that may or may not hold. I think the  
specification should focus on the requirements for interoperability  
between different implementations, not perceived optimizations. Just  
my 2c.

Phil