Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 467D212083E for <6tisch@ietfa.amsl.com>; Thu, 17 Oct 2019 00:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.003 X-Spam-Level: *** X-Spam-Status: No, score=3.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vgSbMRXCghn for <6tisch@ietfa.amsl.com>; Thu, 17 Oct 2019 00:29:27 -0700 (PDT) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEDF712083D for <6tisch@ietf.org>; Thu, 17 Oct 2019 00:29:26 -0700 (PDT) Received: by mail-pg1-x535.google.com with SMTP id i76so832427pgc.0 for <6tisch@ietf.org>; Thu, 17 Oct 2019 00:29:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lPdn0PBjXItN39OXsY1M3IRHbrAUmqugyFrDHeOOKVU=; b=HnL2PNPZcY6REqRgVWZStaoOewqm/iilKqdo9XIvN3UDVvxgR6LQERU3MMgglUL1k1 XMBJDsDDamYPpR2kMh7gZm7pL13z4xXzwLaTXCLugVWZjUzcSC398TZ0So4AU6yWE01B 85OFLjBMD6XKWkLKZsItpW1qL8b8xD9HqSeiHB3q2jGMMAWb9oYrH/fbh4nyFOhDYFty +kwVFd/+Kk4tDC/Lbdw6cVmaGb+6zSaOsolKJZwpeRvt/FteYGtTkB8qvejm6m3lmegK RQTPqhcdcyQ+ooslxtiIiPXRV67pxuoIVCspcRE/rVAZ9OXsuas6lC5ELsnbLHfmDxLL 6gHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lPdn0PBjXItN39OXsY1M3IRHbrAUmqugyFrDHeOOKVU=; b=kefGM3qQ4CF19z4WIH+8UcJL0urpFStysCHDqTEazDWq4JUpae4KBqUcc+z8k7gweJ QO3DH8w2es6mP6SSr7QM3S1DjLDaPQpHqc6Otv3t6MTzm37gK4lOC9afxmdLAWx2uSQF gWmCJSscqVNKw6lR7OIa7yTr5GZzo+tjqwlUSdB8qKFRmCddepcXAHVwr7PeaIzLDwyQ VQNwb4lEOSfJNofObowk637iPwQWgwo0wzS1KeL8kHluPmeVwAvWHXji4e0IDL9cu5Tr 9E0XHbUPEub9V/zQ+uyhKWH5TXViBe5cnxeohHjNN7jNgbfsJOKejkJzASWFLVzVlXBx jdlA== X-Gm-Message-State: APjAAAUNe3GHZlBH5RlcpD+3d/AbEb9VB5w+wqimOeHB9HRAJ2ZUOTid 3utFpMyPZeypFWL2Bcuh6XXdi1rZaKr7Rc598DM= X-Google-Smtp-Source: APXvYqyC25k2OQ0ZTk4l9iqhUTCpmUTydtbSHkxlqYqVCk9ogTV3z/XgetFmyBe7N9QHxPCKbptQx+oUmbxEUip5t18= X-Received: by 2002:a63:690:: with SMTP id 138mr2635776pgg.308.1571297366054; Thu, 17 Oct 2019 00:29:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tengfei Chang Date: Thu, 17 Oct 2019 09:29:13 +0200 Message-ID: To: ryanranario1.paderna@toshiba.co.jp Cc: 6tisch <6tisch@ietf.org> Content-Type: multipart/alternative; boundary="000000000000571bac0595162d5e" Archived-At: Subject: Re: [6tisch] validating the downstream traffic adaptation in draft-ietf-6tisch-msf-06 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2019 07:29:29 -0000 --000000000000571bac0595162d5e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable That's exactly what happened :-) On Thu, Oct 17, 2019 at 9:22 AM wrote: > Hi Tengfei, > > > > Thank you for your prompt reply. > > > > >It's calculated for all Tx cells, but since there is no auto tx cell whe= n > 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 > *Sent:* Wednesday, October 16, 2019 7:05 PM > *To:* paderna ryan ranario(=E3=83=91=E3=83=87=E3=83=AB=E3=83=8A =E3=83=A9= =E3=83=A4=E3=83=B3 =E2=97=8B=EF=BC=B2=EF=BC=A4=EF=BC=A3=E2=96=A1=EF=BC=A3= =EF=BC=AE=EF=BC=AC) < > ryanranario1.paderna@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 > wrote: > > Hi Tengfei, > > > > First of all, thank you showing us the experiment results about downstrea= m > 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 a= re > 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"=3D256. That means "NumTx" will be divi= ded > by 2 if it hits 256. > > Yes. > > Based on the figure target_num_transmission, at first num_transmission hi= t > 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 experime= nt > 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 =3D 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 > *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 adaptatio= n > 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 les= s > 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 loa= d. > > > > 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 > > > > > -- > > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 > > > > Dr. Tengfei, Chang > > Postdoctoral Research Engineer, Inria > > > > www.tcahng.org > > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 > --=20 =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 Dr. Tengfei, Chang Postdoctoral Research Engineer, Inria www.tcahng.org =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 --000000000000571bac0595162d5e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That's exactly what happened :-)

