Re: [6tisch] Thomas' review of draft-ietf-6tisch-msf-02

Tengfei Chang <tengfei.chang@gmail.com> Tue, 26 March 2019 13:57 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 8CA2F1202EC for <6tisch@ietfa.amsl.com>; Tue, 26 Mar 2019 06:57:26 -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_PASS=-0.001, URIBL_BLOCKED=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 sYlgQYwtzQFJ for <6tisch@ietfa.amsl.com>; Tue, 26 Mar 2019 06:57:19 -0700 (PDT)
Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 43D8A1202DC for <6tisch@ietf.org>; Tue, 26 Mar 2019 06:57:19 -0700 (PDT)
Received: by mail-pl1-x630.google.com with SMTP id bg8so1671443plb.0 for <6tisch@ietf.org>; Tue, 26 Mar 2019 06:57:19 -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=RTvCBu1mvpAnh2/aOWciMJePt34nKE2fuFK1Hd2GlRE=; b=c+rm6IdniqOmYIJ+y0apwPdHa3DD/7uRsct4dVOQ3+Z6pzyGUe63kvaRh3eIiieUhi 9HHJvknXbETcDzVuCPTc8VMIzMpaTGQdnPPzBQrNJ7t4vbrHZR9ttvByh/pF9DJYoVgl OZ5X72v2l9DX9t3LsxePrfv7f15pAzsMN9JIT4SY8Z2UFNT9bmSrGUhtbMl4F/Vh7YH1 HXi+RwUId4PGC3z0aHcODqcsM1QjNTAsB5UcbyhRq5ARWSj8IU3NR6vj+ZiKSXgQFGR0 mrettF6p2R9Ub7XbivdzIeyR/qUJPs5YHhFgS48AbsATI8phgPlnwfz2ZPe72DJc5HGo j5VQ==
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=RTvCBu1mvpAnh2/aOWciMJePt34nKE2fuFK1Hd2GlRE=; b=i6hyGiGL9pjVk57q0+1SLD85AD5xp0PFwaIq3xRf5V/Jbk+cUlGGx8mMpiUe0peKDu 1uma+N1ihy8FXTgbxvHAki9DuqqlIGjF/cow/ywF9A4S15SWpEe9bclIaFD7L+1SAAQQ GokUgspscLpV5Xya09bsyiTVyYiv9W2M6Pw+2UoV55J1atW/c9FQ4Sd4gIycj3ce81SE gtSYWk0Y5xlcpnk2BciI49AaHYOFP/ITIm8uDpsMgGc36Lf98E8UVenKU/WzMiOUlRw0 fcrFMmm3bscxR7uWVo4NkpkNZZQ2FwHMAzbXGwiCUYxSMrLeOklxjUGm1XmMxFsClF+7 DTuQ==
X-Gm-Message-State: APjAAAXW2lGibkCNeUvwXxLHUUz8k2ETSVbTJYK6wr6Ea2jlB5xl/5hf Bj0SYOa9qOa3x4IU+tOYrmPSyy0qcZrezwsyVZk=
X-Google-Smtp-Source: APXvYqyI8ioVVNsUL2J5XxJbInHnjYjoGpmbM+v8omc4YsnoMFdYVZ8QBS2YNs0gqvUxySzdSYydfn8JjlyEfX6eAu8=
X-Received: by 2002:a17:902:bf07:: with SMTP id bi7mr8458773plb.87.1553608638175; Tue, 26 Mar 2019 06:57:18 -0700 (PDT)
MIME-Version: 1.0
References: <26484024.1122561.1553497091359.JavaMail.zimbra@inria.fr>
In-Reply-To: <26484024.1122561.1553497091359.JavaMail.zimbra@inria.fr>
From: Tengfei Chang <tengfei.chang@gmail.com>
Date: Tue, 26 Mar 2019 14:57:05 +0100
Message-ID: <CAAdgstQYTOH67jMMOCUtm-vS74KDQRvLGwe90fhh9etEqhUuLQ@mail.gmail.com>
To: Thomas Watteyne <thomas.watteyne@inria.fr>
Cc: 6tisch@ietf.org
Content-Type: multipart/alternative; boundary="000000000000ff9ed00584ffb21c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/XURoF6oD196bIUTuERm9a1PSMsI>
Subject: Re: [6tisch] Thomas' review of draft-ietf-6tisch-msf-02
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: Tue, 26 Mar 2019 13:57:26 -0000

