Subject: [6tisch] MSF traffic adaptation under stress

From: David Hauweele <[email-masked]>
Date: Fri, 10 Apr 2020 00:21:20 +0200

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.

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.

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.

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.

Best regards,
David, Bruno, Aris and Georgios

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 10 Apr 2020 06:50:29 +0000

Hello David

I’m really interested to see your results and proposal for improvements.

If people are interested we could set up an hour virtual interim. We must have it 3 weeks in advance which means early June.

In the meantime, yes please consider whether there are simple adjustments to the spec that could be made before we ship it. We’re very late in the process so we have to act swiftly.

Many thanks!

Pascal

> Le 10 avr. 2020 à 00:27, David Hauweele <[email-masked]> a écrit :
> 
> Dear 6TiSCH,
> 
> <msf-1.pdf>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

---

From: Tengfei Chang <[email-masked]>
Date: Fri, 10 Apr 2020 11:16:57 +0200

Hi David,

I replied inline:

> the evaluation section of our submission is attached to this mail.

Congrats on the published paper!

> cell allocation, it takes longer to reach that maximum than with higher

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.

> 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?

> 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

-- 
——————————————————————————————————————
Stay healthy, stay optimistic!

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tchang.org/
——————————————————————————————————————

---

From: David Hauweele <[email-masked]>
Date: Tue, 21 Apr 2020 18:16:32 +0200

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,

On Fri, 10 Apr 2020 11:16:57 +0200
Tengfei Chang <[email-masked]> wrote:

> Hi David,
> 
> I replied inline:
> 
> On Fri, Apr 10, 2020 at 12:27 AM David Hauweele
> <[email-masked]> wrote:
> 
> > Dear 6TiSCH,
> >
> > 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.
> >
> 
> > 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.
> >
> 
> 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?
> 
> >
> > 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.
> >
> 
> Referring to the MSF standardization process , as said by Pascal, we
> won't be able to made big changes.