[6tisch] validating the downstream traffic adaptation in draft-ietf-6tisch-msf-06

[Tengfei Chang <[e-mail]>]

Hello, All,

As in the MSF draft version 06, we added the downstream traffic adaptation
feature.
here I want to share the implementation result of this feature with OpenWSN
(I remember Pascal asked for this before as well :-) so here it is!)

The setup:
-------------
I had run OpenWSN 6TiSCH implementation on OpenTestbed with 36 nodes
deployed in our office building.
After the network formed. I start to ping one nodes in the network,
specifically using the command:

ping  bbbb::12:4b00:14b5:b571 -w 2000 -t
( bbbb::12:4b00:14b5:b571  is the pinging target node's address)

This allows to generate ping traffic at 1 request /2 seconds.
The command stopped after around 25 mins.

What to measure:
-----------------------
We measured the changes of the number of tx cells (num_tx_cells)

from dagroot to the target node ( for downstream traffic)

from target node to dagroot (for upstream traffic)

The result is shown in the attached file.

Explanation of the Result
----------------------------------
You can check the following explanation in case you have questions after
checking the attached result file.

General information:
The slotframe length is 101 and the slot duration is 20ms.
So traffic load of 1 packet/2seconds requires roughly 1 cell per slotframe.
The ideal status for MSF is to install 2 or 3 Tx cell for it, which results
50% or 33% cell usage.

( num_transmissions figures)
The upper figures shows the number of transmission of dagroot (to target )
and target (to dagroot),which helps to understand the changes of
num_tx_cells.
There are two reason why the number of transmission drops:

the tx cell is deleted so the statistic of transmissions is gone

the number transmission reaches to 256, it is then divided by 2 and changed
to  128.

( target_num_transmissions figure)
Expect the pinging traffic, the target has a default application traffic of
1packet/30 seconds.

(dagroot_num_tx_cells figure)
The dagroot at beginning only uses the auto_tx_cell for sending the ping
request to target.
When the MSF running on *TARGET *node detected the incoming traffic from
dagroot exceeding the LIM_NUMCELLSUSED_HIGH,
the *TARGET *node decided to install a Rx cell to dagroot  in its schedule
(Tx cell on dagroot side)

(target_num_tx_cells figure)
Why is one  tx cells to dagroot deleted during the pinging?
By checking the raw data of the experiment, we found that dagroot is in
backoff status to the target, at the time to install its first Tx cell to
target.
The packet waiting to transmit out is the 6P response packet.
The situation causes the incoming ping request packet is buffer'ed in the
queue.

As a consequence,  the ping response traffic decreases because of the less
incoming request packets,
which temporally makes the num of cell used is lower than
LIM_NUMCELLSUSED_LOW and delete one cell.

After the Tx cell is installed on the dagroot side, the MSF starts to adapt
the increased incoming traffic with a fluctuation (installed 3 Tx cells),
but change to 2 Tx cells, which is ideal for 1packet/2seconds traffic load.

I believe these figures validated the correctness of the downstream traffic
adaptation in  draft-ietf-6tisch-msf-06
Let us know if there is anything not clear for you.

Tengfei

-- 
Chang Tengfei,
Postdoctoral Research Engineer, Inria