Hi Tengfei, I like the new changes, especially the concept of autonomous cells by demand and always having by default 1 downlink negotiated cell.
Here are some minor comments (checking msf-05): * In Section 5.2, it is not clear for me if the parent switch occurs before, during or after the 3-step procedure. My intuition says that is should be after point 2: "the node triggers one or more 6P ADD commands ....". I guess it may be interesting to clarify when the actual parent switch occurs. * Also in the same section 5.2, it could be convenient (although maybe redundant) to say in point 2 that the node has to schedule the same number "and options" of negotiated cells. This would keep also the ratio TX/RX with the new parent. * Maybe out of the scope but, should not be defined here a housekeeping function that removes unused negotiated cells (TX or RX)? For example for cells that can't be removed with a 6P transaction (e.g. nodes are not in range any more). And some minor edit comments: - "increaase" - two "AutoUpCells" are still there - two "managed unicast cell" are still there - "it is possible for negotiated cell to avoid the collision with AutoRxCell." Maybe "for a negotiated"? - "For burst traffic type, larger value of MAX_NUMCELLS indeed introduces higher latency." Maybe "a larger value"? Kind regards, Esteban On Tue, 2019-07-02 at 12:57 +0200, Tengfei Chang wrote: > 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 -- Esteban Municio PhD Researcher, IDLab, University of Antwerp, in collaboration with imec [email protected] The Beacon | Sint-Pietersvliet 7 | 2000 Antwerpen, Belgium
signature.asc
Description: This is a digitally signed message part
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
