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

From: john rubis <[email-masked]>
Date: Tue, 14 Nov 2017 21:52:54 +0000

I am glad to hear that I am not the only one that has needed to read RFC6550 10^6 times. I thought it was just me.

The question I have is, how to handle the case were a node's rank needs to increase due to the link cost (ETX) to its current parent increasing? In some cases this increase may exceed MinHopRankIncrease-1.

This assumes that I am interpreting how a node's rank is calculated per RFC 8180<https://datatracker.ietf.org/doc/html/rfc8180> or RFC6719.

Thank you,

John Rubis

Yes, that seems optimized.

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

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]<mailto:[email-masked]%3cmailto:[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]<mailto:[email-masked]><mailto:[email-masked]%3cmailto:[email-masked]%3e>]
Sent: mercredi 6 septembre 2017 15:36
To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>
Cc: IETF ROLL <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>; [email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[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]<mailto:[email-masked]%3cmailto:[email-masked]>>> wrote:

From: 6tisch [mailto:[email-masked]<mailto:[email-masked]><mailto:[email-masked]%3cmailto:[email-masked]%3e>] On Behalf Of Thomas Watteyne
Sent: mercredi 6 septembre 2017 08:20
To: IETF ROLL <[email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[email-masked]>>>; [email-masked]<mailto:[email-masked]<mailto:[email-masked]%3cmailto:[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

Please do comment if my comment is false!
[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 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?

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/<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.inspiringinsights.nl%2F&data=02%7C01%7Cjohn.rubis%40hotmail.com%7C4dd741b954b9487815d708d52ba69c09%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636462916935931708&sdata=W5ZQQnBarMiIDyZcmlkaPw6ttAxJWtFs7uHXUMytgiU%3D&reserved=0> (but I do not understand a word myself ; )

:-)

Take care,

Pascal

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<http://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<http://www.thomaswatteyne.com><http://www.thomaswatteyne.com%3chttp/www.thomaswatteyne.com%3E>
_______________________________________