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

[Tengfei Chang <[e-mail]>]

( I accidentally sending the email before finishing) the reply continues
inline...

On Wed, Apr 17, 2019 at 1:57 PM Tengfei Chang <[e-mail]>
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 <[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?
>>
>
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 <[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
>


-- 
Chang Tengfei,
Postdoctoral Research Engineer, Inria