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

[Fabrice Theoleyre <[e-mail]>]

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’?

———

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 <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