inline On Wed, Sep 6, 2017 at 2:02 PM, Pascal Thubert (pthubert) < [email protected]> wrote:
> > > > > *From:* 6tisch [mailto:[email protected]] *On Behalf Of *Thomas > Watteyne > *Sent:* mercredi 6 septembre 2017 08:20 > *To:* IETF ROLL <[email protected]>; [email protected] > *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/ > <http://www.inspiringinsights.nl/> (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: > > > > 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 > > _______________________________________ > -- _______________________________________ 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 _______________________________________
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
