[6tisch] Comments on draft-ietf-6tisch-msf-02 - Re: draft-ietf-6tisch-msf-02.txt is published

Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr> Mon, 18 March 2019 14:50 UTC

Return-Path: <yasuyuki.tanaka@inria.fr>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9C11F12865E for <6tisch@ietfa.amsl.com>; Mon, 18 Mar 2019 07:50:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.402
X-Spam-Status: No, score=-4.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BITCOIN_SPAM_02=2.499, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id xTDVRRxsveJK for <6tisch@ietfa.amsl.com>; Mon, 18 Mar 2019 07:50:02 -0700 (PDT)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr []) (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 88BEB127598 for <6tisch@ietf.org>; Mon, 18 Mar 2019 07:50:01 -0700 (PDT)
IronPort-Data: A9a23:UMGXNKISmUvkRPXVFE//H55y081LeRNeAxfCVgivOUwrRnZC7fyCES MVLHCHavqbPk5/kJS8azhwi8BJeGL8sSCwzfsXcgLWgGPiUK2zKhxTXQzCgKOgh2A0QVeeRa bZR4qg/Kbf1ZozgCBQbGixd9/LLJuedjhJDI/TUhPABEZM6fJqWxUQck7cWjnLWt7VXCOMM1 N21pfWyizu1nM2j5PEBUjw3UVO/LHJ8lCDXgfqt/NQevkbw64T51kVnMrzZigxT8oIPue6Xl 9dty3mclFeYu1NaWXMwdfB9z3Pnpbl5QW/f7OsyUnTW8fOLFbK3T0WN3wd4TBECAS+h6A4k8 Pltr2EVaAjSZwnXBNQR4ZRpi1F1Q49iZzPDFrrUlvn9ag87ujx54OBo9gau6pCjojuzv+cXc gIQu4ouwEw83qJbtil7wD0Yzpix4oEHBolo7l3PAGzVvNdENpYzYM4sCzQZQTEFbz/Y/C54W NVtMsnICpUQN+RuEuqyrCAS5qnbixpDLaF4+NJW6kF7I8pie8XO8330hiLHfMJThBco/IcoO StcIA/cMtETYldDzlYSECFjdW5jK7rYnErdxQ6Tf8ADwzar8pdlz7f/Qqu1d3u+okPZpV1TW vPdy68hegZWUg/LwvzJRObxtqgsuHmhoJnQ2U7SYAxCFEs/ttJ4vRK/NTFb6z5edcqLu9jco F5v5gwPqJ0XcBNT61R3ikk0qnaoUc4P9wnj0RsJQ==
X-IronPort-AV: E=Sophos;i="5.58,494,1544482800"; d="scan'208";a="299832332"
Received: from wifi-pro-82-014.paris.inria.fr (HELO []) ([]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 18 Mar 2019 15:49:29 +0100
From: Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr>
To: 6tisch@ietf.org
Cc: yasuyuki.tanaka@inria.fr
References: <CAAdgstS-O33+0yVH4Aahknope74GeVZpyqwzp=f-P7QRcGctbw@mail.gmail.com>
Message-ID: <c1fed393-6355-1ed8-0611-86719aab8dd0@inria.fr>
Date: Mon, 18 Mar 2019 15:49:29 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3
MIME-Version: 1.0
In-Reply-To: <CAAdgstS-O33+0yVH4Aahknope74GeVZpyqwzp=f-P7QRcGctbw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/sCTV4atUCU9Zu6W13SYl00qEcXo>
Subject: [6tisch] Comments on draft-ietf-6tisch-msf-02 - Re: draft-ietf-6tisch-msf-02.txt is published
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, 18 Mar 2019 14:50:06 -0000


Thank you, Tengfei and the other authors, for updating the draft!

I'm sharing my comments on the latest version.


[Security Consideration on autonomous SHARED cell allocation]

> 4.5.  Step 4 - Installing Autonomous Cells for each neighbor in neighbor
>       table
>    Because it has learnt the link-layer keying material used in the
>    network, the joined node can now decrypt any packets sent by its
>    neighbors.  Once a new neighbor is added to the neighbor table, a new
>    autonomous SHARED cell MUST be added to that neighbor.

As per the second sentence in this section, a JP MUST allocate an
autonomous SHARED cell to a pledge during its secure joining process.

Tengfei's email says no action required on the JP side, but the JP
need to have a neighbor table entry (neighbor cache entry) for the JP
in order to send back a join response, doesn't it? I may miss

tengfei> [Resolved. During join process, only pledge required to
tengfei> install autonomous SHARED cell to JP, no action required from
tengfei> JP side.]

If this is the case, I would propose to add some note in Security
Considerations section where we mention risks of this kind allocation,
and may suggest a mitigation technique such as "on-demand allocation".

Basically this is the same comment as the first one in the following


[Join request packets can still increment NumCellUsed?]

tengfei> non-trusted packet shouldn't be accounted for for adapting
tengfei> traffic
tengfei> ====================
tengfei> Mention that the untrusted packet (e.g. join
tengfei> request/response) shouldn't be counted for adapting the
tengfei> traffic.  Issues link:
tengfei> https://github.com/twatteyne/draft-ietf-6tisch-msf/issues/15
tengfei>     [Resolved. clarified in adapting traffic section.]

I think this issue hasn't been resolved yet by the latest draft. I
expect text describing how to handle packets having code point AF42 or


[EB / DIO transmission rules]

I would propose to remove the third and fourth paragraphs mainly for
these two reasons:

- This is an implementation-specific optimization
- This is irrevalnt to the scheduling function itself

> 2.  Interface to the Minimal 6TiSCH Configuration
> (snip)
>    Because the minimal cell is SHARED, the back-off algorithm defined in
>    [IEEE802154-2015] is used to resolve collisions. To ensure there is
>    enough bandwidth available on the minimal cell, a node implementing
>    MSF SHOULD enforce the following rules for broadcast frames:
>    1.  send EBs on a portion of the minimal cells not exceeding
>        1/(3(N+1)), where N is the number of neighbors of the node.
>    2.  send any other broadcast packets on a portion of the minimal
>        cells not exceeding 1/(3(N+1)), where N is the number of
>        neighbors of the node.  For example, the broadcast DIO and DIS,
>        IPv6 Neighbor Discovery (ND)[RFC4861] and any other application
>        layer broadcast packets.
>    The RECOMMENDED behavior for sending EBs is to have a node send EBs
>    with a probability of 1/(3(N+1)).  The RECOMMENDED behavior for
>    sending DIOs is to use a Trickle timer with rate-limiting.  There is
>    no recommendation behavior for sending any other broadcast.  However,
>    the traffic portion of all broadcast packets on minimal cell, except
>    EBs, MUST not exceed 1/(3(N+1)).

Here is Xavi's comment on this:

xavi> here we place a SHOULD and not a MUST. We want to make sure the
xavi> network works as if there is over-use of the minimal cell
xavi> collapses. We think this should be said here so an adopter is
xavi> aware of the limitations and implements a working measure.


I'd like to hear what others think :-)

Aside from that, it's unclear how to implement "Trickle timer with
rate-limiting", and having such a modification to Trickle is
discouraged by RFC6206:


[SAX Configuration]

How can a mote know what values should be used for l_bit and r_bit? Do
we assume they are configured offline? Or they can be advertised in

> Appendix B.  Example of Implementation of SAX hash function
> (snip)
>    For interoperability purpose, the values of h0, l_bit and r_bit in
>    Step 1 and 2 are configured as:
>    o  h0 = 0
>    o  l_bit = 0
>    o  r_bit = 1
>    The appropriate values of l_bit and r_bit could vary depending on the
>    the set of motes' EUI64 address.  How to find those values is out of
>    the scope of this specification.

Additionally, it'd be nice to have test vectors of the SAX computation
with the set of parameters (h0=0, l_bit=0, r_bit=1) for

[Autonomous Cell]

We need a clearer description on the two types of the autonomous cell:

> 3.  Autonomous Cells
>    MSF nodes MUST initialize Slotframe 1 with a set of default cells for
>    unicast communication with their neighbors.  These cells are referred
>    to as 'autonomous cells', because they are maintained autonomously by
>    each node.  To distinguish from the autonomous cells, the cell
>    scheduled by 6P transaction is defined as 'managed cells'.  How to
>    schedule managed cells is detailed in Section 5.  For autonomous
>    cells, each node has:
>    o  One cell at a [slotOffset,channelOffset] computed as a hash of the
>       node's EUI64 (detailed next).  The cell options for this cell are
>       TX=1, RX=1, SHARED=0.
>    o  One cell at a [slotOffset,channelOffset] computed as a hash of the
>       EUI64 of the Join Proxy or each neighbor in the IPv6 neighbor
>       table (detailed in Section 4.4 and Section 4.5).  The cell options
>       for this cell are TX=1, RX=1, SHARED=1.

- put the labels of "autonomous non-SHARED cell" and "autonomous
   SHARED cell" to the itemization: the first one is "autonomous
   non-SHARED cell", the second one is "autonomous SHARED cell"

- tell what to set to NodeAddr (neighbor addresses) of these cells; I
   presume NodeAddr is not set for the autonomous non-SHARED cell, and
   the MAC address of the neighbor is set for the autonomous SHARED

I'd like to have some explanation why we can set SHARED=0 for the
autonomous non-SHARED cell whose slot offset and channel offset are
actually shared with its neighbors.


s/time offset/slot offset/
s/Joining Request/Join Request/


That's all.