Hi Tengfei, Thank you for your prompt reply.
>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. I see. It make sense especially on the last sudden drop of target_num_transmissions in the figure. In this case, there is only one num_tx_cell. It hit 256 then drop to 128. Thank you again. Ryan From: Tengfei Chang <[email protected]> Sent: Wednesday, October 16, 2019 7:05 PM To: paderna ryan ranario(パデルナ ラヤン ○ＲＤＣ□ＣＮＬ) <[email protected]> Cc: 6tisch <[email protected]> Subject: Re: [6tisch] validating the downstream traffic adaptation in draft-ietf-6tisch-msf-06 Hi Ryan, I replied inline: On Wed, Oct 16, 2019 at 4:39 AM <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> Sent: Wednesday, September 25, 2019 7:58 PM To: 6tisch <[email protected]<mailto:[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 -- —————————————————————————————————————— Dr. Tengfei, Chang Postdoctoral Research Engineer, Inria www.tcahng.org<http://www.tcahng.org> ——————————————————————————————————————
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
