That's exactly what happened :-) On Thu, Oct 17, 2019 at 9:22 AM <ryanranario1.pade...@toshiba.co.jp> wrote:
> 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 <tengfei.ch...@gmail.com> > *Sent:* Wednesday, October 16, 2019 7:05 PM > *To:* paderna ryan ranario(パデルナ ラヤン ○ＲＤＣ□ＣＮＬ) < > ryanranario1.pade...@toshiba.co.jp> > *Cc:* 6tisch <6tisch@ietf.org> > *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 <ryanranario1.pade...@toshiba.co.jp> > 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 <tengfei.ch...@gmail.com> > *Sent:* Wednesday, September 25, 2019 7:58 PM > *To:* 6tisch <6tisch@ietf.org> > *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 > > —————————————————————————————————————— > -- —————————————————————————————————————— Dr. Tengfei, Chang Postdoctoral Research Engineer, Inria www.tcahng.org ——————————————————————————————————————
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
