Thanks, Tengfei. I understand that adaptation to traffic doesn't work for Rx managed cells. So, as you suggested, the parent node should trigger 6P ADD/DELETE/RELOCATE to one of its children, probably using 3-step transaction. That would affect description on usage of AutoUpCell and AutoDownCell.
Best regards, Toshio Ito From: Tengfei Chang <[email protected]> Sent: Tuesday, April 23, 2019 10:32 PM To: ito toshio(伊藤 俊夫 ○ＲＤＣ□ＣＮＬ) <[email protected]> Cc: [email protected] Subject: Re: [6tisch] [Call for Review] draft-ietf-6tisch-msf-03 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> On Behalf Of Tengfei Chang Sent: Tuesday, April 09, 2019 1:06 PM To: [email protected]<mailto:[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/6tisch
