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 <[email protected]> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
