Subject: [Roll] How to react if Trickle Interval > Default Lifetime

From: Cenk Gündogan <[email-masked]>
Date: Mon, 2 May 2016 21:25:31 +0200

Dear RPL Veterans,

I recently came across the question of how a RPL router may react,
if a parent's default lifetime (and unit -- specified in the DODAG Conf. 
Opt.)
is surpassed by the parent's continuously rising trickle interval?

Without any action from the children, I would assume that the upward link to
the parent would time out before the next DIO arrives to refresh the 
lifetime,
hence breaking the child -> parent relation.

Implementations seem to handle this case very differently..

* The RPL implementation of RIOT uses unicast DIS messages to request a 
one-shot DIO
from a parent that has a link which is about to expire.
* From what I could gather in [1], Contiki also seems to send unicast DIS
messages randomly in an interval of 30~55 seconds (Please correct me if 
I am wrong).
* In an off-list discussion with Michael, I learned that unstrung is 
e.g. handling
this case by not letting the Trickle interval exceed the default lifetime
(Again, please correct me if I am wrong).

I couldn't find any hints regarding this situation in RFC6550.
Is there actually an obvious way to handle this, but I am just not 
seeing it?

Best,
Cenk Gündoğan

[1] 
https://github.com/contiki-os/contiki/blob/master/core/net/rpl/rpl-timers.c

---

From: Simon Duquennoy <[email-masked]>
Date: Mon, 2 May 2016 21:55:11 +0200

Dear Cenk,

In Contiki we send periodic multicast DIS until the node has joined any DAG.
After that, one thing you can do if enable "probing", which will
periodically send a unicast DIS to your preferred parent (and also cover
other candidates neighbors, to keep link estimates up-to-date).

In general wouldn't it be the expected practice to advertise trickle
parameters that never surpass the default lifetime?

Simon

On Mon, May 2, 2016 at 9:25 PM, Cenk Gündogan <[email-masked]> wrote:

> messages randomly in an interval of 30~55 seconds (Please correct me if I
> am wrong).
> * In an off-list discussion with Michael, I learned that unstrung is e.g.
> handling
> Is there actually an obvious way to handle this, but I am just not seeing
> it?
>
> Best,
> Cenk Gündoğan
>
> [1]
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

---

From: Joakim Eriksson <[email-masked]>
Date: Mon, 2 May 2016 22:00:27 +0200

Hello,

In Contiki I do think we are typically using infinite lifetime on the installed route between the child to parent.
If the child needs a downward route it would register that via DAO and keep that re-sent at less than default lifetime as specified
by the DIO (default lifetime and lifetime unit).

Best regards,
— Joakim

> On 02 May 2016, at 21:55, Simon Duquennoy <[email-masked]> wrote:
> 
> Dear Cenk,
> 
> After that, one thing you can do if enable "probing", which will periodically send a unicast DIS to your preferred parent (and also cover other candidates neighbors, to keep link estimates up-to-date).
> 
> In general wouldn't it be the expected practice to advertise trickle parameters that never surpass the default lifetime?
> 
> Simon
> 
> 
> On Mon, May 2, 2016 at 9:25 PM, Cenk Gündogan <[email-masked] <mailto:[email-masked]>> wrote:
> Dear RPL Veterans,
> 
> if a parent's default lifetime (and unit -- specified in the DODAG Conf. Opt.)
> the parent would time out before the next DIO arrives to refresh the lifetime,
> * The RPL implementation of RIOT uses unicast DIS messages to request a one-shot DIO
> messages randomly in an interval of 30~55 seconds (Please correct me if I am wrong).
> * In an off-list discussion with Michael, I learned that unstrung is e.g. handling
> Is there actually an obvious way to handle this, but I am just not seeing it?
> 
> Best,
> Cenk Gündoğan
> 
> [1] https://github.com/contiki-os/contiki/blob/master/core/net/rpl/rpl-timers.c <https://github.com/contiki-os/contiki/blob/master/core/net/rpl/rpl-timers.c>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/roll <https://www.ietf.org/mailman/listinfo/roll>
>

---

From: Cenk Gündogan <[email-masked]>
Date: Mon, 2 May 2016 22:46:52 +0200

Hello Simon, Joakim,

Thank you for the quick reponses!

On 05/02/2016 09:55 PM, Simon Duquennoy wrote:
> periodically send a unicast DIS to your preferred parent (and also 
> cover other candidates neighbors, to keep link estimates up-to-date).
I would actually expect to find expected practices in the RFC.

The default values of the trickle timer as defined in RFC6550 can result 
in intervals of up to
2.3 hours. If I am bound to use lifetimes > 2.3 hours (or even 
infinite), then it's not really possible to notice
defunct parents within that time span (apart from checking DAO-ACKs and 
signaling of other layers..).
By restricting the lifetimes to such intervals, we basically increase 
the convergence time
of the routing protocol to the same amount of time (worst case).

As a matter of fact, I considered the DIS solution to request a DIO 
before a timeout occurs
as an expected practice and I was a little bit surprised to see that 
implementations are handling
this differently.

However, it seems that there are some degrees of freedom in this matter,
and I am wondering if this can affect interoperability of different 
implementations used in the same network?

Best,
Cenk

---

From: Joakim Eriksson <[email-masked]>
Date: Mon, 2 May 2016 23:06:20 +0200

Hello,

> On 02 May 2016, at 22:46, Cenk Gündogan <[email-masked]> wrote:
> 
> Hello Simon, Joakim,
> 
> The default values of the trickle timer as defined in RFC6550 can result in intervals of up to
> 2.3 hours. If I am bound to use lifetimes > 2.3 hours (or even infinite), then it's not really possible to notice
> defunct parents within that time span (apart from checking DAO-ACKs and signaling of other layers..).
> By restricting the lifetimes to such intervals, we basically increase the convergence time

Typically the RPL parent will get lots of data from the children which will cause the link-metric to change
so it is not always the case that a defunct parent (at least not any of the actively used ones) will be just
kept for 2.3 hours but rather be switched out since it’s link is detected to be really bad.

> As a matter of fact, I considered the DIS solution to request a DIO before a timeout occurs
> as an expected practice and I was a little bit surprised to see that implementations are handling
> this differently.

Yes, a regular unicast DIS is a good way to keep both link metrics and other important liveliness
information up to date.

> and I am wondering if this can affect interoperability of different implementations used in the same network?

It might affect something, but I would guess there are many other things that might be worse when it comes
to impact on interoperability between implementations. Especially DAO / DAO ACK feels underspecified in
the RFC.

Best regards,
— Joakim

---

From: Michael Richardson <[email-masked]>
Date: Fri, 06 May 2016 09:40:56 -0400

Joakim Eriksson <[email-masked]> wrote:
    > Typically the RPL parent will get lots of data from the children which
    > will
    > cause the link-metric to change
    > so it is not always the case that a defunct parent (at least not any of
    > the
    > actively used ones) will be just

In many networks (metering for instance),  there can be very little traffic
for hours at a time, then a dozen packets down that part of the tree a few
times a day.

One answer that I like though: if there is no traffic, then it doesn't matter
if the routes are good or not.  The question is, when traffic does show up,
can we handle it in a timely fashion.

    > other important liveliness

There is a document on unicast DIS.  Does it provide useful advice to you?

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-