Re: [6tisch] Questions on TSCH CSMA-CA retransmission algorithm in IEEE 802.15.4-2015

Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr> Thu, 14 June 2018 21:55 UTC

Return-Path: <yasuyuki.tanaka@inria.fr>
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 EDFEF130F33 for <6tisch@ietfa.amsl.com>; Thu, 14 Jun 2018 14:55:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 lkaRwAOTISCx for <6tisch@ietfa.amsl.com>; Thu, 14 Jun 2018 14:55:45 -0700 (PDT)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99887130EB8 for <6tisch@ietf.org>; Thu, 14 Jun 2018 14:55:44 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.51,224,1526335200"; d="scan'208";a="331873492"
Received: from poi92-3-88-190-144-98.fbxo.proxad.net (HELO [192.168.1.14]) ([88.190.144.98]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jun 2018 23:55:41 +0200
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
From: Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr>
In-Reply-To: <CADJ9OA-0BS27QHO1dE_RHnNjKYZuzauuhi7nLEgrDHBGfX4D5g@mail.gmail.com>
Date: Thu, 14 Jun 2018 23:54:58 +0200
Cc: Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr>, 6TiSCH WG <6tisch@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A0602E7C-9664-43D0-968A-DF02A4DB4D84@inria.fr>
References: <FC00A9BD-16FC-4E54-8B73-C76CAA035138@inria.fr> <4391DBCC-ABC5-4F39-9BC2-2BD9E184EE5F@unistra.fr> <B58B8AF6-BFC0-46F1-9846-1D4F8E8ECD91@inria.fr> <CADJ9OA-0BS27QHO1dE_RHnNjKYZuzauuhi7nLEgrDHBGfX4D5g@mail.gmail.com>
To: Thomas Watteyne <thomas.watteyne@inria.fr>
X-Mailer: Apple Mail (2.3445.8.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/kRz_DLpT0SHBD6kQJ0uZXCa7AWI>
Subject: Re: [6tisch] Questions on TSCH CSMA-CA retransmission algorithm in IEEE 802.15.4-2015
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.26
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, 14 Jun 2018 21:55:47 -0000

Thank you for your comment, Thomas!

> On Jun 14, 2018, at 18:30, Thomas Watteyne <thomas.watteyne@inria.fr> wrote:
> 
> I agree with Fabrice's comments, that's how I read the document.

>> the backoff window is selected randomly between 0 and 2^BE-1. 

I may miss something, but I don't think so....

My understanding right now is:

[basics]
- "the backoff window" means the range between 0 and 2^BE -1 
- "the retransmission backoff wait" (delay before the next retransmission) is chosen randomly in the backoff window
- the minimum value of BE is macMinBE; the minimum backoff window is the range between 0 and 2^macMinBE - 1
- the maximum value of BE is macMaxBE; the maxmum backoff window is the range between 0 and 2^macMaxBE - 1 
- after resetting the backoff window, the length of the backoff windows is 2^macMinBE - 1 long
- only first-attempt transmission (non-retransmission) failures in *shared* cells can trigger the retransmission algorithm

[how the backoff window changes as per page-64]
- the backoff window increases for each consecutive failed transmission in a shared link
- the backoff window is reset by
  <rule-1> a transmission success in a shared link
  <rule-2> a transmission success in a dedicated link, which makes the TX queue empty
- the backoff window is NOT reset by
  <rule-3> a transmission failure a dedicated link
  <rule-4> a transmission success in a dedicated link, which doesn't make the TX queue empty

On page-66, it says, "A device upon encountering a transmission failure in a shared link shall initialize the BE to macMinBe." In other words,

  <rule-5>  the backoff window is reset by a first-attempt transmission failure, a failure of non-retransmission, in a *shared* link

Supposing that there are two frames in the TX queue and the retransmission process for one of the frames ends with a transmission success in a dedicated link, the backoff window could remain larger than 2^macMinBE - 1 <rule-4>. Then, if a device starts another retransmission process for the next frame in the TX queue by a transmission failure in a shared link, the device resets the backoff window <rule-5>. 

I think, what made me confused is that rule-4 part. I couldn't see why the device should keep the backoff window by rule-4. The backoff window isn't used for the first-attempt transmission for the second frame because it's not part of the retransmission algorithm. So, the backoff window is just reset when the retransmission process starts even though the window size is kept by rule-4... 

If rurle-2 and rule-4 ware written as below, it would make sense:

- the backoff window is reset by
  <rule-1> ...
  <rule-2'> a transmission success in a dedicated link, the transmission is for a frame under a retransmission process

- the backoff window is NOT reset by
  <rule-3> ...
  <rule-4'> a transmission success in a dedicated link, the transmission is for a frame which is NOT one under a retransmission process
  <rule-5> ...

However, we don't need rule-2' because the backoff window is reset when starting a retransmission process, anyway.

Yes, I'm still confused a little bit... (>_<)

Best,
Yatch