Hi Yatch, You have a very good point. Section 5.1 was assuming dedicated cells only, I believe we need to adjust it for shared cells. Feels like we want your 2nd solution, which is to increment "NumCellsUsed" during the backoff wait. We will fix this as well as the comment on scanning for next version!
Thanks, Simon On Fri, Oct 5, 2018 at 2:56 PM Yasuyuki Tanaka <yasuyuki.tan...@inria.fr> wrote: > 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 >
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
