Hi Toshio, Thanks for review the draft!
For your comments: *Minimum number of managed cells * TC: Yes, it's better to have at least one Tx Managed Cell to parent, maybe one Rx Managed Cell as well for downstream, for your second point. *Direction of managed cells* TC: yes, the support on Tx and Rx managed cell are not clear in 03. We will rephrase the section. TC: One problem discovered by now is that the adaption to traffic only works on Tx cell actually. TC: For Rx managed cell, if the node didn't receive a packet at Rx cell, it doesn't know where there is no packet incoming or the packet is failed because of interference/collision. TC: One solution for that is, we will only support Tx managed cell but the initiator of 6P could be parent and the request is sent to one of its children. Tengfei On Tue, Apr 23, 2019 at 2:51 AM <toshio9....@toshiba.co.jp> wrote: > Hi Tengfei, > > > > Thanks for the work. The draft looks promising. > > > > I have two comments on the managed cells. > > > > > > * Minimum number of managed cells > > > > Sec. 5.1: Revision -02 had the following sentence. > > > > msf-02> To have the counters working, at least one unicast cell need > > msf-02> to be maintained all the time and never be removed. > > > > However, this is removed in -03. So, I think it's possible that msf-03 > > removes all managed cells, as a result of adaptation to the > > traffic. Is it OK? > > > > > > * Direction of managed cells > > > > It looks like managed cells are only for upstream traffic. > > > > In section 4.6, the joining node adds a Tx cell to the preferred > > parent. > > > > msf-03> Then it MUST issue a 6P ADD command MUST to that parent, with > > msf-03> the following fields: > > msf-03> o CellOptions: set to TX=1,RX=0,SHARED=0 > > msf-03> o NumCells: set to 1 > > > > In section 5.1, the node adds a Tx cell to the preferred parent to > > adapt to the traffic. > > > > msf-03> the node issues a 6P ADD command to its preferred parent to > > msf-03> add one managed Tx cell to the TSCH schedule. > > > > Because 6P transaction is always initiated from the child to the > > preferred parent, and CellOption in 6P ADD request is always (?) Tx=1 > > RX=0, there is no downstream managed cells. As a result, downstream > > packets such as DAO-ACK have to use AutoDownCell or the minimal > > cell. I think we should have downstream cells, too. > > > > > > Best regards, > > Toshio Ito > > > > *From:* 6tisch <6tisch-boun...@ietf.org> *On Behalf Of *Tengfei Chang > *Sent:* Tuesday, April 09, 2019 1:06 PM > *To:* 6tisch@ietf.org > *Subject:* [6tisch] [Call for Review] draft-ietf-6tisch-msf-03 > > > > Dear all, > > > > A new version of "draft-ietf-6tisch-msf" is just published at here: > https://www.ietf.org/id/draft-ietf-6tisch-msf-03.txt > > > > This version mainly resolved the issues presented during IETF 104 meeting. > > I would like to mention one of the main changes in this version is we > removed the frame pending bit feature. > > > > It's for two reasons: > > - it will influence the "adapt to traffic" strategy of MSF. > > - the "adapt to traffic" strategy has the ability to handle burst traffic > by using a smaller MAX_NUMCELLS > > > > Now we are calling for reviews on the new version of MSF! > > Any comments and feedback are appreciated! > > > > Tengfei > > > > > > > > -- > > Chang Tengfei, > > Postdoctoral Research Engineer, Inria > -- Chang Tengfei, Postdoctoral Research Engineer, Inria
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
