( I accidentally sending the email before finishing) the reply continues inline...
On Wed, Apr 17, 2019 at 1:57 PM Tengfei Chang <tengfei.ch...@gmail.com> wrote: > Hi Fabrice, > > Thanks a lot for your detailed comments! I will reply them inline below. > > On Tue, Apr 9, 2019 at 11:39 AM Fabrice Theoleyre <theole...@unistra.fr> > wrote: > >> Dear Tengfei, >> >> Please find below my review of the draft. I isolated the corresponding >> blocks, and inserted my comments after 'FT>' >> >> The draft is very well written, and I have mostly minor comments. >> Great job! >> >> Best regards, >> Fabrice >> >> >> ———— >> >> >> an implementor MAY implements MSF >> >> FT> an implementor MAY implement MSF >> >> FT> I’m also a little bit confused. The section describes how to use the >> shared >> FT> cell of Minimal 6TISCH. If Minimal 6TISCH is not used, how does the >> FT> scheme work? Shouldn’t some minimum requirements be FT given here? >> > TC: The minimum requirements will be that the the joining nodes are able to find a way to listen the EB/DIO from neighbors. It could be implemented in someway that not only sent on minimal cell. TC: However, consider your comments further below that the minimal security is a MUST for MSF, and minimal security is based on minimal configuration, we may need command the minimal configuration as well. > >> ——— >> >> These cells are called 'autonomous cells', because they are maintained >> autonomously >> by each node. >> >> FT> I find the term ‘autonomous’ quite misleading, since manage cells are >> FT> also negotiated autonomously (without any controller). I would rather >> use >> FT> something else like ‘pseudo-random’. >> FT> or rename the 'managed cells' in ’negotiated cells’? >> >> TC: yes, "negotiated cells" sounds good for me. > TC: I will rephrase the sentence as : > TC: These cells are called 'autonomous cells', because they are maintained autonomously TC: by each node without negotiation through 6P. TC: Cells scheduled through 6P transaction are called ' negotiated cells'. > ——— >> >> There are other optional parameters defined in SAX determines the >> performance of SAX hash function. >> >> FT> Other optional parameters defined in SAX >> FT> determine the performance of SAX hash function. >> >> TC: Will be fixed in next version. > ——— >> >> The AutoUpCell with the most packets in the outgoing queue takes >> precedence. >> >> FT> does a node has several upstream cells? I would have thought >> FT> that a single upstream cell exists (or you consider multiple parents?) >> >> TC: no. only one parent is considered. Will change something like: "AutoUpCell takes precedence if its outgoing queue is non-empty." > ——— >> >> Autonomous Downstream Cell (AutoDownCell), one cell at a >> [slotOffset,channelOffset] computed as a hash of its own EUI64 >> (detailed next). Its cell options bits are assigned as TX=1, >> RX=1, SHARED=0. >> >> FT> I would have explained here the role of this cell (i.e. receiving >> FT> control packets from any neighbor), and similarly for the upstream >> cell. >> FT> I conjecture it may be quite hard for the reader to understand >> FT> their purpose >> >> TC: The traffic on the autonomous cells are defined later in the section, which explains what packets/frames are sent on those cells. We could replace that explanation early in the section. For example, right after the definition of the autonomous cell. > ——— >> >> 6P RELOCATE Request frames to the node's RPL routing child MUST be >> sent on AutoDownCell. >> >> FT> What about 6P RELOCATE request to the parent? Can only a parent >> FT> relocate a cell with 6P? >> >> TC: 6P RELOCATE request to the parent will be sent on AutoUpCell. I missed the RELOCATE 6P request. Will be fixed in next version. > ——— >> >> Join Response packets and 6P ADD/DELETE Response frames to the >> pledge or its RPL routing child MUST be sent on AutoDownCell. >> >> FT> does this mean that a cell MUST be inserted in the schedule >> FT> for each child (or after the reception of a Join-req)? Or can >> FT> a node send a packet through a cell not registered in its schedule? >> > TC: no. There is only on AutoDownCell. The parent/JP can use the cell to send to any of its chidren/pledge. > >> ——— >> >> A node implementing MSF MUST implement the Minimal Security Framework >> for 6TiSCH >> >> FT> In contradiction with section 2 'MAY implements MSF without >> implementing >> FT> Minimal 6TiSCH Configuration.' >> > TC: yes, as a consequence, we may use "MUST" again on the Minimal 6TiSCH Configuration. Or make the security strategy open as well? I am tending to the former. > >> ——— >> >> The section 4 is particularly clearly, explaining well the ‘flow’ when a >> device joins the network >> > TC: 👍 > >> ——— >> >> While autonomous cells have a dedicated section (2), managed cells are >> not described. >> In particular, are they bidirectional, shared, etc.? >> > TC: no, they are considered as only one direction, with cell option either TX=1 or RX=1. > >> ——— >> >> NumCellsUsed: Counts the number of managed cells that have been >> used. This counter is initialized at 0. NumCellsUsed is >> incremented by exactly 1 when, during a managed cell to the >> preferred parent, either of the following happens: >> >> […] >> >> * The node receives a frame from its preferred parent. >> >> FT> Let assume a cell is shared, and is only used to receive packets. >> FT> Because of a bad PDR, we have many retransmissions. The receiver >> FT> implements the counter only when the cell is decoded. It may decide >> FT> to DELETE this cell. >> FT> Doesn’t it? >> > TC: This is good point! I think the adaption strategy doesn't fit the case for the RX cell in this sense. TC: if we can't figure out a good way to handle that case, we will remove the support of RX cell. > >> FT> Shouldn’t the description consider separately the SHARED and >> NON-SHARED >> FT> cases? >> >> TC: Right now we are not considering the case of SHARED "managed cell" (negotiated cell) since It may influence the calculation of cell Usage. > ——— >> >> 1. if there is managed cell conflicted with the AutoUpCells to be >> installed, the node MUST issue a 6P RELOCATE command to relocate >> the conflicted cell >> >> FT> When is the AutoUpCells installed? After the 6P RELOCATE RESPONSE? >> FT> Before, and the AutoUpCells has the priority? >> > TC: for general case, AutoUpcell is installed before issuing 6P RELOCATE RESPONSE. However, in case of parent switching, the sequence may change. > >> ——— >> That is, for example, from NumTx=256 and >> NumTxAck=128, they become NumTx=128 and NumTxAck=64. This operation >> does not change the value of the PDR, but allows the counters to keep >> incrementing. >> >> FT> yes, but it increases the convergence time. For instance, a burst of >> FT> packets is dropped at the beginning (i.e. during convergence, with >> FT> many collisions). Then, everything is fine. The PDR will take a long >> time >> FT> to reflect the actual PDR. The cell may be RELOCATED erroneously. >> FT> (the collision may have been solved meanwhile by the conflicting link) >> >> FT> Is it something you considered? >> > TC: in convergence time, the traffic goes on autonomous cell, when the "managed cell" is installed, that cell shouldn't have collision. Though the PDR take a long time to reflect the actual PDR, in case of bad PDR on the cell, the MSF traffic adapting strategy will compensate by allocating extra cell to meet the throughput. > >> ——— >> towards it preferred parent >> >> FT> towards its preferred parent >> >> TC: will be fixed in next version. > ——— >> >> is calcualted as >> ((2^MAXBE)-1)*SLOTFRAME_LENGTH, where: >> >> FT>is calculated as >> > TC: will be fixed in next version. > >> ——— >> >> MAXEB is the maxmium backoff exponent is used >> >> FT> MAXBE is the maximum backoff exponent used >> (3 errors) >> > TC: will be fixed in next version. > >> ——— >> >> >> >> >> >> Le 9 avr. 2019 à 06:06, Tengfei Chang <tengfei.ch...@gmail.com> a écrit : >> >> 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 >> _______________________________________________ >> 6tisch mailing list >> 6tisch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tisch >> >> >> > > -- > 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
