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 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: 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> _______________________________________
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
