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? > > ——— > > 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. ——— > > 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. > > ——— > > 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?) > > ——— > > 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 > > ——— > > 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? > > ——— > > 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? > > ——— > > 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.' > > ——— > > The section 4 is particularly clearly, explaining well the ‘flow’ when a > device joins the network > > ——— > > While autonomous cells have a dedicated section (2), managed cells are not > described. > In particular, are they bidirectional, shared, etc.? > > ——— > > 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? > > FT> Shouldn’t the description consider separately the SHARED and NON-SHARED > FT> cases? > > ——— > > 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? > > ——— > 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? > > ——— > towards it preferred parent > > FT> towards its preferred parent > > ——— > > is calcualted as > ((2^MAXBE)-1)*SLOTFRAME_LENGTH, where: > > FT>is calculated as > > ——— > > MAXEB is the maxmium backoff exponent is used > > FT> MAXBE is the maximum backoff exponent used > (3 errors) > > ——— > > > > > > 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
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
