[Roll] Understanding RPL [was: Working group re-charter ideas]

[Juliusz Chroboczek <[e-mail]>]

Thanks for your answer, Pascal.

> There are literally hundreds of papers that reference RPL,

Indeed.  But I've made a half-serious attempt at a bibliography search,
and couldn't find anything to satisfy my thirst for experimental data,
especially for the proactive subset.  Could you please give me a reference?

> so the process of microloop avoidance in Babel is effectively the same
> as what RPL calls a global recovery. Both protocols inherit DUAL's
> feasibility condition.

My perhaps mistaken understanding is that RPL uses a more primitive
version of DSDV's feasibility condition (without the even-odd mechanism
that avoids loops after a retraction).  If RPL uses DUAL feasibility, then
I completely fail to see the data structure that keeps the necessary
history (the equivalent of Babel's source table).

(Which makes sense for RPL -- you certainly don't want to multiply the
data structures being held in a sensor.  Babel and RPL play in different
spaces, right?)

> But RPL adds the capability to make local repair which provides
> a service of freezing akin to the the diffusion algorithm but adapted to
> LLN and MANET.

Again, I may be confused, but I think the local repair mechanism is not
specified in the RFC.  There's an example mechanism given in Section 3.7.2,
but that example is prone to loops in the presence of packet loss.

As what RPL calls a "global repair", all I could find in the RFC is

   A DODAG root institutes a global repair operation by incrementing the
   DODAGVersionNumber.  This initiates a new DODAG Version.

However, there's nothing I see to say when a root decides to trigger
a global repair (except for some vague mention of periodic updates, which
the DSDV experiment has shown are not a good idea).  This is very much
unlike Babel (different spaces, remember?)  which has a provably complete
reactive mechanism for triggering seqno updates.

> Even more, RPL adds a capability to stretch the rules, and a capability to
> delay the repairs so as to reduce the control overhead in Lower Power and
> mobile use cases.

Yes.  That's probably a very good feature in the space where RPL plays.
Which is different from the space that Babel aims for.

> All in all I remain to be convinced that Babel is much, much, anything.

That citation belongs on the conclusion slide of the next talk I give ;-)

-- Juliusz