Re: [6tisch] [Call for Review] draft-ietf-6tisch-msf-03

[Tengfei Chang <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>
>

-- 
Chang Tengfei,
Postdoctoral Research Engineer, Inria