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.tan...@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 mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
