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

[Yasuyuki Tanaka <[e-mail]>]

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