Subject: [Roll] Trickle Reset vs Restart

From: Rahul Jadhav <[email-masked]>
Date: Thu, 21 Nov 2019 13:02:19 +0800

During the IETF106 roll-session, we discussed resetting vs restarting
Trickle. Pascal raised this in another mail as well.

After checking RFC 6206 (Section 4.2), I found that there is only one
notion i.e., to reset Trickle timer, which means going back to Imin and
starting a new interval.

There is no notion of restarting the current timer for the instantaneous
value of I.

This is what my understanding was and reset is all that is needed, IMO. I
would like to be corrected if there is any use-case, where restarting the
timer would be needed.

We may not need any clarifications on this particular issue. Or do you
think we should still keep this as a note for implementors in the
observations draft?

Regards,
Rahul

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 21 Nov 2019 05:16:40 +0000

Hello Rahul 

We all observe that restarting the timer can be disfunctional. So yes I think it deserves text somewhere, starting immediately in your rich and useful observations draft.

I’m happy to add text in the eliding-options draft, for the lack of a better carrier. I think that the observation that the timer should not be restarted may not be general to trickle but seems general to where we use trickle in RPL.

Regards,

Pascal

> Le 21 nov. 2019 à 13:02, Rahul Jadhav <[email-masked]> a écrit :
> 
> 
> During the IETF106 roll-session, we discussed resetting vs restarting Trickle. Pascal raised this in another mail as well.
> 
> After checking RFC 6206 (Section 4.2), I found that there is only one notion i.e., to reset Trickle timer, which means going back to Imin and starting a new interval.
> 
> There is no notion of restarting the current timer for the instantaneous value of I.
> 
> This is what my understanding was and reset is all that is needed, IMO. I would like to be corrected if there is any use-case, where restarting the timer would be needed.
> 
> We may not need any clarifications on this particular issue. Or do you think we should still keep this as a note for implementors in the observations draft?
> 
> Regards,
> Rahul
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Rahul Jadhav <[email-masked]>
Date: Fri, 22 Nov 2019 12:32:28 +0800

Hi Pascal, All,

Following PR (https://github.com/roll-wg/rpl-observations/pull/7) adds the
text in the RPL-Observation draft for the clarification of these points.
Please let me know if you have any comments.

Regards,
Rahul

On Thu, 21 Nov 2019 at 13:16, Pascal Thubert (pthubert) <[email-masked]>
wrote:

> Hello Rahul
>
> We all observe that restarting the timer can be disfunctional. So yes I
> think it deserves text somewhere, starting immediately in your rich and
> useful observations draft.
>
> I’m happy to add text in the eliding-options draft, for the lack of a
> better carrier. I think that the observation that the timer should not be
> restarted may not be general to trickle but seems general to where we use
> trickle in RPL.
>
>
> Regards,
>
> Pascal
>
> > This is what my understanding was and reset is all that is needed, IMO.
> I would like to be corrected if there is any use-case, where restarting the
> timer would be needed.
> >

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 25 Nov 2019 08:29:49 +0200

That depends on the Protocol/Standard using Trickel Algorithm.

Restart can be used. So if such protocol using this algorithm needs
Restart, then it can be used for protocol performance and usecases.
Reset is always needed by Trickel ( it is in its six Rules, section 4) that
is in the RFC6206 specification, and also Reset can be needed/used by the
protocol using the Trickel (mentined in section 5).

Overall, any protocol/standard using this RFC6206 algorithm must specify
what does it reacts when inconsistency is detected. That reaction can be
Restart algorithm.

> notion i.e., to reset Trickle timer, which means going back to Imin and

not one notion I think,

> would like to be corrected if there is any use-case, where restarting the

I think Restart is needed by RPL at some topology changes with
inconsistency, or needed at protocol configuration changes at runtime. We
don't forget that C6206 is so far from perfect (these words mentioned in
section 6.7), with some efficient results. However, it may need simple
restart or reconfiguring its parameters at cases that can be noticed by
RFC6206 operational considerations section.

> think we should still keep this as a note for implementors in the

IMO, clarification in drafts is always good specially in a
standard/updating_standard draft.

Regards,
AB