[6tisch] Comments on draft-chang-6tisch-msf-00

Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr> Tue, 13 February 2018 17:13 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 3A4C612D84C for <6tisch@ietfa.amsl.com>; Tue, 13 Feb 2018 09:13:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id PvcJ_46A60QY for <6tisch@ietfa.amsl.com>; Tue, 13 Feb 2018 09:13:08 -0800 (PST)
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 622D912D84F for <6tisch@ietf.org>; Tue, 13 Feb 2018 09:13:07 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.46,508,1511823600"; d="scan'208";a="254672379"
Received: from unknown (HELO []) ([]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Feb 2018 18:13:05 +0100
From: Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Message-Id: <F6A8EC42-3727-4CBB-B683-A2EA2A9FAE75@inria.fr>
Date: Tue, 13 Feb 2018 18:13:04 +0100
Cc: Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr>
To: 6tisch@ietf.org
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/9Z5mNXEfPbJRZHdwLUEx2NKlWhE>
Subject: [6tisch] Comments on draft-chang-6tisch-msf-00
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 13 Feb 2018 17:13:11 -0000

Hi all,

I'd like to share my comments on draft-chang-6tisch-msf-00:


The first one is about 6P CLEAR after detecting unreachability to a neighbor.

> 3.8.  Step 7 - Neighbor Polling
> (snip)
>    When a neighbor is declared unreachable, the node MUST issue a 6P
>    CLEAR to that neighbor (which can fail at the link-layer), and MUST
>    remove all dedicated links with that neighbor from its own schedule.

Why does the node have to issue a 6P CLEAR to a neighbor which is determined to be unreachable...? It just wastes time and energy of the initiator since this transaction will fail as the draft mentioned. I think it'd be fine to remove all the dedicated cells to the unreachable neighbor without 6P CLEAR. By the way, the term "cells" should be used instead of "links".

Other comments are trivial.

> 1.  Introduction
> (snip)
>    MSF is designed to operate in a wide range of application domains.
>    It is optimized for applications with regular upstream traffic (from
>    the nodes to the Internet).  

"The internet" sounds too specific. "From the nodes toward the root" would be better?

> 2.  Interface to the Minimal 6TiSCH Configuration
> (snip)
>    MSF uses the minimal cell to exchange the following packets:
> ...
>    4.  The first 6P packet a node issues to a neighbor it doesn't have
>        dedicated cells to, as defined by
>        [I-D.ietf-6tisch-6top-protocol].  These are unicast frames.

The minimal cell is used for not only the first 6P packet but also subsequent packets associated with a 6P transaction initiated by the first packet. In this sense, I'd like to propose to replace it with:

   6P packets to schedule the first dedicated cell with a neighbor. There are unicast frames.

> 7.  Rules for CellList
>    MSF uses 2-step 6P Transactions exclusively.  6P Transactions are
>    only initiated by a node towards it preferred parent.  As a result,
>    the cells to put in the CellList of a 6P ADD command, and in the
>    candidate CellList of a RELOCATE command, are chosen by the node.  In
>    both cases, the same rules apply:
>       the CellList SHOULD contain 5 or more cells.
>       Each cell in the CellList MUST have a different slotOffset value.
>       For each cell in the CellList, the node MUST NOT have any
>       scheduled cell on the same slotOffset.
>       The slotOffset value of any cell in the CellList MUST NOT be the
>       same as the slotOffset of the minimal cell (slotOffset=0).
>       The slotOffset of a cell in the CellList SHOULD be randomly and
>       uniformly chosen among all the slotOffset values that satisfy the
>       restriction above.
>       The channelOffset of a cell in the CellList SHOULD be randomly and
>       uniformly in [0..numFrequencies] where numFrequencies represents
>       the number of frequencies a node can communicate on.

Is this a format error...?

> 8.  6P Timeout Value
>    The 6P Timeout is not a constant value.  It is calculated a (C/

I think it'd be better for a variable name to start with a non-numeric character even in a document.

That's it!