Subject: [6tisch] Questions on RPL Settings in RFC 8180

From: Yasuyuki Tanaka <[email-masked]>
Date: Thu, 23 Aug 2018 22:21:41 +0200

Hi all,

I have a few questions on the RPL settings described in RFC
8180. Could anyone help me find answers...?

  https://tools.ietf.org/html/rfc8180#section-5

---

(1) Rank Computation

RFC 8180 says:

rfc8180> 5.1.1.  Rank Computation
rfc8180> (...)
rfc8180> Sp SHOULD be calculated as (3*ETX)-2.  The minimum value of
rfc8180> Sp (MINIMUM_STEP_OF_RANK) indicates a good quality link.  The
rfc8180> maximum value of Sp (MAXIMUM_STEP_OF_RANK) indicates a poor
rfc8180> quality link.  The default value of Sp (DEFAULT_STEP_OF_RANK)
rfc8180> indicates an average quality link.  Candidate parents with
rfc8180> ETX greater than 3 SHOULD NOT be selected.

  https://tools.ietf.org/html/rfc8180#section-5.1.1

MAXIMUM_STEP_OF_RANK is defined to 9. Why?

Sp is calculated as (3 * ETX) - 2 and the worst acceptable ETX is
3. It looks like 7 is the possible largest value of Sp...

(2) Trickle Timer

RFC 8180 says:

rfc8180> 5.3.  Trickle Timer
rfc8180> (...)
rfc8180> For this specification, the Trickle timer MUST be used with the
rfc8180> RPL-defined default values (see Section 8.3.1 of [RFC6550]).

  https://tools.ietf.org/html/rfc8180#section-5.3

So, Imin for DIO Trickle timer starts with 8 ms, which looks too short
for the minimal TSCH schedule where one shared cell in a slotframe of
1.01s. This setting could cause congestion by DIO traffic...

Why is this default value (DEFAULT_DIO_INTERVAL_MIN) reasonable for
the 6TiSCH minimal configuration...?

rfc6550> 17.  RPL Constants and Variables
rfc6550> (...)
rfc6550> DEFAULT_DIO_INTERVAL_MIN: This is the default value used to
rfc6550>      configure Imin for the DIO Trickle timer.
rfc6550>      DEFAULT_DIO_INTERVAL_MIN has a value of 3.  This
rfc6550>      configuration results in Imin of 8 ms.

  https://tools.ietf.org/html/rfc6550#section-17

---

There are some email threads on RPL configuration found in 6TiSCH ML
archive. But, I could not find any discussion about above mentioned
points...

- [6tisch] On 2*ETX in Minimal
  https://mailarchive.ietf.org/arch/msg/6tisch/oWmlpcq2evOlf4gH90moG2gyxzg

- [6tisch] 6TiSCH Minimal: step_of_rank
  https://mailarchive.ietf.org/arch/msg/6tisch/BXbfFtysPHJTekkeQXScv1GVxCM

- [6tsch] Zero Objective Function discussion
  https://mailarchive.ietf.org/arch/msg/6tisch/McGiW7IPnhITB74Vz2y2SKXot80

Thank you!
Yatch

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 27 Aug 2018 15:30:34 +0000

Hello Yatch
> rfc8180> Sp SHOULD be calculated as (3*ETX)-2.  The minimum value of Sp
> rfc8180> (MINIMUM_STEP_OF_RANK) indicates a good quality link.  The
> rfc8180> indicates an average quality link.  Candidate parents with ETX
> rfc8180> greater than 3 SHOULD NOT be selected.
> 
[PT>] This is defined in OF0. 9 denotes a worst possible quality that is still acceptable and makes it equivalent to 9 hops at the best quality for that technology.
The number enables 7 hops at the worst rank factor (4) and with the worst quality.

> Sp is calculated as (3 * ETX) - 2 and the worst acceptable ETX is 3. It looks like 7 is
> the possible largest value of Sp...
> 
[PT>] True, so we never reach 9 and stay compatible with OF0. I guess the max ETX of 3 is arbitrary, we could have gone up to 11/3...

> So, Imin for DIO Trickle timer starts with 8 ms, which looks too short for the
> minimal TSCH schedule where one shared cell in a slotframe of 1.01s. This
> setting could cause congestion by DIO traffic...
> 
> Why is this default value (DEFAULT_DIO_INTERVAL_MIN) reasonable for the
> 6TiSCH minimal configuration...?
[PT>] 
[PT>] I agree that this needs discussion. Note that the minimal schedule of 1.01s is just an example.
The initial value of I (see RFC 6206) is between Imin and Imax. With the default, that is between 8ms and 2.3 hours. Hopefully I is not always 8ms! The DIO will not fire before I/2.
I agree we should use a somewhat higher Imin, but then that pushes Imax to the say and I may be set to that.
IOW I'd have liked to restraint the initial setting of I to something in between, like between a few seconds and a few minutes while keeping Imax to 2^20 times Imin.

