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

Tengfei Chang <tengfei.chang@gmail.com> Thu, 17 October 2019 07:29 UTC

Return-Path: <tengfei.chang@gmail.com>
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: <CAAdgstRP_3muMrXO+Oqq1X79XcO3V=3d5gSKg9k4K4F_A4WaHA@mail.gmail.com> <TYAPR01MB23358253BFE427104EEFD96998920@TYAPR01MB2335.jpnprd01.prod.outlook.com> <CAAdgstTg8bfzH1doPv+3+-j0WF_9vBBL8bnCR59UAKeUcLgUpQ@mail.gmail.com> <TYAPR01MB2335A497930BF963098F1841986D0@TYAPR01MB2335.jpnprd01.prod.outlook.com>
In-Reply-To: <TYAPR01MB2335A497930BF963098F1841986D0@TYAPR01MB2335.jpnprd01.prod.outlook.com>
From: Tengfei Chang <tengfei.chang@gmail.com>
Date: Thu, 17 Oct 2019 09:29:13 +0200
Message-ID: <CAAdgstRewgYY9=zJ=igZvderdrbkGvVcKVaMfzLkY_n16e62Vg@mail.gmail.com>
To: ryanranario1.paderna@toshiba.co.jp
Cc: 6tisch <6tisch@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000571bac0595162d5e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/OMxSS15mlINlBqySKmIWrBDhNnQ>
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: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Oct 2019 07:29:29 -0000

That's exactly what happened :-)

On Thu, Oct 17, 2019 at 9:22 AM <ryanranario1.paderna@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.chang@gmail.com>
> *Sent:* Wednesday, October 16, 2019 7:05 PM
> *To:* paderna ryan ranario(パデルナ ラヤン ○RDC□CNL) <
> 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 <ryanranario1.paderna@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.chang@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
——————————————————————————————————————