On Thu, Oct 17, 2019= at 9:22 AM <ryanr= anario1.paderna@toshiba.co.jp> wrote:

Hi Tengfei,

=C2=A0

Thank you for your prompt reply.

=C2=A0

>It's calculated for all Tx ce= lls, but since there is no auto tx cell when there is negotiated cell in sc= hedule.

>The num_transmissions for target = is calculated for negotiated tx cells.

=C2=A0

I see. It make sense especially on th= e last sudden drop of target_num_transmissions in the figure.=

In this case, there is only one num_t= x_cell. It hit 256 then drop to 128.

=C2=A0

Thank you again.

=C2=A0

Ryan

=C2=A0

From: Tengfei Chang <tengfei.chang@gmail.com<= /a>>
Sent: Wednesday, October 16, 2019 7:05 PM
To: paderna ryan ranario(=E3= =83=91=E3=83=87=E3=83=AB=E3=83=8A =E3=83=A9=E3=83=A4=E3=83=B3 = =E2=97=8B=EF=BC=B2=EF=BC=A4=EF=BC=A3<= /span>=E2=96=A1=EF=BC=A3=EF=BC=AE= =EF=BC=AC) <ryanranario1.paderna@toshiba.co.jp>
Cc: 6tisch <= 6tisch@ietf.org>
Subject: Re: [6tisch] validating the downstream traffic adaptation i= n draft-ietf-6tisch-msf-06

=C2=A0

Hi Ryan,

=C2=A0

I replied inline:=

=C2=A0

On Wed, Oct 16, 2019 at 4:39 AM= <ryanranario1.paderna@toshiba.co.jp> wrote:

Hi Tengfei,

=C2=A0

First of all, thank yo= u showing us the experiment results about downstream traffic adaptation for= MSF. It was very helpful.

=C2=A0

I would like to ask si= mple questions about it. About the "num_transmissions" in the fig= ure, 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.

=C2=A0

1. If the "num_tr= ansmission" is ping:

I assumed that "num_transmissions" is number of pi= ng 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.

=C2=A0

It's not this case.=C2=A0

=C2=A0

2. If the "num_tr= ansmission" is "NumTx":

It's more like this case, b= ut "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.=C2=A0=

I also assumed that the "MAXNUMTX"=3D256. That mea= ns "NumTx" will be divided by 2 if it hits 256.

Yes.

Based on the figure target_num_transmission, at first num_tr= ansmission hit around 256 but did not decrease to 128 (instead it decreased around 150). There are also multiple sudden d= ecrease when the num_transmission is less than or higher than 256. Is it be= cause num_transmissions in this experiment was calculated for all negotiate= d 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.

=C2=A0

While the NumTx in Section 5.3 was calculated per cell?

=C2=A0num_transmissions =3D sum= (NumTx per tx cell)

=C2=A0

I also have a follow u= p 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 severa= l states such as checking the type of current slot, looking for packet to t= he target neighbor, load radio etc.
But I see why you ask the question, probably TSCH state machine is implemen= tation-specific term.=C2=A0 I will change it as following:

=C2=A0

NumCellsElapsed :=C2=A0 Counts the number of negotiated cel=
ls that have
=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 elapsed since the counter was initialized.=C2=A0 T=
his counter is
=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 initialized at 0. When the current cell is declare=
d as a 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0negotiated cell t=
o the preferred parent, NumCellsElapsed is 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0incremented by ex=
actly 1, regardless of whether the cell is 
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0used to transmit/=
receive a frame.

=C2=A0

4. Why the target node was chosen to be a neighbor of Dagroo= t out of 36 nodes in the network?=

The goal of the figure is to sh= ow the behaviors of downstream traffic adaptation.

Ping to a first hop node is suf= ficient to reach this goal.

