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

Tengfei Chang <tengfei.chang@gmail.com> Fri, 09 August 2019 11:04 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 9F92212014B for <6tisch@ietfa.amsl.com>; Fri, 9 Aug 2019 04:04:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 5Vjnf6Zkt2q9 for <6tisch@ietfa.amsl.com>; Fri, 9 Aug 2019 04:04:47 -0700 (PDT)
Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (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 BB4911200E0 for <6tisch@ietf.org>; Fri, 9 Aug 2019 04:04:47 -0700 (PDT)
Received: by mail-pg1-x529.google.com with SMTP id r26so9746487pgl.10 for <6tisch@ietf.org>; Fri, 09 Aug 2019 04:04:47 -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=kY5OPkfjM8af0I5q06Tpz8vK1nvS7b8+0+k9SFdLqYU=; b=S4DYfTRphxOhG9LI6uDy46jR0HK4ZaoAZdqPasNMdiZEIH78oyQEQw/3GAAU2K/IM4 XZVs+1hWnAhRBeOcG4YCEszMWBhXm9GSeqJ9ot51mbh53uYlCgFoBQ9eqNKrv0S+N+uy S4biIxlIcth5htzIsGGmtYG4n3vAt2NzpPqAQYydBdiPL7pVMo57UTIqPZtOAAXEbwkK tBVTIdFFbUblMot5iKkGoY6QEN5dIpN7N1x66DNyc32soRT5t8+uJE3+JH0dHAu/oEPK CP4V06RbJJ1/YafGFJGySPfGfnvafcG5ps0gkak2tXjTSdW/Kk6qUZaWA7ggKRstP25U vUnQ==
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=kY5OPkfjM8af0I5q06Tpz8vK1nvS7b8+0+k9SFdLqYU=; b=N90b9Q6udx3Mu+kN4E/LTtXGgcRjZMXeHDFQhg2VTFNxPUK63H1E4CBxciaFUVi5Ia Ic4DNRSnebFYPeEUmH9yaCT14DlPB3FrGDIXoFTHpioMNxO31vDk1nlZrR74Z+WMh8+L 8WG/muvlLeqd6znXj24O/bltR4CeBAYM6rPW3LJZqQpGGWxKFhcfe+ZIvWucF4zNruH4 Od2CF6AEnKf6LyYD4t2oXT6hFUGUpsTNfbIneoZB1An3haLklkfwwT/GCEBKsiTDnCeU fJrAV9Bv8P4ZHO1XqURIw3E8+CSiiiVkGLHoPFHMpW0HQWljzCW2ftQ7kO33kWdiYEDi 26Mg==
X-Gm-Message-State: APjAAAUlV9U7cfmvObH4kWXmYz7vMLKFB/dHwjKrgZrbfkZNnh+lojql Nm0x+pdhKQoxcDLJ4jzMPcINkrPc8vVNfncZovU=
X-Google-Smtp-Source: APXvYqyTpdWzJMtvS9+sqEwfzL0gEtz/9TFinRx02h4+fqh+0C5NSCmk/ShJCrEea8ZH76so1HVCS+EvibVLFZ4/XNo=
X-Received: by 2002:a63:2b84:: with SMTP id r126mr17512623pgr.308.1565348686884; Fri, 09 Aug 2019 04:04:46 -0700 (PDT)
MIME-Version: 1.0
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> <23861.55227.955362.143308@fireball.acr.fi>
In-Reply-To: <23861.55227.955362.143308@fireball.acr.fi>
From: Tengfei Chang <tengfei.chang@gmail.com>
Date: Fri, 09 Aug 2019 13:04:36 +0200
Message-ID: <CAAdgstRKkxWPdqdnSZB758EhNWiowVtRMGTde9aF7nnho=_Uwg@mail.gmail.com>
To: Tero Kivinen <kivinen@iki.fi>
Cc: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, "6tisch@ietf.org" <6tisch@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006e7505058fad2476"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/cWp2BEg0uKbs7rHWfRhFEvdR1sY>
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: Fri, 09 Aug 2019 11:04:50 -0000

Thanks Tero and Pascal for the comments!

I understand What Pascal and Tero are saying. According to the discussion
above and during the IETF 105 6TiSCH meeting, I would add the following
content in the next version of the draft in Rule of Celllist section:

Since  the Cell is randomly selected, there is a non-zero chance that
several nodes in vicinity are using the same cells.
An implementer implements MSF MAY implement a CCA strategy to monitor the
Tx cell before using it to avoid this situation.
The node MAY configure the Tx cell to be installed as Rx cell to listen any
incoming frames.
Within a pre-defined time window, if there is no frames received, the Tx
cell will replace the Rx cell to transmit frames.

The content will be something like this, we can rephrase it later.

Please let me know what you think. Thanks!

Tengfei


On Mon, Jul 22, 2019 at 5:35 PM Tero Kivinen <kivinen@iki.fi> wrote:

> 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
>


-- 
Chang Tengfei,
Postdoctoral Research Engineer, Inria