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

Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr> Tue, 02 July 2019 12:58 UTC

Return-Path: <yasuyuki.tanaka@inria.fr>
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 181D71201D1 for <6tisch@ietfa.amsl.com>; Tue, 2 Jul 2019 05:58:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 sjVxK7-dHEkr for <6tisch@ietfa.amsl.com>; Tue, 2 Jul 2019 05:58:31 -0700 (PDT)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 0182F12013B for <6tisch@ietf.org>; Tue, 2 Jul 2019 05:58:30 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.63,443,1557180000"; d="scan'208";a="312162500"
Received: from wifi-pro-83-161.paris.inria.fr ([128.93.83.161]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Jul 2019 14:58:28 +0200
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr>
In-Reply-To: <CAAdgstQHZ8KCtfLx+dmU=F2SLtvE1HTeSGJU8i2GPo7_798i3g@mail.gmail.com>
Date: Tue, 02 Jul 2019 14:58:28 +0200
Cc: Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr>, 6tisch@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <24BBDDB7-E10C-4E14-860F-5C9EE77D7061@inria.fr>
References: <CAAdgstQHZ8KCtfLx+dmU=F2SLtvE1HTeSGJU8i2GPo7_798i3g@mail.gmail.com>
To: Tengfei Chang <tengfei.chang@gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/GOs8g-63jn3lLxpNwASbURZuQ60>
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: Tue, 02 Jul 2019 12:58:34 -0000

Thank you, Tengfei and the other authors, for the update!

Here are my comments:

[Major] Negotiated RX cell (Section 4.6)

https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-4.6

If MSF is designed for regular upstream traffic, I don't think we need
the negotiated RX cell that is introduced by this new version.

I presume the purpose of the negotiated RX cell is, to have a
collision-free channel directed from parent to child. The parent may
have collisions on the autonomous TX cell to a node since children of
the node also use the cell to transmit their frames. However, once the
network converges, the children have negotiated TX cells to the
node. The parent of the node will be the only one who uses the
autonomous TX cell until a topological change happens.

I would rather keep unused cells in the slotframe for negotiated TX
cells to handle "regular upstream traffic" instead of using some of
them for negotiated RX cells (to receive frames from the parent).

I'm looking forward to seeing Tengfei's evaluation results, by the way
:-)


[Minor] AutoTxCell usage (Section 3)

https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-3

Sorry for bringing this again and again, but *in general*, L2/TSCH
layer has no idea about its upper layers. Although you can implement a
6TiSCH stack in which TSCH is aware of upper layer contents of a frame
to transmit, that may not be always the case. That is, the second
bullet point, starting with "frame is used for...", may not be able to
be implemented.

In this sense, applying "MUST" to the second bullet point seems too
strict.

draft> AutoTxCell is not permanent in the schedule but added/deleted on
draft>    demand when there is a frame to sent.  Throughout the network
draft>    lifetime, nodes MUST maintain the autonomous cells as follows:
draft>
draft>    o  Add an AutoTxCell to the layer 2 source address which is indicated
draft>       in a frame when:
draft>
draft>       *  there is no 6P negotiated Tx cell in schedule for that frame to
draft>          transmit, and
draft>       *  the frame is used for protocol management purposes , such as
draft>          Join Request/Response, 6P Request/Response and any link-local
draft>          communication for RPL routing control.


[Minor] Unprotected frames on negotiated cells? (Section 5.1)

https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-5.1

draft>   Both NumCellsElapsed and NumCellsUsed counters can be used to
draft>   negotiated cells with cell option TX=1 or Rx=1.  All the frames used
draft>   for increasing/decreasing the counters MUST be encrypted or
draft>   decryptable with the key get from joining process.

Will we have unprotected frames transmitted on negotiated TX/RX cells,
which are expected to be scheduled with *joined* nodes? I'm not sure
why the last sentence is necessary...


[Minor] Length of CellList (Section 8)

https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-8

What should a node do when it receives a CellList shorter than 5?
Return RC_ERR_CELLLIST?

draft> 8.  Rules for CellList
draft>
draft>    MSF uses 2-step 6P Transactions exclusively.  6P Transactions are
draft>    only initiated by a node towards its preferred parent.  As a result,
draft>    the cells to put in the CellList of a 6P ADD command, and in the
draft>    candidate CellList of a RELOCATE command, are chosen by the node
draft>    initiating the 6P Transaction.  In both cases, the same rules apply:
draft>
draft>    o  The CellList SHOULD contain 5 or more cells.


[Trivial] Section 3. Autonomous Cells

https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-3

draft>  o  The AutoRxCell MUST always remain scheduled.

*Always* is ambiguous. A node cannot schedule an AutoRxCell until it's
get synchronized, when the length of slotframe 1 is available.


[Trivial] nits / editorial

- "AutoUpCells" is still there
- s/behvaior/behavior/
- s/boostrap/bootstrap/
- s/sheduling/scheduling/
- s/negoitated/negotiated/
- s/neogtiated/negotiated/
- s/transcation/transaction/
- s/calulated/calculated/

That's all!
Yatch