[6tisch] Review of draft-ietf-6tisch-msf-03

[Yasuyuki Tanaka <[e-mail]>]

Thank you, the authors!

I confirmed most of my comments to the previous version have been
addressed. It reads better :-)

Here are my comments: two comments are major, the rest are minor.


[major: usage of the autonomous cell and the managed cell]

The draft specifies rules what type of frames MUST be sent over the
autonomous cell. How can we implement the rules on top of TSCH MAC
defined by IEEE802.15.4?

https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-3
draft-03>  The traffic on the autonomous cells are scheduled as:
draft-03>
draft-03>  o  Join Request packets and 6P ADD/DELETE Request frames to the
draft-03>     node's Join Proxy or its RPL routing parent MUST be sent on
draft-03>     AutoUpCell.
draft-03>  o  Join Response packets and 6P ADD/DELETE Response frames to the
draft-03>     pledge or its RPL routing child MUST be sent on AutoDownCell.
draft-03>  o  6P RELOCATE Request frames to the node's RPL routing child MUST be
draft-03>     sent on AutoDownCell.
draft-03>  o  6P RELOCATE Response frames to its RPL routing parent MUST be sent
draft-03>     on AutoUpCell.

https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-5.1
draft-03>   Adding/removing/relocating cells involves exchanging frames that
draft-03>   contain 6P commands.  All 6P Request frames to its parent MUST be
draft-03>   sent on the AutoUpCell All 6P Response frames to non-parent neighbor
draft-03>   MUST be sent on AutoDownCell.

At draft-ietf-6tisch-msf-02, the autonomous cell and the managed cell
to the same neighbor are used without distinction. This is totally
fine and straightforward. Why do we need the change to this part?

https://tools.ietf.org/html/draft-ietf-6tisch-msf-02#section-5.1
draft-02>   Autonomous cells are used indistinguishably
draft-02>   together with dedicated cells, for broadcast or unicast traffic with
draft-02>   the target neighbor.  The procedure to remove autonomous cells is
draft-02>   described in Section 3.

To my understandings, TSCH MAC selects a cell (link) to transmit a
frame seeing macTxType, macLinkType, and macNodeAddress of the cell,
which are defined in section 8.4.2.2.2 of IEEE802.15.4-2015. TSCH MAC
cares only the destination MAC address and the frame type of a TX
frame, doesn't it?


[major: some confusions in Section 5]

We don't need to maintain NumCellsElapsed and NumCellsUsed for RX
cells because managed cells have always only TX=1.

https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-5.1
draft-03>   NumCellsElapsed :  Counts the number of managed cells that have
draft-03>       elapsed since the counter was initialized.  This counter is
draft-03>       initialized at 0.  Each time the TSCH state machine indicates
draft-03>       that the current cell is a managed cell to the preferred parent,
draft-03>       NumCellsElapsed is incremented by exactly 1, regardless of
draft-03>       whether the cell is used to transmit/receive a frame.

"to transmit/receive a frame" in the last sentence should be replaced
with "to transmit a frame", and

draft-03>   Both NumCellsElapsed and NumCellsUsed counters can be used to cell
draft-03>   with cell option TX=1 or RX=1.

"with cell option TX=1 or RX=1" should be replaced with "with cell
option TX=1"?

Another thing is related to what Fabrice pointed out. There is
something wrong in text about the RELOCATE operation. Since NumTx and
NumTxAck are the key counters for the RELOCATE operation, a RELOCATE
request is never issued for an RX cell. Then, the direction in the
following text is opposite...

https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-3
draft-03>  o  6P RELOCATE Request frames to the node's RPL routing child MUST be
draft-03>     sent on AutoDownCell.
draft-03>  o  6P RELOCATE Response frames to its RPL routing parent MUST be sent
draft-03>     on AutoUpCell.

One more thing:

https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-5.3
draft-03>  4.  For any other cell, it compares its PDR against that of the cell
draft-03>      with the highest PDR.  If the different is less than
draft-03>      RELOCATE_PDRTHRES, it triggers the relocation of that cell using
draft-03>      a 6P RELOCATE command.

- s/different/difference/
- s/less than/larger than/ ??

Can you check the entire text in Section 5?


[minor comment #1]

https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-2
draft-03>   For example, a Trickle Timer defined in [RFC6550] MAY be
draft-03>   applied on DIOs.

Do we need "MAY" here? If you implement RFC6550, DIO is automatically
controlled by Trickle Timer.


[minor comment #2]

https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-3
draft-03>   MUST use the hash function SAX [SAX-DASFAA].  The coordinates are
draft-03>   computed to distribute the cells across all channel offsets, and all
draft-03>   but the first time offsets of Slotframe 1.  The first time offset is
draft-03>   skipped to avoid colliding with the minimal cell in Slotframe 0.

s/time offset/slot offset/


[minor comment #3]

https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-3
draft-03>    o  slotOffset(MAC) = 1 + hash(EUI64, length(Slotframe_1) - 1)
draft-03>    o  channelOffset(MAC) = hash(EUI64, 16)
draft-03>
draft-03>    The second input parameter defines the maxmium return value of the
draft-03>    hash function.

The second input should be "the maximum return value plus 1", which
is the parameter 'T' of SAX.

https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#appendix-B
draft-03>   In MSF, the T is replaced by the length slotframe 1.  String s is
draft-03>   replaced by the mote EUI64 address.  The characters of the string c0,
draft-03>   c1, ..., c7 are the 8 bytes of EUI64 address.

This may be misleading. The first sentence could be...

  For slotOffset(), T is the length of the slotframe 1. For
  channelOffset(), T is the number of available channels.


[minor comment #4]

https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-3
draft-03>   The second input parameter defines the maxmium return value of the
draft-03>   hash function.  There are other optional parameters defined in SAX
draft-03>   determines the performance of SAX hash function.  Those parameters
draft-03>   could be broadcasted in EB frame or pre-configured.

What parameters...? The parameters to configure are be h0, l_bit,
and r_bit, I believe.

By the way, s/maxmium/maximum/


[minor comment #5]

https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-5.1
draft-03>   Implementors MAY choose to create the same counters for each
draft-03>   neighbor, and add them as additional statistics in the neighbor
draft-03>   table.

https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-5.3
draft-03>   Implementors MAY choose to maintain the same counters for each
draft-03>   managed cell in the schedule.

For what purposes? Do we need these sentences?


[minor comment #6]
Want to have test vectors of SAX! :-)


[minor comment #7]


https://tools.ietf.org/html/draft-ietf-6tisch-msf-03#section-5.1
draft-03>       *  If NumCellsUsed > LIM_NUMCELLSUSED_HIGH, trigger 6P to add a
draft-03>          single cell to the preferred parent
draft-03>       *  If NumCellsUsed < LIM_NUMCELLSUSED_LOW, trigger 6P to remove a
draft-03>          single cell to the preferred parent

It would be better to put "managed" there:

proposed>       *  If NumCellsUsed > LIM_NUMCELLSUSED_HIGH, trigger 6P to add a
proposed>          single managed cell to the preferred parent
proposed>       *  If NumCellsUsed < LIM_NUMCELLSUSED_LOW, trigger 6P to remove a
proposed>          single managed cell to the preferred parent


[minor comment #8]

s/Tx Cell/TX cell/
s/Tx cell/TX cell/

Best,
Yatch