Chose a node with multiple hoop= to dagroot=C2=A0 may introduce parent switch event along the route,=C2=A0<= u>

which is normal, but it may mak= e the figure not clear for showing the downstream adaptation behavior.=C2= =A0

Thank you.

Ryan Paderna

= =C2=A0

= =C2=A0

From: Tengfei Chang <ten= gfei.chang@gmail.com>
Sent: Wednesday, September 25, 2019 7:58 PM
To: 6tisch <= 6tisch@ietf.org>
Subject: [6tisch] validating the downstream traffic adaptation in dr= aft-ietf-6tisch-msf-06

=C2=A0

Hello, All,

=C2=A0

As in the MSF draft version 06,= we added the downstream traffic adaptation feature.

here I want to share the implem= entation result of this feature with OpenWSN=C2=A0

(I remember Pascal asked for th= is before as well :-) so here it is!)

=C2=A0

The setup:=

-------------

I had run OpenWSN 6TiSCH implem= entation on OpenTestbed with 36 nodes deployed in our office building.=C2= =A0

After the network formed. I sta= rt to ping one nodes in the network, specifically using the command:=C2=A0<= u>

ping=C2=A0 bbbb::12:4b00:14b5:b= 571 -w 2000 -t

( bbbb::12:4b00:14b5:b571=C2=A0= is the pinging target node's address)

This allows to generate ping tr= affic at 1 request /2 seconds.

The command stopped after aroun= d 25 mins.

=C2=A0

What to measure:<= /span>

-----------------------<= u>

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 (fo= r upstream traffic)

The result is shown in the atta= ched file.

=C2=A0

Explanation of the Result

-------------------------------= ---

You can check the following exp= lanation in case you have questions after checking the attached result file= ..

=C2=A0

General information:<= /u>

The slotframe length is 101 and= the slot duration is 20ms.=C2=A0

So traffic load of 1 packet/2se= conds requires roughly 1 cell per slotframe.=C2=A0

The ideal status for MSF is to = install 2 or 3 Tx cell for it, which results 50% or 33% cell usage.<= u>

=C2=A0

( num_transmissions figures)=

The upper figures shows the num= ber of transmission of dagroot (to target ) and target (to dagroot),which h= elps to understand the changes of num_tx_cells.=C2=A0=C2=A0

There are two reason why the nu= mber of transmission drops:

the tx cell is deleted so the s= tatistic of transmissions is gone

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

=C2=A0

( target_num_transmissions figu= re)=C2=A0=C2=A0

Expect the pinging traffic, the= target has a default application traffic of 1packet/30 seconds.<= /u>

=C2=A0

(dagroot_num_tx_cells figure)

The dagroot at beginning only u= ses the auto_tx_cell for sending the ping request to target.<= /span>

When the MSF running on TARGET=C2=A0node detected the incoming traffic from dagroot exceedin= g the=C2=A0LIM_NUMCELLSUSED_HIGH,=C2=A0

the=C2=A0TARGET=C2=A0node decided to install a Rx cell to dagroot=C2=A0 in its schedule (Tx cell on dagroot side)

=C2=A0

(target_num_tx_cells figure)=

Why is one=C2=A0 tx cells to da= groot deleted during the pinging?

By checking the raw data of the= experiment, we found that dagroot is in backoff status to the target, at t= he time to install its first Tx cell to target.

The packet waiting to transmit = out is the 6P response packet.

The situation causes the incomi= ng ping request packet is buffer'ed in the queue.<= /p>

=C2=A0

As a consequence,=C2=A0 the pin= g response traffic decreases because of the less incoming request packets,<= u>

which temporally makes the num = of cell used is lower than=C2=A0 LIM_NUMCELLSUSED_LOW and delete one cell.<= u>

=C2=A0

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.

=C2=A0

I believe these figures validat= ed the correctness of the downstream traffic adaptation in=C2=A0=C2=A0draft= -ietf-6tisch-msf-06

Let us know if there is anythin= g not clear for you.

=C2=A0

Tengfei

=C2=A0

--

Chang Tengfei,=

Postdoctoral Research Engineer, Inria


=C2=A0

--

=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=

=C2=A0

Dr. Tengfei, Chang

Postdoctoral Research Engineer, Inria

=C2=A0

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94



--
=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94

Dr. Tengfei, Chang
<= span style=3D"background-color:rgb(255,255,255)">Postdoctoral Research Engi= neer, Inria
=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=
--000000000000571bac0595162d5e--