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

[Tengfei Chang <[e-mail]>]

Hi Ryan,

I replied inline:

On Wed, Oct 16, 2019 at 4:39 AM <[e-mail]> wrote:

> Hi Tengfei,
>
>
>
> First of all, thank you showing us the experiment results about downstream
> traffic adaptation for MSF. It was very helpful.
>
>
>
> I would like to ask simple questions about it. About the
> "num_transmissions" in the figure, is it the number of ping transmitted? Or
> is it "NumTx" counter that counts the number of transmission attempts on
> the cell (Section 5.3 Handling Schedule Collisions)? Because of this, I
> divided my questions into two parts depending on the assumption.
>
>
>
> 1. If the "num_transmission" is ping:
>
> I assumed that "num_transmissions" is number of ping because of the label
> "1 packet/2seconds" which is rate of ping you are giving. However there are
> sudden decrease of "num_transmission" in the target_num_transmissions
> figure.
>

It's not this case.

>
>
> 2. If the "num_transmission" is "NumTx":
>
It's more like this case, but "NumTx" is a counter for one cell.
"num_transmission" here is like the sum of "NumTx" of all cells.

> In the experiment, I assumed that there is no parent switch because
> "NumTx" did not reset to 0 (section 5.3).
>
Yes.

> I also assumed that the "MAXNUMTX"=256. That means "NumTx" will be divided
> by 2 if it hits 256.
>
Yes.

> Based on the figure target_num_transmission, at first num_transmission hit
> around 256 but did not decrease to 128 (instead it decreased around 150).
> There are also multiple sudden decrease when the num_transmission is less
> than or higher than 256. Is it because num_transmissions in this experiment
> was calculated for all negotiated cells?
>
It's calculated for all Tx cells, but since there is no auto tx cell when
there is negotiated cell in schedule. The num_transmissions for target is
calculated for negotiated tx cells.

While the NumTx in Section 5.3 was calculated per cell?
>
 num_transmissions = sum(NumTx per tx cell)

I also have a follow up questions below:
>
> 3. About "NumCellsElapsed" in section 5.1 Adapting to Traffic. Can you
> explain about indication of TSCH state machine that increments the
> "NumCellsElapsed"?
>
For each slot, there are several states such as checking the type of
current slot, looking for packet to the target neighbor, load radio etc.
But I see why you ask the question, probably TSCH state machine is
implementation-specific term.  I will change it as following:

NumCellsElapsed :  Counts the number of negotiated cells that have
       elapsed since the counter was initialized.  This counter is
       initialized at 0. When the current cell is declared as a

       negotiated cell to the preferred parent, NumCellsElapsed is

       incremented by exactly 1, regardless of whether the cell is

       used to transmit/receive a frame.


4. Why the target node was chosen to be a neighbor of Dagroot out of 36
> nodes in the network?
>
The goal of the figure is to show the behaviors of downstream traffic
adaptation.
Ping to a first hop node is sufficient to reach this goal.
Chose a node with multiple hoop to dagroot  may introduce parent switch
event along the route,
which is normal, but it may make the figure not clear for showing the
downstream adaptation behavior.

> Thank you.
>
> Ryan Paderna
>
>
>
>
>
> *From:* Tengfei Chang <[e-mail]>
> *Sent:* Wednesday, September 25, 2019 7:58 PM
> *To:* 6tisch <[e-mail]>
> *Subject:* [6tisch] validating the downstream traffic adaptation in
> draft-ietf-6tisch-msf-06
>
>
>
> 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
>


-- 
——————————————————————————————————————

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tcahng.org
——————————————————————————————————————