Thanks a lot Yatch for reviewing the draft. I will reply inline: On Tue, Jul 2, 2019 at 2:58 PM 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 > :-) > I think the purpose is indeed trying to add support for downstream traffic. I current doesn't have a strong option on this. > > [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. > Hmm, it only requires read access from other layers right? It could be implemented. But I agree MUST is too strict. I just removed the MUST from the sentence. > > > [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... > > Yes, it's removed in the next version. > > [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. > Nothing happens actually, the 6P will process with less than 5 candidate cells. Though the SHOULD here is a little strong, I changed the SHOULD to RECOMMENDED, to make it less constrain. > > > [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. > Yes, changed to " The AutoRxCell MUST always remain scheduled after synchronized" > > > [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/ > Thanks for the typos list! They will be fixed in the next version. > > That's all! > Yatch > > -- Chang Tengfei, Postdoctoral Research Engineer, Inria
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
