Hi, I have additional comments on the latest MSF:
* discussion: scheduling adaptation MSF can adapts to traffic changes in the manner described in section 5.1. It seems this mechanism doesn't work well under a heavy loaded situation. After joining process, a joined node (child) has one autonomous cell to its parent, which is the autonomous RX cell from the viewpoint of the parent. If the network is inactive and the link quality is pretty good, the child can send a frame over the autonomous cell anytime it wants. And, if it has always frames to send, then the adaptation mechanism will determines to allocate additional cells. However, if there are many siblings of the child around and its network load is high, frames sent by the child on the autonomous cell of the parent are likely to be lost because of collisions. When the child has an un-acknowledged frame, it has to perform the retransmission algorithm since the autonomous cell has the SHARED bit on. A bad thing to the adaptation mechanism is that "NumCellsUsed" is not incremented during the backoff wait, although "NumCellsPassed" is counted up. As a result, the child cannot have additional (dedicated) cells here even though it may have many cells in its TX queue. It may be fine, by the way, since these frames in the TX queue will be sent continuously thanks to the pending bit once the first frame is received successfully by the parent. But, an additional dedicated cell is not allocated in this case, anyway. A simple solution is to increment "NumCellsUsed" during the backoff wait if it's desirable to have a dedicated cell to the parent in such a case. * trivial comment: channel to listen on for EBs The pledge may not know in advance which channels are used in a network to join. So, it'd be better to try a different frequency if it cannot receive any EB for a while. draft> 4.2. Step 1 - Choosing Frequency draft> draft> When switched on, the pledge SHOULD randomly choose a frequency among draft> the available frequencies, and start listening for EBs on that draft> frequency. draft> draft> 4.3. Step 2 - Receiving EBs draft> draft> Upon receiving the first EB, the pledge SHOULD continue listening for draft> additional EBs to learn: Best, Yatch On Aug 31, 2018, at 15:33, Yasuyuki Tanaka <yasuyuki.tan...@inria.fr> wrote: > > Thank you, Simon and Xavi! > > A couple of things: > >>>> 'MUST' here sounds too strong... Some may want to use MSF with a base >>>> schedule >>>> other than one defined RFC 8180 with full understands on implications by >>>> not >>>> following RFC 8180. Then, I'd propose 'SHOULD'. >>>> >>>> By the way, I'm not sure whether we can specify 'MUST implement' to a BCP >>>> document or not. >>> >>> MSF assumes the presence of the minimal cell, but might be able to run >>> without the full RFC8180. >>> Happy to hear what others think >>> >> XV>> MSF needs at least one pre-existing cell in the schedule so a node can >> receive/send EBs and form/join into the network. To ensure this we enforce >> RFC8180. > > If the minimal shared cell is only the dependency for MSF, it'd be much > clearer to say that instead of saying, "MSF MUST implement RFC 8180". RFC > 8180 defines far more things than having the minimal shared cell. And, it > concerns 2.4 GHz O-QPSK PHY alone. > >>>> * minor comment 6 >>>> >>>> What is Section 10, "Rule for Ordering Cells", for...? Why do we need this >>>> section? >>>> >>> I'll let other co-authors answer >>> >> XV> I think this was though to handle pagination when the LIST command is >> received. This is, define what are the cells to return when a list command >> is requesting cells from a particular offset. > > I see; then, I'd like to have such explanation in Section 10 :-) > > https://tools.ietf.org/html/draft-ietf-6tisch-msf-00#section-10 > > Best, > Yatch _______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