Take care, 

Pascal
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 27 Aug 2018 15:45:30 +0000

Starting a discussion on your last point, Yatch:

RFC 6206 says:

"
   Finally, a protocol SHOULD set k and Imin such that Imin is at least
   two to three times as long as it takes to transmit k packets.
"
By default k n RPL is set to very conservative DEFAULT_DIO_REDUNDANCY_CONSTANT of 10, so there is not suppression unless there is a high density. 
So with the 1.01s slotframe, RFC 6206 recommends that Imin should be 20 to 30 seconds...

Maybe we could amend/ERRATA the RFC to recommend different settings.

 What do others think?

Pascal

> -----Original Message-----
> From: Pascal Thubert (pthubert)
> Sent: lundi 27 août 2018 17:29
> To: 'Yasuyuki Tanaka' <[email-masked]>; [email-masked]
> Subject: RE: [6tisch] Questions on RPL Settings in RFC 8180
> 
> Hello Yatch
> >
> > (1) Rank Computation
> >
> > RFC 8180 says:
> >
> > rfc8180> Sp
> [PT>] This is defined in OF0. 9 denotes a worst possible quality that is still
> acceptable and makes it equivalent to 9 hops at the best quality for that
> technology.
> > Sp is calculated as (3 * ETX) - 2 and the worst acceptable ETX is 3.
> > It looks like 7 is the possible largest value of Sp...
> >
> [PT>] True, so we never reach 9 and stay compatible with OF0. I guess the max
> ETX of 3 is arbitrary, we could have gone up to 11/3...
> 
> 
> > (2) Trickle Timer
> >
> > RFC 8180 says:
> >
> > rfc8180> For this specification, the Trickle timer MUST be used with
> > rfc8180> the RPL-defined default values (see Section 8.3.1 of [RFC6550]).
> >
> The initial value of I (see RFC 6206) is between Imin and Imax. With the default,
> that is between 8ms and 2.3 hours. Hopefully I is not always 8ms! The DIO will
> not fire before I/2.
> IOW I'd have liked to restraint the initial setting of I to something in between,
> like between a few seconds and a few minutes while keeping Imax to 2^20 times
> Imin.
> 
> Take care,
> 
> Pascal

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Mon, 27 Aug 2018 18:06:16 +0200

Thank you, Pascal!

> [PT>] True, so we never reach 9 and stay compatible with OF0. I guess the max ETX of 3 is arbitrary, we could have gone up to 11/3...

OK! That is what I understood. It's very clear now.

> The initial value of I (see RFC 6206) is between Imin and Imax. With the default, that is between 8ms and 2.3 hours. Hopefully I is not always 8ms! The DIO will not fire before I/2.

Regarding the Trickle timer, yes, the initial value of "I" is chosen between Imin and Imax. And it's not always 8ms.

But, "I" is reset to Imin (8 ms) when Trickle hears something "inconsistent". After that, "I" will be just doubled at the end of interval: 16ms, 32ms, 64ms, ... This could pile up DIOs in the TX queue and consume bandwidth for nothing. :-/

Best,
Yatch

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 28 Aug 2018 05:45:43 +0000

Hello Yatch:

I agree; thus my quote of RFC 6206 in the other mail.

 Now even if we do not do an erratum, an implementation should not schedule a transmission faster than it can send; iow I should be reset to Imin but rounded to the next minimal slot or the next mcast slot available.

 A node should not have multiple DIOs in xmit queue.

Regards,

Pascal

> Le 27 août 2018 à 18:06, Yasuyuki Tanaka <[email-masked]> a écrit :
> 
> Thank you, Pascal!
>

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Tue, 28 Aug 2018 10:55:32 +0200

Hi Pascal,

pascal> Maybe we could amend/ERRATA the RFC to recommend different settings.

It'd be nice to have some amendment or an errata entry for the following
sentence.

rfc8180> (5.3.  Trickle Timer, RFC 8180)
rfc8180>
rfc8180> For this specification, the Trickle timer MUST be used with the
rfc8180> RPL-defined default values (see Section 8.3.1 of [RFC6550]).

At least, "MUST" in this sentence should be replaced with something, in my
opinion.

Best,
Yatch

> On Aug 27, 2018, at 17:45, Pascal Thubert (pthubert) <[email-masked]> wrote:
>