Thanks for the update, Tengfei. I think Auto{Tx,Rx}Cells are simpler than Auto{Up,Down}Cells, because they are independent of parent switching.
Here are my comments. - Section 3: address for AutoTxCells msf-04> Autonomous Tx Cell (AutoTxCell), one cell at a msf-04> [slotOffset,channelOffset] computed as a hash of the layer 2 msf-04> EUI64 source address in the frame to be transmitted msf-04> msf-04> ... msf-04> msf-04> Add an AutoTxCell to the layer 2 source address which is msf-04> indicated in a frame when: The destination address (not source address) of the frame should be used to calculate the AutoTxCell, shouldn't it? - Section 3: conflict between autonomous and negotiated cells msf-04> In case of conflicting with a negotiated cell, autonomous msf-04> cells take precedence over negotiated cell. Now that autonomous cells and negotiated cells are in different slotframes, this statement is a natural result of Section 6.2.6.4 of IEEE 802.15.4-2015. I think it's a good idea to refer to it here. - Section 5.1: CellOptions of 6P ADD There is no specification on CellOptions (Tx/Rx/Shared) of 6P ADD requests as a result of traffic adaptation. Is it up to implemtation? - Section 5.2: parent switch We can now remove items 1. and 2. because we don't have AutoUpCells. - Section 5.3: counters for handling schedule collision msf-04> The node MUST maintain the following counters for each managed msf-04> unicast cell to its preferred parent: I think the node should maintain the counters for each negotiated Tx cell to ANY neighbor, not only to the preferred parent. That is because schedule collision can occur to any Tx cell. If a node had counters for each neighbor, the paragraph starting with the following sentance would be unnecessary. msf-04> Each time the node switches preferred parent (or during the msf-04> join process when the node selects a preferred parent for the msf-04> first time), both NumTx and NumTxAck MUST be reset to 0. Although managing the counters for each neighbor is conceptually simple, I admit it might be too much overhead for constrainted nodes. BTW, there are still two occurrences of "managed unicast cell" in the draft. Best regards, Toshio Ito From: 6tisch <6tisch-boun...@ietf.org> On Behalf Of Tengfei Chang Sent: Tuesday, July 02, 2019 7:57 PM To: 6tisch@ietf.org Subject: [6tisch] call for review: draft-ietf-6tisch-msf-04 Dear all, As you may noticed that a new version of MSF is just published at here: https://tools.ietf.org/html/draft-ietf-6tisch-msf-04 There are some moderate changes comparing to previous one. Mainly in two aspects: 1. change the concept of autonomous cell In the new version, there will be two type of autonomous cells: - autoTxCell, which is scheduled on demand for just transmitting -autoTxCell, which is schedule permanently, for just receiving (the previous version the autonomous cell are used as bidirectional) More details about how to use those autonomous cell is available in the draft. 2. re-added the downstream traffic adaptation feature Though, there are cases that the node doesn't receive packet because of collision, we assume the influence won't be much to adapt the downstream traffic. We will evaluate the performance of this changes. We are targeting to have a new version before the submission deadline. During the time, we will evaluate the v4 MSF and would like to have your comments as well. Thanks in advance! Tengfei -- Chang Tengfei, Postdoctoral Research Engineer, Inria
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch