Hello Tengfei, All our approaches are currently work in progress and we plan to evaluate them in the coming weeks. We understand this is late in the standardization process and some of our changes are more involved than others. Here are some of the ideas we plan to evaluate.
Our first goal is to reduce the time required by MSF to allocate the number of cells for the current traffic. To do so, we could allocate more than 1 cell per 6P transaction, another change would replace the recurring window of MAX_NUM_CELLS with a sliding window of the same size. As a result we don't have to wait up to MAX_NUM_CELLS to issue the next 6P request but only up to the next cell. Our second goal is to reduce the overprovisioning of MSF especially with higher traffic load. To do so, we plan to evaluate changes to the values for LIM_NUMCELLSUSED_HIGH and LIM_NUMCELLSUSED_LOW and eventually use dynamic values that depend on an estimation of the current traffic load. Best regards, David, Bruno, Aris and Georgios On Fri, 10 Apr 2020 11:16:57 +0200 Tengfei Chang <[email protected]> wrote: > Hi David, > > I replied inline: > > On Fri, Apr 10, 2020 at 12:27 AM David Hauweele > <[email protected]> wrote: > > > Dear 6TiSCH, > > > > In the last few months, we performed a small scale study of the > > behavior of 6TiSCH's minimal scheduling function (MSF) under > > stress. We were especially interested in the dynamics of MSF's > > automated adaptation to traffic load. Some of our conclusions have > > been summarized in a paper that we submitted to IEEE ISCC 2020. A > > copy of the evaluation section of our submission is attached to > > this mail. > > > > Congrats on the published paper! > > > > > Among our surprising findings, we observed that > > > > 1) The time required for MSF to adapt to a traffic change depends on > > the current number of cells allocated. To give an example, it takes > > much longer to go from 0 to 10 cells than from 10 to 20 cells. We > > attribute this behavior to the way MSF measures cell occupancy by > > counting the number of used and passed cells. Adaptation only occurs > > when the number of passed cells reaches a maximum. However, with > > light cell allocation, it takes longer to reach that maximum than > > with higher cell allocation. > > > > Cool! I have the similar results when evaluate the MSF performance. > There are two things influencing the response time to the traffic > changes 1. The value of MAX_NUM_CELLS, which you mentioned. It is > configurable. By setting it to a small value, the response time can > be reduced in case the traffic load changes frequently. > 2. The number of cells to be added/deleted each time. In MSF, for > the simplicity, we only add/delete 1 cell every time. An advanced > version of MSF could add/delete cells according the percentage of > cell usage. > > > > > 2) MSF can lead to severe over-provisioning, which can be harmful > > in an environment where the resources are scarce. We noticed that > > releasing cells was especially hard for MSF due to the fixed > > hysteresis thresholds. Indeed, the estimated cell occupancy must > > drop below 25% for cells to be released. > > > > The over-provisioning is designed intentionally to avoid the > fluctuation of 6P transactions. > It costs additional 50% cells in average, as a trade-off, it could > reduce the cost of sending 6P frames, and the latency caused by 6P > transaction. No sure if there is a perfect way to cover every aspects? > > > > > We already have ideas to improve MSF's traffic adaptation mechanism, > > that we plan to put under test in the coming weeks. We can also > > provide you with more details if you wish. If you see interest in > > our evaluation and proposals, we are eager to discuss this further > > with the WG. > > > > Very interesting to see your approach to improve MSF ! > Referring to the MSF standardization process , as said by Pascal, we > won't be able to made big changes. > We can adapt some minor changes. > Unless there is a flaw in the draft, I would prefer to keep the draft > as it. > > Tengfei > > > > > > Best regards, > > David, Bruno, Aris and Georgios > > _______________________________________________ > > 6tisch mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/6tisch > > > > _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
