Hi Toshio, Thanks for reviewing the draft, let me reply you inline below:
On Thu, Jul 4, 2019 at 4:16 AM <[email protected]> wrote: > 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? > Yes, it should. Thanks for indicating it! Will be fixed in next version. > > > > > - 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. > Yes, will be added in next version. > > > > > - 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? > Yes, it's kind of implied in the draft that it can be Tx=1 only or Rx=1 only. Will add this statement in the draft next version. > > > > > - Section 5.2: parent switch > > > > We can now remove items 1. and 2. because we don't have AutoUpCells. > Removed. Thanks! > > > > > - 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. > Thanks for the comments! However, along the network time, the node won't send upper layer packet s to non-parent neighbor. In case of switching parent, the traffic will go on autoTx cell. > > > > > BTW, there are still two occurrences of "managed unicast cell" in the > > draft. > Will corrected in next version. > > > > > Best regards, > > Toshio Ito > > > > *From:* 6tisch <[email protected]> *On Behalf Of *Tengfei Chang > *Sent:* Tuesday, July 02, 2019 7:57 PM > *To:* [email protected] > *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 > -- Chang Tengfei, Postdoctoral Research Engineer, Inria
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
