Hi Esteban, > * 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).
It'd be nice to mention something there, at least like this: A node may remove negotiated cells scheduled with a neighbor which is considered as "unreachable", without having a 6P transaction. In that case, the node SHOULD reset the (6P) SeqNum for the neighbor. Specifying mechanisms to detect unreachable neighbors is out of scope of this document. We used to have such a mechanism in previous versions, by the way: https://tools.ietf.org/html/draft-ietf-6tisch-msf-02#section-4.8 I'm not sure what is the best way to do for that purpose when using MSF. Best, Yatch > On Jul 11, 2019, at 15:47, Esteban Municio <esteban.muni...@uantwerpen.be> > wrote: > > 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 > esteban.muni...@uantwerpen.be > The Beacon | Sint-Pietersvliet 7 | 2000 Antwerpen, Belgium > > > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch _______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
