rpl: logic to switch between dodags

[cgundogan]

This PR introduces a simple check whether to leave the current dodag and join a new one, which would yield a better rank.

[OlegHahm]

Please put parens around each condition.

[OlegHahm]

Should a node really always switch the dodag upon DIO reception if the other provides a better rank?

[cgundogan]

adressed @OlegHahm's comment

[cgundogan]

@OlegHahm I think it is a good assumption that a node should join a dodag, which provides a better rank in order to get more 'optimal' dodag structures.

[OlegHahm]

To me this sounds dangerous in a way that nodes might end up wasting some energy by switching between dodags only to gain a better rank, @emmanuelsearch, what do you say?

[cgundogan]

I guess in a theoretical scenraio you only switch so often until you join the dodag, which yields the best rank for you. After then there won't be any more switches, because all other DIOs from the same instance are ignored (worse or equal rank).

EDIT: After each switch to a better dodag, you also eliminate all other dodags which have worse or equal ranks.. so I guess there won't be much extra energy consumption here?

[BytesGalore]

@OlegHahm @cgundogan the RFC states that a node should not be greedy to gain a better rank in one DODAG, but switching the DODAGs for a better rank is not mentioned explicitly.
However, I see some difficulties arising from this behaviour:

1. If a node switches the DODAG (and joins the new one) it resets its trickle timer [1]. This will result in transmissions of DIOs for this node in the joined DODAG.
2. The switch probably results that the left DODAG requires to repair the "gap" from the node. This, if it happens, will force the former neighbour nodes to reset their timers and start to distribute DIOs for the local repair.
3. In the worst case, if 2. happens and the local repair does not resolve the inconsistency, the former DODAG rises its version and reconstructs the topology.
   Now if the reconstructed DODAG provides a parent with better rank the left node returns, because the DODAG version changed [2], and again tears up a "gap" in the left DODAG .

This greediness for a better DODAG could result in some oscillation if we assume that a DODAG can change its shape over time, which consumes energy on several nodes.

(That's just some thoughts and maybe I missed something or just catastrophize a harmless situation)

[1] https://github.com/RIOT-OS/RIOT/blob/master/sys/net/routing/rpl/rpl_dodag.c#L393
[2] https://tools.ietf.org/html/rfc6550#section-8.2.2.4

[cgundogan]

@BytesGalore @OlegHahm What should we aim for then? At some point the node has to decide to switch to a better dodag (or not). I would vote for the simplistic approach of beeing greedy and think about other strategies later (when we have real multiple dodag support) @emmanuelsearch what is your opinion on this subject?

[jnohlgard]

@cgundogan Because of the problems outlined by @BytesGalore above, I vote for staying with the current DODAG instead of being greedy. Can the implementation today detect if we are no longer receiving DIOs for the current DODAG?

[BytesGalore]

@gebart at least we recognize the opposite here [1], if a DIO is not from our current DODAG.
I think we have no specific tracking mechanism for unreachable DODAGs.

[1] https://github.com/RIOT-OS/RIOT/blob/master/sys/net/routing/rpl/rpl_control_messages.c#L700

[cgundogan]

@gebart The route to the preferred parent could timeout (due to missing DIOs). This is the only way that comes to my mind for finding inactive Dodags. However, this timeout can be fairly long.

But I want to point out the following scenario:
Assuming we have a fully developed Dodag (let's say it's running for several time units now). As soon as one node decides to be the root of another Dodag of the same instance, nobody would join this Dodag (probably for a very long time). In my opinion nodes should decide based on the ranks they would get in each separate dodag. Like @BytesGalore explained earlier, being totally greedy can lead to several problems, but this kind of problems could be solved with a hysteresis like mechanism (e.g. do not switch dodags in a given time interval, or do not switch dodags if |rank_d1 - rank_d2| < X, where rank_d1 is the rank of dodag d1, rank_d2 is the rank of dodag d2 and X is a configurable parameter).

The point I want to make is that beeing greedy could be a good and simple starting point to develop further strategies on top of it and still be able to have support for multiple dodags in the same instance.

[emmanuelsearch]

Let's take a step back and think about scenarios where DODAG jumping makes sense.

On one hand, in order for jumping to make sense based on rank comparison, this implies that the OF and the root should be the same in both DODAGs. Else, metrics are not comparable, and thus jumping based on such a comparison is nonsense.

On the other hand, it is counterproductive (and thus unlikely) to have several DODAGs aiming to optimize the exact same metric, towards the same destination (root). Thus, I think we should not worry too much about nodes "jumping" around between DODAGs.

There are other cases, where we have several DODAGs, with the same OF, but each with a different root (e.g. with P2P-RPL [1] running in parallel of basic RPL).
But in such cases, we fall back to rank comparisons between DODAGs being nonsense (because roots are different).

So all in all: I guess we do not need such logic. Or am I missing something?

[1] https://tools.ietf.org/html/rfc6997

[BytesGalore]

@emmanuelsearch most probably I'm confusing things, but what I understand is that one RPL-Insatnce is a set of 1..n DODAGs, where all the DODAGs within that instance (equal RPLInstanceID) share the same OF.
On that (probably wrong) assumption, using a simple metric like OF0 jumping to another DODAG within a global DODAG could look beneficial for a node.
But I also think we should not worry too much about nodes "jumping" around between DODAGs.

[emmanuelsearch]

@BytesGalore I'm not sure where you get this understanding from, but to me, it makes no practical sense to have multiple DODAGs using the same OF, with the same root. Sounds like overhead for nothing gained?

[cgundogan]

@emmanuelsearch, I think @BytesGalore was refering to multiple dodag-roots for the same rpl-instance. To my understanding it should be possible to have several dodag roots using the same global instance id RFC6550#section-5.1, while local instance ids are bound to the dodagid and thus unique.

But again, the majority agrees on dropping this PR for now, so I will close it if there is no objection?

[BytesGalore]

Ahh, I just confused the term global DODAG being a regular local DODAG [1].

(and I should read my mails before posting replies)

[1] https://tools.ietf.org/html/rfc6550#section-5