Re: [6tisch] call for review: draft-ietf-6tisch-msf-04

Tero Kivinen <kivinen@iki.fi> Mon, 22 July 2019 15:35 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 285341202B0 for <6tisch@ietfa.amsl.com>; Mon, 22 Jul 2019 08:35:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.419
X-Spam-Level:
X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, 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 tmxyhN_1Ahy5 for <6tisch@ietfa.amsl.com>; Mon, 22 Jul 2019 08:35:30 -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 5A089120288 for <6tisch@ietf.org>; Mon, 22 Jul 2019 08:35:30 -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 x6MFZOuE006250 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 22 Jul 2019 18:35:24 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x6MFZN9u015353; Mon, 22 Jul 2019 18:35:23 +0300 (EEST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-ID: <23861.55227.955362.143308@fireball.acr.fi>
Date: Mon, 22 Jul 2019 18:35:23 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Cc: Tengfei Chang <tengfei.chang@gmail.com>, "6tisch@ietf.org" <6tisch@ietf.org>
In-Reply-To: <MN2PR11MB35659388E8B5FF663164A13FD8C90@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <CAAdgstQHZ8KCtfLx+dmU=F2SLtvE1HTeSGJU8i2GPo7_798i3g@mail.gmail.com> <MN2PR11MB356563F2C214702BCE2E4E9BD8FA0@MN2PR11MB3565.namprd11.prod.outlook.com> <CAAdgstR=A7=Kxi4=GPZyFVrPse4DUc67ePoumB2AdquKdELN3A@mail.gmail.com> <MN2PR11MB3565C73190BA0063B9972DAED8F60@MN2PR11MB3565.namprd11.prod.outlook.com> <CAAdgstTB051qELAKSaqsJB-1Jek5QKDx1AFXXkX_VK0nnzoGvA@mail.gmail.com> <MN2PR11MB3565254F897A295D78A334BFD8F00@MN2PR11MB3565.namprd11.prod.outlook.com> <CAAdgstQWTbgtE78mHXny8LaqQf9gQdfYwD2bhuf4BC9py8UU-A@mail.gmail.com> <MN2PR11MB35651E7876A925871BC6A13DD8C90@MN2PR11MB3565.namprd11.prod.outlook.com> <CAAdgstQBQ4=oqKVB0R-JiOt6YC8s9oXAOhpGet2KLGUJqgVo0g@mail.gmail.com> <MN2PR11MB35659388E8B5FF663164A13FD8C90@MN2PR11MB3565.namprd11.prod.outlook.com>
X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd)
X-Edit-Time: 10 min
X-Total-Time: 10 min
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/aXeJgC6RCfXXmJDWHKNsuSx3kzU>
Subject: Re: [6tisch] call for review: draft-ietf-6tisch-msf-04
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: Mon, 22 Jul 2019 15:35:33 -0000

Pascal Thubert (pthubert) writes:
> In a 6TiSCH network, CCA is useless between synchronized devices because
> they’ll talk at the same time. So LBT must be done some other way.

Note, that 802.15.4 do allow doing CCA if TschCca was set on when
MLME-TSCHE-MODE.request primitive is called to turn TSCH mode on. In
that case the node will do CCA at macTsCcaOffset time for macTsCca,
and all this is done before the actual macTsTxOffset happens, i.e.,
before the node is supposed to send its frame. This CCA does not
protect against other nodes in the TSCH, but it will protect against
other users on the same band, thus it should be enough for the legal
LBT requirements.

See figure 6-30 of 802.15.4-2015 in Section 6.5.4.1 and Section
6.2.5.2 covering TSCH CCA algorithm.

> The bright side is that the future collision can be detected before it even
> happens. Doing CCA on cells before allocating them, etc… I think you must
> provide a method for that. A trade off would be to provide that method in the
> draft and make it optional.

Note, that doing CCA on cells is bit pointless, as that will only
detect someone inside the same syncronized network using that slot, it
will not detect anybody else. I think it would be better to get
information of allocated slots from some kind of centralized node,
keeping track of nodes allocated and making sure there is no
collisions inside that one network.

Also, you cannot use the normal TSCH CCA for that, as it is done
BEFORE the actual time for TSCH frame to be sent on the channel. I do
not think there is a good way to do that specified in the 802.15.4. In
theory you could do it by configuring the specific slot for receiving
before starting to use it for transmission, and enabling promiscuous
mode, so you get all frames even when they are not addressed to you.

So requiring such feature to be provided for 6TiSCH to work, might
make it so that not all radios can do this, depending how much of TSCH
is actually implemented on MAC and how much is implemented in upper
layer.
-- 
kivinen@iki.fi