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