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

[Cenk Gündogan <[e-mail]>]

Hello Simon, Joakim,

Thank you for the quick reponses!

On 05/02/2016 09:55 PM, Simon Duquennoy wrote:
> 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?
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

> Simon
>
>
> On Mon, May 2, 2016 at 9:25 PM, Cenk Gündogan <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     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
>
>     _______________________________________________
>     Roll mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/roll
>
>
>
>
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll