Subject: [6tisch] clarifying question about RPL: DAGMaxRankIncrease

From: Thomas Watteyne <[email-masked]>
Date: Wed, 6 Sep 2017 08:19:40 +0200

All,

While re-reading RFC6550 for the 10^6's time, and realize I have some
fundamental questions about DAGMaxRankIncrease...

In RFC6550, DAGMaxRankIncrease appears a grand total of 5 times (listed at
the bottom of this e-mail for pedantic completeness).

*Question 1: rationale*

The rationale of having DAGMaxRankIncrease is explained in the last
sentence below. But the sentence is not 100% clear, at least to me.

Do you agree with the statement that "DAGMaxRankIncrease is there to limit
the count-to-infinity"? That is, if parent and child and swapping roles,
rather than counting to infinity, they count to DAGMaxRankIncrease. To put
in another way, when a node's rank increases to L+DAGMaxRankIncrease, the
node has serious reasons to believe it is in a count-to-infinity spiral.

Please do comment if my comment is false!

*Question 2: recommended value*

Neither RFC6550, RFC8180 nor RFC6552 give any indication as to what value
to pick for DAGMaxRankIncrease.

I understand that, the larger the value of DAGMaxRankIncrease, the longer
the count-to-infinity spiral goes on. This means having packets reach their
hop limit, and get dropped. Bad.

The other extreme is to set DAGMaxRankIncrease=MinHopRankIncrease. This
results in a local repair as soon as the mote increases it rank to that of
its children.

It follows that the value of DAGMaxRankIncrease should be larger than
MinHopRankIncrease, but not too large so count-to-infinity aborts quickly.
OK.

But why should I have DAGMaxRankIncrease>MinHopRankIncrease at all? This
would allow count-to-infinity to start, and packets to get dropped, which
is a big no-no in serious networks. What is the danger of having
DAGMaxRankIncrease=MinHopRankIncrease?

Looking for inspiring insights.

Thomas

====

Section 6.7.6:

MaxRankIncrease: 16-bit unsigned integer used to configure
DAGMaxRankIncrease, the allowable increase in Rank in support
of local repair. If DAGMaxRankIncrease is 0, then this
mechanism is disabled.

Section 8.2.24:

Let L be the lowest Rank within a DODAG Version that a given node
has advertised. Within the same DODAG Version, that node MUST
NOT advertise an effective Rank higher than L +
DAGMaxRankIncrease. INFINITE_RANK is an exception to this rule:
a node MAY advertise an INFINITE_RANK within a DODAG Version
without restriction. If a node’s Rank were to be higher than
allowed by L + DAGMaxRankIncrease, when it advertises Rank, it
MUST advertise its Rank as INFINITE_RANK.

Section 8.2.2.4:

A node is allowed to join any DODAG Version that it has never been a
prior member of without any restrictions, but if the node has been a
prior member of the DODAG Version, then it must continue to observe
the rule that it may not advertise a Rank higher than
L+DAGMaxRankIncrease at any point in the life of the DODAG Version.
This rule must be observed so as not to create a loophole that would
allow the node to effectively increment its Rank all the way to
INFINITE_RANK, which may have impact on other nodes and create a
resource-wasting count-to-infinity scenario.

-- 
_______________________________________

Thomas Watteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

www.thomaswatteyne.com
_______________________________________

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 6 Sep 2017 12:02:53 +0000

From: 6tisch [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: mercredi 6 septembre 2017 08:20
To: IETF ROLL <[email-masked]>; [email-masked]
Subject: [6tisch] clarifying question about RPL: DAGMaxRankIncrease

All,

While re-reading RFC6550 for the 10^6's time, and realize I have some fundamental questions about DAGMaxRankIncrease...

In RFC6550, DAGMaxRankIncrease appears a grand total of 5 times (listed at the bottom of this e-mail for pedantic completeness).

Question 1: rationale

The rationale of having DAGMaxRankIncrease is explained in the last sentence below. But the sentence is not 100% clear, at least to me.

Do you agree with the statement that "DAGMaxRankIncrease is there to limit the count-to-infinity"?
[Pascal] YES
That is, if parent and child and swapping roles, rather than counting to infinity, they count to DAGMaxRankIncrease. To put in another way, when a node's rank increases to L+DAGMaxRankIncrease, the node has serious reasons to believe it is in a count-to-infinity spiral.
[Pascal] YES

[Pascal] No comment : )

Question 2: recommended value

Neither RFC6550, RFC8180 nor RFC6552 give any indication as to what value to pick for DAGMaxRankIncrease.
[Pascal] I’d suggest 0; this relates to the chances of picking a child of yours in a down spiral. If you’re lucky, you pick a parent below you that is not your descendant and the method succeeds. If you are unlucky, you are one of his ancestors and a loop is created. If he has multiple parents, only some of the packets may be affected. IOW: You are lucky and local repair is really quick. You are unlucky and it is really long. You have an external hint, good for you. You don’t and you expect a deterministic behavior, do not use that scheme. Note: these comments come from someone who opposed that mechanism in the RPL design.

I understand that, the larger the value of DAGMaxRankIncrease, the longer the count-to-infinity spiral goes on. This means having packets reach their hop limit, and get dropped. Bad.

[Pascal] True

The other extreme is to set DAGMaxRankIncrease=MinHopRankIncrease. This results in a local repair as soon as the mote increases it rank to that of its children.
[Pascal] True, one may attach to an ex-sibling. That should be mostly harmless since it does not break the feasibility condition, which is, do not attach to someone that advertises a Rank worse than you ever advertised (since you last poisoned), expressed in units of MinHopRankIncrease.

It follows that the value of DAGMaxRankIncrease should be larger than MinHopRankIncrease, but not too large so count-to-infinity aborts quickly. OK.
[Pascal] No. You do not have to use the mechanism at all (or use it as above)

But why should I have DAGMaxRankIncrease>MinHopRankIncrease at all? This would allow count-to-infinity to start, and packets to get dropped, which is a big no-no in serious networks. What is the danger of having DAGMaxRankIncrease=MinHopRankIncrease?
[Pascal] Agreed. I’m still looking for the piece that you dod not understand. I do not see any…

Looking for inspiring insights.
[Pascal] http://www.inspiringinsights.nl/ (but I do not understand a word myself ; )

Take care,

Pascal

Thomas

====

Section 6.7.6:

Section 8.2.24:

Section 8.2.2.4<http://8.2.2.4>:

Thomas Watteyne, PhD

www.thomaswatteyne.com<http://www.thomaswatteyne.com>
_______________________________________

---

From: Xavi Vilajosana Guillen <[email-masked]>
Date: Wed, 6 Sep 2017 15:32:08 +0200

Hi,

I have a clarifying question.

when a node uses DAGMaxRankIncrease = 0, this means that this mechanism is
disabled. What that really means? is then L the rank a node should
advertise?

regards,
Xavi

2017-09-06 14:02 GMT+02:00 Pascal Thubert (pthubert) <[email-masked]>:

>
>
>
>
> *From:* 6tisch [mailto:[email-masked]] *On Behalf Of *Thomas
> Watteyne
> *Sent:* mercredi 6 septembre 2017 08:20
> *To:* IETF ROLL <[email-masked]>; [email-masked]
> *Subject:* [6tisch] clarifying question about RPL: DAGMaxRankIncrease
>
>
>
> All,
>
>
>
> In RFC6550, DAGMaxRankIncrease appears a grand total of 5 times (listed
> at the bottom of this e-mail for pedantic completeness).
>
>
>
> *Question 1: rationale*
>
>
>
> *[Pascal] YES*
> That is, if parent and child and swapping roles, rather than counting to
> infinity, they count to DAGMaxRankIncrease. To put in another way, when a
> node's rank increases to L+DAGMaxRankIncrease, the node has serious
> reasons to believe it is in a count-to-infinity spiral.
>
> *[Pascal] YES*
>
>
>
> *[Pascal] No comment : )*
>
>
>
> *[Pascal] I’d suggest 0; this relates to the chances of picking a child of
> yours in a down spiral. If you’re lucky, you pick a parent below you that
> is not your descendant and the method succeeds. If you are unlucky, you are
> one of his ancestors and a loop is created. If he has multiple parents,
> only some of the packets may be affected. IOW: You are lucky and local
> repair is really quick. You are unlucky and it is really long. You have an
> external hint, good for you. You don’t and you expect a deterministic
> behavior, do not use that scheme. Note: these comments come from someone
> who opposed that mechanism in the RPL design. *
>
>
>
> *[Pascal] True*
> *[Pascal] True, one may attach to an ex-sibling. That should be mostly
> harmless since it does not break the feasibility condition, which is, do
> not attach to someone that advertises a Rank worse than you ever advertised
> (since you last poisoned), expressed in units of MinHopRankIncrease.*
>
>
>
>
>
> MinHopRankIncrease, but not too large so count-to-infinity aborts
> quickly. OK.
>
> *[Pascal] No. You do not have to use the mechanism at all (or use it as
> above)*
>
>
>
> *[Pascal] Agreed. I’m still looking for the piece that you dod not
> understand. I do not see any…*
>

> *[Pascal] http://www.inspiringinsights.nl/
> <http://www.inspiringinsights.nl/> (but I do not understand a word myself ;
> )*
>
>
>
> *Take care,*
>
>
>
> *Pascal*
>
>
>
>
>
> Thomas
>
>
>
> ====
>
>
>
> Section 6.7.6:
>
>
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

-- 
Dr. Xavier Vilajosana
Wireless Networks Lab

*Internet Interdisciplinary Institute (IN3)Professor*
(+34) 646 633 681
[email-masked] <[email-masked]>
http://xvilajosana.org
http://wine.rdi.uoc.edu
Parc Mediterrani de la Tecnologia
Av Carl Friedrich Gauss 5, B3 Building
08860 Castelldefels (Barcelona). Catalonia. Spain

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 6 Sep 2017 15:36:22 +0200

inline

On Wed, Sep 6, 2017 at 2:02 PM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

> who opposed that mechanism in the RPL design.*
>

I have a hard time following. Setting DAGMaxRankIncrease to 0 means you
disable the bounding on the count-to-infinity, and you run the risk of
having an actual count to infinity. Is that what you suggest?

> <http://www.inspiringinsights.nl/> (but I do not understand a word myself ;

:-)

Thomas Watteyne, PhD

www.thomaswatteyne.com

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 6 Sep 2017 15:30:56 +0000

Hello Thomas :

The mechanism to disable is the ability to increase the Rank above L without poisoning, which effectively means moving down the DODAG and thus risking a loop.
To there can be no count to infinity. The node has to detach, poison (e.g. by rooting a floating DAG, or by exposing an infinite Rank), observe for a while till its descendants have acted on it (we cannot afford the diffusion algorithm so that’s an approximation) and then the node can move back, deeper than it originally was since L is now reset.

The way to signal that it risking CTI is acceptable is signaled by a non-zero value of the MaxRankIncrease in the DODAG Configuration option. I agree with you that a value below MinHopRankIncrease is in fact harmless and c/should be used.

Is that your question?

Pascal

From: Thomas Watteyne [mailto:[email-masked]]
Sent: mercredi 6 septembre 2017 15:36
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: IETF ROLL <[email-masked]>; [email-masked]
Subject: Re: [6tisch] clarifying question about RPL: DAGMaxRankIncrease

inline

On Wed, Sep 6, 2017 at 2:02 PM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:

From: 6tisch [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Thomas Watteyne
Sent: mercredi 6 septembre 2017 08:20
To: IETF ROLL <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: [6tisch] clarifying question about RPL: DAGMaxRankIncrease

All,

Question 1: rationale

I have a hard time following. Setting DAGMaxRankIncrease to 0 means you disable the bounding on the count-to-infinity, and you run the risk of having an actual count to infinity. Is that what you suggest?

[Pascal] True

:-)

Take care,

Pascal

Thomas

====

Section 6.7.6:

Section 8.2.24:

Thomas Watteyne, PhD

Thomas Watteyne, PhD

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 6 Sep 2017 15:32:56 +0000

Hello Xavi :

Yes, in that case the node will advertise L, and L can only be reduced over time.  The way to reattach deeper is first to detach, wait and see.

Take care,

Pascal

From: Xavi Vilajosana Guillen [mailto:[email-masked]]
Sent: mercredi 6 septembre 2017 15:32
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: Thomas Watteyne <[email-masked]>; IETF ROLL <[email-masked]>; [email-masked]
Subject: Re: [6tisch] clarifying question about RPL: DAGMaxRankIncrease

Hi,

when a node uses DAGMaxRankIncrease = 0, this means that this mechanism is disabled. What that really means? is then L the rank a node should advertise?

