Thank you Zhen for the review and comments... Please find my responses inline ...
cheers, Rahul On 14 July 2017 at 06:18, Zhen Cao <[email protected]> wrote: > Dear Rahul and co-authors, > > Many thanks for the hard work in contributing this draft to the lwig > wg. (I am copying roll and 6lo since some discussion will be quite > relevant) > > As I go through the document, I found essentially there are three > types of different policies discussed: > a. Trivial neighbor management (FCFS/LRU) > b. advanced neighbor management (proactive and reactive) > c. proposed ‘reservation based’ approach > > Logically I understand the shortcomings of the trivial approach, > however in practice, how much this many impact the network stability > is not convincing enough yet. (what’s the possible size of node > density/mobility may be impacted? ). > [RJ]: a) Existing open sources (such as RioT and Contiki) implement trivial nbr mgmt policies ... for e.g. riot uses FCFS, and Contiki previously used LRU (but Contiki in the past some time has upgraded and put out a new implementation inline to what we have proposed) ... Through this draft we want to highlight scalability issues with such trivial policies ... Scalability issues arise especially in case of dense networks with nodes having limited memory for neighbor cache ... b) Currently the draft talks only about reactive "reservation" based policy, since our aim to begin with, is to check what best can be achieved without making any signaling changes ... But clearly this has limitations which also are highlighted by the draft and we have put forth the reasoning for using proactive signaling ... In my deployment scenario, we could never stabilize the network unless we implemented such a policy ... My deployment is a typical metering scenario and the node density is not in control (network size is, but not the node density) ... In some areas the node density is high (100 nodes on the same hop) .. and the nbr cache is limited to say 25 entries ... in such a case NCEs undergo a churn which results in routing adjacencies never stabilizing ... Specifically, the draft will help implementers in cases "where the node density is higher than nbr cache size". Another way to look at that is, even if a node can afford to store a bigger nbr cache, it is inefficient use of dynamic memory. Proposed policy can be used to reduce the nbr cache size and thus optimize mem usage! > > The discussion of reactive and proactive ways of managing the neighbor > cache entries is helpful. The discussion about the proactive approach > in Sec.2.5.2 quoted below has some pending relationship with RPL (if > this is an acknowledged problem by ROLL WG). Anyway this is something > we need to discuss with the ROLL wg to see if this a need feature. > > Currently there is no standard way of signaling such neighbor cache > space availability information. RPL's DIO messages carry metric > information and can be augmented with neighbor cache space as an > additional metric. > [RJ] As I mentioned before, the current approach is a reactive "reservation" based approach ... It improves network stability but still has its own limitations (highlighted in the draft). These limitations could be worked out with some changes to existing protocols (such as RPL). As part of LWIG draft we have set forth only requirements towards such changes. > > For the proposed reservation based approach, I think this is quite a > practical recommendation (if my concern about a. will be relaxed). > > I also found the Contiki RPL implementation has recently used a > similar way in its rpl-nbr-policy. Shall we link the draft to the open > source community to see if the document has provided additional help > to the implementation? (or that’s already done given coauthors Simon > and Joakim are both active contributors of Contiki)? > [RJ] The Contiki rpl-nbr-policy implementation is already in line with the proposed draft. We already have the Contiki implementers as co-authors of this draft and their inputs have shaped the draft quite a lot. > > Many thanks for discussion. > Thank You! > > Cheers, > Zhen >
_______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
