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

Tero Kivinen <kivinen@iki.fi> Sat, 06 October 2018 01:28 UTC

Return-Path: <kivinen@iki.fi>
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 11233130DC3 for <6tisch@ietfa.amsl.com>; Fri, 5 Oct 2018 18:28:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.421
X-Spam-Level:
X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779] 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 bEQ6rDsNL9Q0 for <6tisch@ietfa.amsl.com>; Fri, 5 Oct 2018 18:28:24 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 22B75126F72 for <6tisch@ietf.org>; Fri, 5 Oct 2018 18:28:23 -0700 (PDT)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id w961SJD3028384 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 6 Oct 2018 04:28:19 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id w961SJX6012214; Sat, 6 Oct 2018 04:28:19 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <23480.4019.122928.340023@fireball.acr.fi>
Date: Sat, 06 Oct 2018 04:28:19 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr>
Cc: 6tisch@ietf.org
In-Reply-To: <B1743E04-02E9-4A90-9C36-7CBD6B4A9ADF@inria.fr>
References: <FC00A9BD-16FC-4E54-8B73-C76CAA035138@inria.fr> <23338.24307.310204.951524@fireball.acr.fi> <3DD8D1A9-9A2C-4D95-A8F5-3773F2E3FF53@inria.fr> <4C7D8FC5-1228-4693-8A8F-F24AF5765F6B@inria.fr> <23340.65260.93293.26087@fireball.acr.fi> <51985800-E995-438D-A691-00B483C7CBD0@inria.fr> <B1743E04-02E9-4A90-9C36-7CBD6B4A9ADF@inria.fr>
X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd)
X-Edit-Time: 10 min
X-Total-Time: 18 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/ca_kcE8GnDZHWuWQlQxDItj8Py4>
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.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: Sat, 06 Oct 2018 01:28:27 -0000

Yasuyuki Tanaka writes:
> I came across another question on the retransmission algorithm.
> Could you help...? 
> 
> What should we do when a frame sent in an un-scheduled slot is not
> acknowledged? 
> 
> As you know, with the frame pending bit, we can send a frame even if
> we don't have a cell scheduled at that time (Section 7.2.1.3 of IEEE
> 802.15.4-2015). While I don't think the back-off wait is necessary
> in this case, this topic is not covered by IEEE 802.15.4-2015... 

The frame pending bit operations in TSCH is bit underspecified in the
802.15.4-2015. We do have comment CID 93 about that in the current
letter ballot. The TG4md documents can be found from [1] and there is
consolidated comments from the last letter ballot [2], and from there
you can find the CID 93 that is talking about the frame pending bit on
TSCH.

This rewrite will most likely add some more text there specifying what
link scheduled means, and when to send the pending bit and so on, I
will make sure it also covers the case where there is no ACK.

My guess is that if there is no ACK, then you abort sending further
frames, and move to the normal TSCH operation, i.e., the
retransmission happens using normal rules.

The reason why we do not have ACK, could be:

1) Transmitted frame did not reach recipient. In this case recipient
will time out as it is not receiving any frames in timeslot even when
the frame pending bit was on on previous frame, so it should most
likely stop listening on that channel and resume operations.

2) Transmitted frame did reach other end, but the ACK did not reach
back. In this case the recipient will process the frame, and if that
frame it received has frame pending bit on, it will stay on this
channel for next frame.

The transmitter has no idea which of those two things happened, thus
only safe thing it can do is to abort also and continue normal
schedule.

But, that is just my guess what should happen, I am not sure what
implementations do, and I do not think we have text in standard
describing exactly what to do.

[1] https://mentor.ieee.org/802.15/documents?is_group=04md
[2] https://mentor.ieee.org/802.15/dcn/18/15-18-0433-06-04md-lb150-consolidated-comments.xlsx
-- 
kivinen@iki.fi