Thanks for the comments! Generally, all comments are taken.

I will  fix them in the next version!

Tengfei

On Mon, Mar 25, 2019 at 7:59 AM Thomas Watteyne <thomas.watteyne@inria.fr>
wrote:

> Authors,
>
> Please find below my review of draft-ietf-6tisch-msf-02. It's a patch
> file to the txt version of the draft.
>
> You will find inline fixes of typos, and comments, which start at the new
> line with "TW>"
>
> Overall, the draft is in good shape. The recommendations I make are
> editorial. The biggest remark is that the draft mixes the terms "dedicated
> cells" and "managed cells". I also would like to see some text that
> describes the reasoning between "autonomous SHARED cells" and "autonomous
> non-SHARED cells". Also, because those terms are obscure, you could replace
> them throughout by "autonomous upstream cells" and  "autonomous
> downstream cells".
>
> Thomas
>
> =====
>
> diff --git
> "a/C:\\Users\\twatteyn\\AppData\\Local\\Temp\\TortoiseGit\\draft-ietf-6tisch-msf-02-54bdb6a.000.txt"
> "b/C:\\Users\\twatteyn\\Desktop\\ietf\\draft-ietf-6tisch-msf-02.txt"
> index 89514c6...49e59bb 100644
> ---
> "a/C:\\Users\\twatteyn\\AppData\\Local\\Temp\\TortoiseGit\\draft-ietf-6tisch-msf-02-54bdb6a.000.txt"
> +++ "b/C:\\Users\\twatteyn\\Desktop\\ietf\\draft-ietf-6tisch-msf-02.txt"
> @@ -135,10 +135,9 @@ Internet-Draft  6TiSCH Minimal Scheduling Function
> (MSF)      March 2019
>
>     The 6TiSCH Minimal Scheduling Function (MSF), defined in this
>     specification, is a 6TiSCH Scheduling Function (SF).  The role of an
> -   SF is entirely defined in [RFC8480]: it complements [RFC8480] by
> +   SF is entirely defined in [RFC8480]. This specification complements
> [RFC8480] by
>     providing the rules of when to add/delete cells in the communication
> -   schedule.  The SF defined in this document follows that definition,
> -   and satisfies all the requirements for an SF listed in Section 4.2 of
> +   schedule.  This specification satisfies all the requirements for an SF
> listed in Section 4.2 of
>     [RFC8480].
>
>     MSF builds on top of the following specifications: the Minimal IPv6
> @@ -153,11 +152,11 @@ Internet-Draft  6TiSCH Minimal Scheduling Function
> (MSF)      March 2019
>     the 7 steps described in Section 4.  The end state of the join
>     process is that the node is synchronized to the network, has mutually
>     authenticated to the network, has identified a preferred routing
> -   parent, has scheduled one default managed unicast cell (defined in
> +   parent, and has scheduled one default managed unicast cell (defined in
>     Section 5.1) to/from its preferred routing parent.  After the join
>     process, the node can continuously add/delete/relocate cells, as
>     described in Section 5.  It does so for 3 reasons: to match the link-
> -   layer resources to the traffic, to handle changing parent, to handle
> +   layer resources to the traffic, to handle changing parent, or to handle
>     a schedule collision.
>
>     MSF is designed to operate in a wide range of application domains.
> @@ -172,18 +171,19 @@ Internet-Draft  6TiSCH Minimal Scheduling Function
> (MSF)      March 2019
>
>     the nodes to the root).  Appendix C contains a performance evaluation
>     of MSF.
> +TW> I would remove this sentence, as Appexdix C might be removed
>
>     This specification follows the recommended structure of an SF
> -   specification in Appendix A of [RFC8480], with the following
> +   specification, given in Appendix A of [RFC8480], with the following
>     adaptations:
>
> -   o  We have reordered part of the sections, in particular to have the
> -      section on the node behavior at boot Section 4 appear early in
> +   o  We have reordered some sections, in particular to have the
> +      section on the node behavior at boot (Section 4) appear early in
>        this specification.
>     o  We added sections on the interface to the minimal 6TiSCH
> -      configuration Section 2, the use of the SIGNAL command Section 6,
> -      the MSF constants Section 14, the MSF statistics Section 15, the
> -      performance of MSF Appendix C.
> +      configuration (Section 2), the use of the SIGNAL command (Section
> 6),
> +      the MSF constants (Section 14), the MSF statistics (Section 15),
> and the
> +      performance of MSF (Appendix C).
>     o  This specification does not include an examples section.
>
>  2.  Interface to the Minimal 6TiSCH Configuration
> @@ -193,8 +193,9 @@ Internet-Draft  6TiSCH Minimal Scheduling Function
> (MSF)      March 2019
>     shared cell providing minimal connectivity between the nodes in the
>     network.  The MSF implementation provided in this specification is
>     based on the implementation of the Minimal 6TiSCH Configuration.  An
> -   implementor with full-awareness of the Minimal 6TiSCH Configuration
> +   implementor with full awareness of the Minimal 6TiSCH Configuration
>     implications MAY implement MSF without it.
> +TW> I don't understand the statement "with full awareness of the Minimal
> 6TiSCH Configuration". Rephrase.
>
>     MSF uses the minimal cell to exchange the following packets:
>
> @@ -203,6 +204,7 @@ Internet-Draft  6TiSCH Minimal Scheduling Function
> (MSF)      March 2019
>     2.  DODAG Information Objects (DIOs), defined by [RFC6550], with
>         broadcast type.  Unicast type DIOs SHOULD NOT be sent on minimal
>         cell.
> +TW> just say "broadcast DIOs" and "unicast DIO". "Broadcast type" doesn't
> mean much.
>
>     Because the minimal cell is SHARED, the back-off algorithm defined in
>     [IEEE802154-2015] is used to resolve collisions.  To ensure there is
> @@ -214,7 +216,7 @@ Internet-Draft  6TiSCH Minimal Scheduling Function
> (MSF)      March 2019
>     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
> +       IPv6 Neighbor Discovery (ND) [RFC4861] and any other application
>         layer broadcast packets.
>
>
> @@ -229,8 +231,8 @@ Internet-Draft  6TiSCH Minimal Scheduling Function
> (MSF)      March 2019
>     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
> +   no recommended behavior for sending any other broadcast frame.
> However,
> +   the traffic portion of all broadcast frames on the minimal cell, except
>     EBs, MUST not exceed 1/(3(N+1)).
>
>     Section 4.3 describes how to evaluate the number of neighbors during
> @@ -240,31 +242,33 @@ Internet-Draft  6TiSCH Minimal Scheduling Function
> (MSF)      March 2019
>     As detailed in Section 2.2 of [RFC8480], MSF MUST schedule cells from
>     Slotframe 1, while Slotframe 0 is used for traffic defined in the
>     Minimal 6TiSCH Configuration.  The length of Slotframe 0 and
> -   Slotframe 1 SHOULD be the same value.  The default of
> +   Slotframe 1 SHOULD be the same value.  The default value of
>     SLOTFRAME_LENGTH is RECOMMENDED for both Slotframe 0 and Slotframe 1,
> -   although any value can be advertised in the EBs.
> +   although any value can be used, and advertised in the EBs.
> +TW> minimal is not required, yet there is a MUST here. I suggest you
> start this paragraph by a statement such as "If MSF is used together with
> the ..."
>
>  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
> +   unicast communication with their neighbors.
> +TW> remove the MUST?
> +   These cells are
> +   called "autonomous cells", because they are maintained autonomously by
> +   each node.  Cells
> +   scheduled by 6P transactions are called "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
> +   o  One cell at a [slotOffset,channelOffset] computed as a hash of its
> own 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
> +      EUI64 for each neighbor in the IPv6 neighbor
> +      table, including the Join Proxy (detailed in Section 4.4 and
> Section 4.5).  The cell options
>        for this cell are TX=1, RX=1, SHARED=1.
>
>     To compute a [slotOffset,channelOffset] from an EUI64 address, nodes
>     MUST use the hash function SAX [SAX-DASFAA].  The coordinates are
> -   computed to distribute the cells across all 16 channel offsets, and
> +   computed to distribute the cells across all channel offsets, and
>     all but the first time offsets of Slotframe 1.  The first time offset
>     is skipped to avoid colliding with the minimal cell in Slotframe 0.
>     The slot coordinates derived from a given EUI64 address are computed
> @@ -272,7 +276,7 @@ Internet-Draft  6TiSCH Minimal Scheduling Function
> (MSF)      March 2019
>
>     o  slotOffset(MAC) = 1 + hash(EUI64, length(Slotframe_1) - 1)
>     o  channelOffset(MAC) = hash(EUI64, 16)
> -
> +TW> don't you need a modulo operator here? THe hash function can return a
> very large number.
>
>
>
> @@ -282,11 +286,13 @@ Chang, et al.          Expires September 12, 2019
>            [Page 5]
>  Internet-Draft  6TiSCH Minimal Scheduling Function (MSF)      March 2019
>
>
> -   For interoperability purpose, an example how the hash function is
> +   For interoperability purposes, an example how the hash function is
>     implemented is detailed in Appendix B.
>
> -   Because of hash collisions, there are cases where the autonomous
> -   SHARED and non-SHARED cells are scheduled at the same time offset
> +   Because of hash collisions, there will be cases when the autonomous
> +   SHARED and non-SHARED cells
> +TW> what do you call "autonomous SHARED and non-SHARED cells"? Do you
> mean autonomous and managed cells?
> +   are scheduled at the same time offset
>     and/or channel offset.  Hash collisions among a set of cells at a
>     given time offset is resolved at run-time as follows:
>
> @@ -294,29 +300,33 @@ Internet-Draft  6TiSCH Minimal Scheduling Function
> (MSF)      March 2019
>        precedence.
>     o  If all SHARED cells have empty outgoing queues, the non-SHARED
>        cell takes precedence.
> +TW> please specify what you mena by SHARED and non-SHARED
>
>     Both SHARED and non-SHARED autonomous cells are scheduled to transmit
>     unicast packets.  The autonomous SHARED cells can only be used to
> -   transmit packets to the neighbor whose EUI64 address is used in hash
> -   function to create this cell.  The autonomous non-SHARED cells can be
> +   transmit packets to the neighbor whose EUI64 address is used in the
> hash
> +   function to schedule this cell.  Autonomous non-SHARED cells can be
>     used to transmit packet to any neighbors.  The traffic on the
>     autonomous cells are scheduled as:
>
> -   o  The Join Request MUST be sent on a SHARED cell, the 6P Request
> -      packet MAY be sent on a SHARED cell.
> -   o  The Join Response MUST be sent on a non-SHARED cell, the 6P
> -      Response packet MAY send on a non-SHARED cell.
> +   o  Join Request packets MUST be sent on SHARED cells.
> +   o  Join Response packets MUST be sent on non-SHARED cells.
> +   o  6P Request frames MAY be sent on SHARED cells.
> +   o  6P Response frames MAY be sent on non-SHARED cells.
>
>     Throughout the network lifetime, nodes MUST maintain the autonomous
>     cells as follows:
>
>     o  The non-SHARED cell MUST always remain scheduled.
> +TW> what do you mean?
>     o  Whenever a new IPv6 neighbor is discovered, add a SHARED cell for
>        it.
>     o  Whenever an IPv6 neighbor is removed, remove the SHARED cell that
>        was assigned to it.
>     o  6P CLEAR MUST NOT erase autonomous cells.
>
> +TW> The whole terminology of shared and non-shared autonomous cells is
> confusing, as it is used following a paragraph that explains that there are
> autonomous and managed cells. Please start by explaining, possibly with an
> example/diagram, what you mean.
> +
>  4.  Node Behavior at Boot
>
>     This section details the behavior the node SHOULD follow from the
> @@ -342,9 +352,10 @@ Internet-Draft  6TiSCH Minimal Scheduling Function
> (MSF)      March 2019
>
>     A node implementing MSF MUST implement the Minimal Security Framework
>     for 6TiSCH [I-D.ietf-6tisch-minimal-security].  As a corollary, this
> -   means that a pledge, before being switched on, is pre-configured with
> +   means that a pledge, before being switched on, may be pre-configured
> with
>     the Pre-Shared Key (PSK) for joining, as well as any other
>     configuration detailed in [I-D.ietf-6tisch-minimal-security].
> +   This is not needed if the node implements a security solution not
> based on PSKs, such as [draft-ietf-6tisch-dtsecurity-zerotouch-join].
>
>  4.2.  Step 1 - Choosing Frequency
>
> @@ -377,14 +388,15 @@ Internet-Draft  6TiSCH Minimal Scheduling Function
> (MSF)      March 2019
>     The decision of which neighbor to use as a JP is implementation-
>     specific, and discussed in [I-D.ietf-6tisch-minimal-security].
>
> -4.4.  Step 3 - Setting up Autonomous Cells during Join Process
> +4.4.  Step 3 - Setting up Autonomous Cells during the Join Process
>
> -   After selected the JP, nodes MUST set up their autonomous SHARED
> -   cells, as described in Section 3.  A Join Request is sent then by
> -   pledge to its JP.  The JP forwards the request/response between the
> -   JRC and the JP, possibly over multiple hops.  When JP received the
> -   Join Response from JRC, it sends a Join Response to the pledge, where
> -   the pledge learns the keying material used in the network, as well as
> +   After selected a JP, a node MUST set up autonomous SHARED
> +   cells to that JP, as described in Section 3.  A Join Request is then
> sent by the
> +   pledge to its JP.  The JP forwards the Join Request to the JRC,
> possibly over multiple hops.
> +   Similarly, the JRC sends the Join Response to the JP, possibly over
> multiple hops.
> +   When the JP receive the
> +   Join Response from the JRC, it sends that Join Response to the pledge.
> +   The pledge thereby learns the keying material used in the network, as
> well as
>     other configurations, and becomes a "joined node".  The Join Request
>
>
> @@ -394,31 +406,27 @@ Chang, et al.          Expires September 12, 2019
>            [Page 7]
>  Internet-Draft  6TiSCH Minimal Scheduling Function (MSF)      March 2019
>
>
> -   and Response traffics are happened on the autonomous cells, which are
> +   and Response traffic happens on autonomous cells, which are
>     scheduled as following:
>
> -   o  The Joining Request packet MUST be sent on the autonomous SHARED
> -      cell to the JP by the pledge.  A retransmition with backoff
> -      mechanism will be sent later if collision happens.
> -   o  The Joining Response packet MUST be sent on the autonomous non-
> -      SHARED cell to the pledge by the JP.  A retransmition will be sent
> -      immediately at next autonomous non-SHARED cell if collision
> -      happens.
> +   o  The Join Request MUST be sent on the autonomous SHARED
> +      cell the pledge has to the JP. Because it is SHARED, a back-off
> mechanism kicks in at the plegde when it doesn't receive a link-layer
> response.
> +   o  The Join Response MUST be sent on the autonomous non-
> +      SHARED cell the JP has to be pledge. Because it is non-SHARED, the
> JP retransmit immediately it case it doesn't receive a link-layer response
> (i.e. there is no back-off).
>
> -   After joined, nodes MUST set up their autonomous non-SHARED cell, as
> -   described in Section 3.  The root node MUST set up its autonomous
> -   non-SHARED cell when it is configured as root.
> +   After joining, nodes MUST set up their autonomous non-SHARED cell, as
> +   described in Section 3.  The root node is consider "joined" as soon as
> it is configured as root.
>
>  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.  The
> +   network, a joined node can decrypt any packets sent by its
> +   neighbors.  Once a new neighbor is added a node's neighbor table, the
> node MUST add
> +   an autonomous SHARED cell to that neighbor.  The
>     autonomous SHARED cell MUST be removed if the corresponding neighbor
> -   is removed from the neighbor table.  How to decide the neighbors to
> -   keep in neighbor table is implementation-specific.
> +   is removed from the neighbor table.  How to decide which neighbors to
> +   remove in the neighbor table is implementation-specific.
>
>  4.6.  Step 5 - Acquiring a RPL rank
>
> @@ -459,6 +467,7 @@ Internet-Draft  6TiSCH Minimal Scheduling Function
> (MSF)      March 2019
>     managed unicast cells with that neighbor from its own schedule.  In
>     addition, it MAY issue a 6P CLEAR to that neighbor (which can fail at
>     the link-layer).  The node MAY be removed from the neighbor table.
> +TW> some context or condition is missing from this last sentence.
>     If so, the autonomous SHARED cell will be removed following the
>     procedure described in Section 3.
>
> @@ -472,10 +481,11 @@ Internet-Draft  6TiSCH Minimal Scheduling Function
> (MSF)      March 2019
>     o  it has identified its preferred routing parent
>     o  it has one autonomous non-SHARED cell and a set of autonomous
>        SHARED cells to/from its neighbors
> +TW> split in multiple bullet points for SHARED and non-SHARED
>     o  it is periodically sending DIOs, potentially serving as a router
>        for other nodes' traffic
>     o  it is periodically sending EBs, potentially serving as a JP for
> -      new joining nodes
> +      new pledges
>
>  5.  Rules for Adding/Deleting Cells
>
> @@ -526,13 +536,16 @@ Internet-Draft  6TiSCH Minimal Scheduling Function
> (MSF)      March 2019
>     removed by 6P, so that there always exists an autonomous cell between
>     a node and its preferred parent, even if no frames are being
>     exchanged between them.  Autonomous cells are used indistinguishably
> -   together with dedicated cells, for broadcast or unicast traffic with
> +TW> what do you mean by "used indistinguishably"?
> +   together with dedicated cells,
> +TW> previously, you used the term managed cells but now dedicated. I
> suggest you use the term managed throughout
> +   for broadcast or unicast traffic with
>     the target neighbor.  The procedure to remove autonomous cells is
>     described in Section 3.
>
>     Adding/removing/relocating cells involves exchanging frames that
> -   contain 6P commands.  All 6P frames MUST be sent on the autonomous
> -   cell or managed cell if the node has.
> +   contain 6P commands.  All 6P frames MUST be sent on autonomous
> +   or managed cells.
>
>     The node MUST maintain the following counters for its preferred
>     parent:
> @@ -551,9 +564,7 @@ Internet-Draft  6TiSCH Minimal Scheduling Function
> (MSF)      March 2019
>         *  The node sends a frame to its preferred parent.  The counter
>            increments regardless of whether a link-layer acknowledgment
>            was received or not.
> -       *  The node receives a frame from its preferred parent.  The
> -          frame MUST be able to decrypt with the key assigned during
> -          joining process.
> +       *  The node receives a frame from its preferred parent, and
> unsecuring of that frame is successful.
>
>
>
> @@ -570,36 +581,39 @@ Internet-Draft  6TiSCH Minimal Scheduling Function
> (MSF)      March 2019
>
>     1.  Both NumCellsElapsed and NumCellsUsed are initialized to 0 when
>         the node boots.
> -   2.  After End State defined in Section 4.9, if there is no managed
> -       unicast cell to the preferred parent, trigger 6P to add a signle
> +   2.  After the End State defined in Section 4.9, if there is no managed
> +       unicast cell to the preferred parent, trigger 6P to add a
>         cell to it.
>     3.  When the value of NumCellsElapsed reaches MAX_NUMCELLS:
>
>         *  If NumCellsUsed > LIM_NUMCELLSUSED_HIGH, trigger 6P to add a
> -          single cell to the preferred parent
> +          cell to the preferred parent
>         *  If NumCellsUsed < LIM_NUMCELLSUSED_LOW, trigger 6P to remove a
> -          single cell to the preferred parent
> +          cell to the preferred parent
>         *  Reset both NumCellsElapsed and NumCellsUsed to 0 and go to
>            step 2.
>
> -   To have the counters working, at least one unicast cell need to be
> +   To have the counters working, at least one unicast cell needs to be
>     maintained all the time and never be removed.
> +TW> OK, so in all cases a node will have 2 cells to its preferred parent:
> one autonomous, one managed.
>
> -   The reason why the counter only counts the managed unicast cell, NOT
> -   including the autonomous SHARED cell is to avoid the effects of
> -   collision.  If the autonomous SHARED cell is counted as well,
> +   The reason why the counter only counts managed unicast cell (NOT
> +   autonomous SHARED cells) is to avoid the effect of
> +   collisions.  If autonomous SHARED cell were counted as well,
>     NumCellsUsed > LIM_NUMCELLSUSED_HIGH could be caused by the collision
> -   on the cell.  A 6P add request on the autonomous SHARED cell will
> +   on the cell.  A 6P add request on the autonomous SHARED cell would
>     make the collision even worse.
>
>     Both NumCellsElapsed and NumCellsUsed counters can be used to cell
> +TW> something missing
>     with cell option TX=1 or RX=1.  With the rules defined above, the
> -   cell to add or remove can be transmitting cell or receiving cell
> +   cell to add or remove can be a transmitting or receiving cell
>     according to which type of cell the two counters are used for.
> +TW> don't understand.
>
> -   Similar to Join Request and Response, the 6P Request is scheduled to
> -   send on the autonomous SHARED cell to the node's parent.  The 6P
> -   Response is scheduled to send back on the autonomous non-SHARED cell
> +   Similar to Join Request and Response messages, 6P Request frames are
> +   sent on the autonomous SHARED cell to the node's parent.  The 6P
> +   Response is sent back on the autonomous non-SHARED cell
>     to the node.
>
>  5.2.  Switching Parent
> @@ -607,7 +621,7 @@ Internet-Draft  6TiSCH Minimal Scheduling Function
> (MSF)      March 2019
>     A node implementing MSF SHOULD implement the behavior described in
>     this section.
>
> -   Part of its normal operation, the RPL routing protocol can have a
> +   As part of its normal operation, the RPL routing protocol can have a
>     node switch preferred parents.  The procedure for switching from the
>     old preferred parent to the new preferred parent is:
>
> @@ -619,7 +633,7 @@ Internet-Draft  6TiSCH Minimal Scheduling Function
> (MSF)      March 2019
>
>
>     1.  if the new parent is not in the neighbor table, the autonomous
> -       SHARED cell MUST be added as defined in Section 3
> +       SHARED cell MUST be added, as defined in Section 3
>     2.  the node counts the number of managed unicast cell cells it has
>         per slotframe to the old preferred parent
>     3.  the node triggers one or more 6P ADD commands to schedule the
> @@ -636,6 +650,7 @@ Internet-Draft  6TiSCH Minimal Scheduling Function
> (MSF)      March 2019
>     Since scheduling is entirely distributed, there is a non-zero
>     probability that two pairs of nearby neighbor nodes schedule a
>     managed unicast cell at the same [slotOffset,channelOffset] location
> +TW> why "managed unicast"? why not simply "managed"?
>     in the TSCH schedule.  In that case, data exchanged by the two pairs
>     may collide on that cell.  We call this case a "schedule collision".
>
> @@ -817,6 +832,7 @@ Internet-Draft  6TiSCH Minimal Scheduling Function
> (MSF)      March 2019
>         quarantine, drop all frames received from that node.
>     waitretry:  Abort the 6P Transaction.  Wait for a duration randomly
>         and uniformly chosen in [WAITDURATION_MIN,WAITDURATION_MAX].
> +TW> these names are a bit obscure. Use WAITRETRYDURATION_MIN and
> WAITRETRYDURATION_MAX?
>         Retry the same transaction.
>
>  13.  Schedule Inconsistency Handling
> @@ -1020,10 +1036,10 @@ Appendix B.  Example of Implementation of SAX hash
> function
>     o  c, which is the characters of string s, to be hashed
>
>     In MSF, the T is replaced by the length slotframe 1.  String s is
> -   replaced by the mote EUI64 address.  The characters of the string c0,
> +   replaced by the mote's EUI64 address.  The characters of the string c0,
>     c1, ..., c7 are the 8 bytes of EUI64 address.
>
> -   The SAX hash function requires shift operation which is defined as
> +   The SAX hash function requires a shift operation which is defined as
>     follow:
>
>     o  L_shift(v,b), which refers to left shift variable v by b bits
>
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>


-- 
Chang Tengfei,
Pre-Postdoctoral Research Engineer, Inria