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. 2. If the "num_transmission" is "NumTx": In the experiment, I assumed that there is no parent switch because "NumTx" did not reset to 0 (section 5.3). I also assumed that the "MAXNUMTX"=256. That means "NumTx" will be divided by 2 if it hits 256. 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? While the NumTx in Section 5.3 was calculated per 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"? 4. Why the target node was chosen to be a neighbor of Dagroot out of 36 nodes in the network? Thank you. Ryan Paderna From: Tengfei Chang <[email protected]> Sent: Wednesday, September 25, 2019 7:58 PM To: 6tisch <[email protected]> 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
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
