Re: [6tisch] call for review: draft-ietf-6tisch-msf-04
Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr> Thu, 04 July 2019 13:04 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 65C9812021C for <6tisch@ietfa.amsl.com>; Thu, 4 Jul 2019 06:04:17 -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 JqTD_Vlw3TeL for <6tisch@ietfa.amsl.com>; Thu, 4 Jul 2019 06:04:14 -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 64B3F120665 for <6tisch@ietf.org>; Thu, 4 Jul 2019 06:04:12 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.63,451,1557180000"; d="scan'208";a="312433602"
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; 04 Jul 2019 15:04:10 +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: <24BBDDB7-E10C-4E14-860F-5C9EE77D7061@inria.fr>
Date: Thu, 04 Jul 2019 15:04:09 +0200
Cc: Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr>, 6tisch@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <AC7AE7A7-E1F6-4F17-9635-88377948AEA5@inria.fr>
References: <CAAdgstQHZ8KCtfLx+dmU=F2SLtvE1HTeSGJU8i2GPo7_798i3g@mail.gmail.com> <24BBDDB7-E10C-4E14-860F-5C9EE77D7061@inria.fr>
To: Tengfei Chang <tengfei.chang@gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/ZuvvtQ83w_reMQbpUBc5lGmqCec>
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: Thu, 04 Jul 2019 13:04:17 -0000
Hi Tengfei, Another minor comment: https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-5.3 draft> 5.3. Handling Schedule Collisions draft> draft> A node implementing MSF SHOULD implement the behavior described in draft> this section. The "MUST" statements in this section hence only apply draft> if the node implements schedule collision handling. I think some part of the section could be implementation-specific, for instance, how to manage NumTx and NumTxAck internally. draft> Each time the node switches preferred parent (or during the join draft> process when the node selects a preferred parent for the first time), draft> both NumTx and NumTxAck MUST be reset to 0. They increment over draft> time, as the schedule is executed and the node sends frames to its draft> preferred parent. When NumTx reaches 256, both NumTx and NumTxAck draft> MUST be divided by 2. I'd propose to remove the second sentence in the first paragraph, which starts with "The "MUST" statements in this section...", and to alter the section just to demonstrate how we can resolve "schedule collisions" using 6P RELOCATE command. Best, Yatch > On Jul 2, 2019, at 14:58, Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr> wrote: > > 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 >
- [6tisch] call for review: draft-ietf-6tisch-msf-04 Tengfei Chang
- Re: [6tisch] call for review: draft-ietf-6tisch-m… Yasuyuki Tanaka
- Re: [6tisch] call for review: draft-ietf-6tisch-m… toshio9.ito
- Re: [6tisch] call for review: draft-ietf-6tisch-m… Yasuyuki Tanaka
- Re: [6tisch] call for review: draft-ietf-6tisch-m… Pascal Thubert (pthubert)
- Re: [6tisch] call for review: draft-ietf-6tisch-m… Tengfei Chang
- Re: [6tisch] call for review: draft-ietf-6tisch-m… Tengfei Chang
- Re: [6tisch] call for review: draft-ietf-6tisch-m… Tengfei Chang
- Re: [6tisch] call for review: draft-ietf-6tisch-m… Pascal Thubert (pthubert)
- Re: [6tisch] call for review: draft-ietf-6tisch-m… Pascal Thubert (pthubert)
- Re: [6tisch] call for review: draft-ietf-6tisch-m… Tengfei Chang
- Re: [6tisch] call for review: draft-ietf-6tisch-m… Esteban Municio
- Re: [6tisch] call for review: draft-ietf-6tisch-m… Yasuyuki Tanaka
- Re: [6tisch] call for review: draft-ietf-6tisch-m… Tengfei Chang
- Re: [6tisch] call for review: draft-ietf-6tisch-m… Pascal Thubert (pthubert)
- Re: [6tisch] call for review: draft-ietf-6tisch-m… Tengfei Chang
- Re: [6tisch] call for review: draft-ietf-6tisch-m… Tengfei Chang
- Re: [6tisch] call for review: draft-ietf-6tisch-m… Pascal Thubert (pthubert)
- Re: [6tisch] call for review: draft-ietf-6tisch-m… Tero Kivinen
- Re: [6tisch] call for review: draft-ietf-6tisch-m… Tengfei Chang
- Re: [6tisch] call for review: draft-ietf-6tisch-m… Pascal Thubert (pthubert)