Re: [6tisch] comments on draft-chang-6tisch-msf-01

[Florian Kauer <[e-mail]>]

Hi,
regarding section "5. Rules for Adding/Deleting Cells" of

     https://tools.ietf.org/html/draft-ietf-6tisch-msf-00

I noticed some issues. Some of them are already addressed by Yasuyuki 
Tanaka in a previous review of draft-chang-6tisch-msf-01 but it seems 
they have not been addressed yet.

 > 2.  When the value of NumCellsPassed reaches MAX_NUMCELLS:
 >      *  If NumCellsUsed > LIM_NUMCELLSUSED_HIGH, trigger 6P to add a
 >          single cell to the preferred parent
 >      *  If NumCellsUsed < LIM_NUMCELLSUSED_LOW, trigger 6P to remove
 >          single cell to the preferred parent
 >      *  Reset both NumCellsPassed and NumCellsUsed to 0 and go to step
 >         2.

In particular, in 5.1. the inequalities NumCellsUsed > 
LIM_NUMCELLSUSED_HIGH and NumCellsUsed < LIM_NUMCELLSUSED_LOW do not 
match the intention of the recommended values of LIM_NUMCELLSUSED_HIGH 
and LIM_NUMCELLSUSED_LOW as percentages.

In addition, it seems that MAX_NUMCELLS is not defined in 
draft-ietf-6tisch-msf-00. Is it defined in another draft? I expect its 
value (or better: the use of this value in MSF) has a tremendous impact 
on the ability of MSF to handle volatile traffic.

 > The node MUST maintain the following counters for its preferred
 > parent:

What is the reason that dynamic allocation of slots is only performed 
towards the parent and not towards children?

Greetings,
Florian

On 14.06.2018 18:16, Yasuyuki Tanaka wrote:
> Hi,
> 
> I'm sharing my comments on draft-chang-6tisch-msf-01.
> 
>      https://tools.ietf.org/html/draft-chang-6tisch-msf-01
> 
> 
> [1] how should a node handle a 6P transaction failure?
> 
> draft> 3.  Node Behavior at Boot
> draft> ...
> draft> 3.6.  Step 5 - 6P ADD to Preferred Parent
> draft>
> draft>    After having selected a preferred parent, the joined node MUST issue
> draft>    a 6P ADD command to that parent, with the following fields:
> 
> What should the joining node do if the ADD transaction fails? It
> should retry the ADD command after waiting for [WAITDURATION_MIN,
> WAITDURATION_MAX]? If so, how many times should it retry at the
> maximum?
> 
> 
> [2] what cell options will additional dedicated cells have?
> 
> draft> 4.1.  Adapting to Traffic
> ....
> draft>    o  If the node determines that the number of link-layer frames it is
> draft>       attempting to exchange with its preferred parent per unit of time
> draft>       is larger than the capacity offered by the TSCH cells it has
> draft>       scheduled with it, it triggers a 6P Transaction with its preferred
> draft>       parent to add cells to the TSCH schedule of both nodes.
> 
> It's unclear to me what cell options additional dedicated cells will
> have. NumCellsUsed is the number of frame exchanges in dedicated
> cells, which doesn't care about directions: incoming or outgoing.
> 
> draft>    NumCellsUsed:  Counts the number of dedicated cells that have been
> draft>        used.  This counter is initialized at 0.  NumCellsUsed is
> draft>        incremented by exactly 1 when, during a dedicated cell to the
> draft>        preferred parent, either of the following happens:
> draft>
> draft>        *  The node sends a frame to its preferred parent.  The counter
> draft>           increments regardless of whether a link-layer acknowledgment
> draft>           was received or not.
> draft>        *  The node receives a frame from its preferred parent.
> 
> In other words, NumCellsUsed doesn't give you any idea how many frames
> were transmitted or how many frames were received.
> 
> There could be two options:
> 
> - (1) have one NumCellsUsed variables per direction
> - (2) count only transmissions in NumCellsUsed; dedicated RX cells are
>        scheduled via 6P transactions initiated by the peer
> 
> If you want 6P transactions initiated only by a child, the first one
> is the choice.
> 
> 
> [3] How do we choose dedicated cell to be deleted?
> 
> draft> 4.1.  Adapting to Traffic
> draft> ...
> draft>    2.  When the value of NumCellsPassed reaches MAX_NUMCELLS:
> draft>
> draft>        *  If NumCellsUsed > LIM_NUMCELLSUSED_HIGH, trigger 6P to add a
> draft>           single cell to the preferred parent
> draft>        *  If NumCellsUsed < LIM_NUMCELLSUSED_LOW, trigger 6P to remove a
> draft>           single cell to the preferred parent
> 
> How do we choose cells to be set in CellList of a 6P DELETE request?
> They should be randomly chosen? Or, they should be chosen in order
> from the lowest PDR cell?
> 
> NumCellsUsed in that bullet list should be (NumCellsUsed /
> NumCellsPassed) or ((NumCellsUsed / NumCellsPassed * 100), by the way.
> 
> 
> [4] (trivial comment)
> 
> draft> 4.2.  Switching Parent
> draft> ...
> draft>    1.  the node counts the number of dedicated cells it has per
> draft>        slotframe to the old preferred parent
> draft>    2.  the node triggers one or more 6P ADD commands to schedule the
> draft>        same number of dedicated cells to the new preferred parent
> 
> To be precise, it'd better to mention about cell options as well as
> how many dedicated cells are scheduled.
> 
> 
> [5] questions in Handling Schedule Collisions
> 
> draft> 4.3.  Handling Schedule Collisions
> draft> ...
> draft>   Each time the node switches preferred parent (or during the join
> draft>   process when the node selects a preferred parent for the first time),
> draft>   both NumTx and NumTxAck MUST be reset to 0.  They increment over
> 
> When should a parent reset NumTx and NumTxAck for a dedicated cell?
> 
> Another question related to this topic: how does a parent remove a
> dedicated cell scheduled during the join process if the child leaves
> without a successful 6P command transaction?
> 
> draft> 4.3.  Handling Schedule Collisions
> draft> ...
> draft>    The key for detecting a schedule collision is that, if a node has
> draft>    several cells to the same preferred parent, all cells should exhibit
> draft>    the same PDR.  A cell which exhibits a PDR significantly lower than
> draft>    the others indicates than there are collisions on that cell.
> 
> Do we exclude a dedicated cell having SHARED bit on for this collision
> detection? If it's excluded, how do we handle collisions on such a
> dedicated cell? If it's not excluded, a dedicated cell having SHARED
> bit on tends to be relocated since usually it could have lower PDR
> than other dedicated cells which doesn't have SHARED bit on. How do we
> cope with this situation?
> 
> draft> 4.3.  Handling Schedule Collisions
> draft> ...
> draft>    2.  Any cell that hasn't yet had NumTx divided by 2 since it was last
> draft>        reset is skipped in steps 3 and 4.  This avoids triggering cell
> draft>        relocation when the values of NumTx and NumTxAck are not
> draft>        statistically significant yet.
> 
> Does this mean, skip 3 and 4 for cells whose NumTx have never been
> divided by 2 (never reached 256)? I'm not sure the meaning of "since
> it was last reset".
> 
> 
> That's it! Thank you.
> 
> Best,
> Yatch
> 
> 
> _______________________________________________
> 6tisch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tisch
>