regards,
Xavi

2017-09-06 14:02 GMT+02:00 Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>:

All,

Question 1: rationale

[Pascal] True

Take care,

Pascal

Thomas

====

Section 6.7.6:

Section 8.2.24:

Thomas Watteyne, PhD

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

--
Dr. Xavier Vilajosana
Wireless Networks Lab
Internet Interdisciplinary Institute (IN3)
Professor
(+34) 646 633 681
[email-masked]<mailto:[email-masked]>
http://xvilajosana.org
http://wine.rdi.uoc.edu

[Universitat Oberta de Catalunya]  [https://ferranadelantado.files.wordpress.com/2014/05/wine_logo_small2-e1453363995864.png?w=330&h=123]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 6 Sep 2017 15:36:58 +0000

Clarifying my writing, when the mechanism is disabled by  setting a zero value of the MaxRankIncrease in the DODAG Configuration option, there can be no count to infinity, no loop. In theory, because in practice, if a descendant did not see the poisoning, which is possible since we are not using the diffusion algorithm / DUAL ), then there could still be a loop. This the importance of the datapath detection with the RPI…

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: mercredi 6 septembre 2017 17:31
To: Thomas Watteyne <[email-masked]>
Cc: IETF ROLL <[email-masked]>; [email-masked]
Subject: Re: [6tisch] clarifying question about RPL: DAGMaxRankIncrease

Hello Thomas :

Is that your question?

Pascal

From: Thomas Watteyne [mailto:[email-masked]]
Sent: mercredi 6 septembre 2017 15:36
To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Cc: IETF ROLL <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [6tisch] clarifying question about RPL: DAGMaxRankIncrease

inline

All,

Question 1: rationale

[Pascal] True

:-)

Take care,

Pascal

Thomas

====

Section 6.7.6:

Section 8.2.24:

Thomas Watteyne, PhD

Thomas Watteyne, PhD

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 6 Sep 2017 17:38:06 +0200

OK, so your recommendation is to
use DAGMaxRankIncrease=MinHopRankIncrease-1, and have a node that violates
DAGMaxRankIncrease detach, create a floating DAG, and reattach?

On Wed, Sep 6, 2017 at 5:30 PM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

> Hello Thomas :
>
>
>
> The mechanism to disable is the ability to increase the Rank above L
> without poisoning, which effectively means moving down the DODAG and thus
> risking a loop.
>
> To there can be no count to infinity. The node has to detach, poison (e.g.
> by rooting a floating DAG, or by exposing an infinite Rank), observe for a
> while till its descendants have acted on it (we cannot afford the diffusion
> algorithm so that’s an approximation) and then the node can move back,
> deeper than it originally was since L is now reset.
>
>
>
> The way to signal that it risking CTI is acceptable is signaled by a
> non-zero value of the MaxRankIncrease in the DODAG Configuration option. I
> agree with you that a value below MinHopRankIncrease is in fact harmless
> and c/should be used.
>
>
>
> Is that your question?
>
>
>
> Pascal
>
>
>
>
>
>
>
> *From:* Thomas Watteyne [mailto:[email-masked]]
> *Sent:* mercredi 6 septembre 2017 15:36
> *To:* Pascal Thubert (pthubert) <[email-masked]>
> *Cc:* IETF ROLL <[email-masked]>; [email-masked]
> *Subject:* Re: [6tisch] clarifying question about RPL: DAGMaxRankIncrease
>
>
>
> inline
>
>
>

Thomas Watteyne, PhD

www.thomaswatteyne.com

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 6 Sep 2017 15:40:58 +0000

Yes, that seems optimized.

Sent: mercredi 6 septembre 2017 17:38

OK, so your recommendation is to use DAGMaxRankIncrease=MinHopRankIncrease-1, and have a node that violates DAGMaxRankIncrease detach, create a floating DAG, and reattach?

On Wed, Sep 6, 2017 at 5:30 PM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Thomas :

Is that your question?

Pascal

From: Thomas Watteyne [mailto:[email-masked]<mailto:[email-masked]>]

inline

All,

Question 1: rationale

[Pascal] True

:-)

Take care,

Pascal

Thomas

====

Section 6.7.6:

Section 8.2.24:

Thomas Watteyne, PhD

Thomas Watteyne, PhD

Thomas Watteyne, PhD