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

[Tengfei Chang <[e-mail]>]

Hi Yatch,

Thanks for the reviewing! I will reply your comments inline.

On Tue, Apr 9, 2019 at 2:03 PM Yasuyuki Tanaka <[e-mail]>
wrote:

> 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.
>

TC: For implementing, it requires some flag for the frame to mark as what
type of 6P frames.
TC: I agree that there are other frames that should be able to send on the
autonomous cell according to IEEE802.15.4 standards.
TC: Here is to limit the type frames on one cell but it doesn't break what
defined in IEEE802.15.4 standards, IMO.

>
> 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?
>

TC: this is to avoid the failure of 6P frames on inconsistent managed cell,
for example, the node has a Tx cell to parent but the parent doesn't have
the RX cell.
TC: Though, it will be resolved at next 6P transaction (two transactions
actually), it will be underperformance.

>
> 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?
>
> TC: It does in IEEE802.15.4 standard.
TC: I am just not considering instead of caring only the destination MAC
address and frame type, caring about more parameters is not a violation of
standard.
TC: Though, just in my opinion.

>
> [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.
>

TC: yes, accepted this comment.
TC: As replied to Fabrice, I will remove the RX=1 cell case for the
adapting traffic strategy in next version..

>
> 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?
>

TC: sure. Sorry for the confusing! Will be clarified in next version.

>
>
> [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.
>
> TC: yes, it's a requirement.

>
> [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/
>
> TC: Thanks! I will go over the draft to make sure this is consistent.

>
> [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.
>

TC: That's correct! Will be fixed.

>
> 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.
>
> TC: Will be applied in next verison. Thanks!

>
> [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.
>

TC: yes, I didn't say that but presented in the example section. Maybe I
should mention there though.

>
> By the way, s/maxmium/maximum/
>

TC: will be fixed! Thanks!

>
>
> [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?
>

TC: For parent selection. In case parent switching happens, those counters
can record the link quality of previous parent for future parent selection.

>
>
> [minor comment #6]
> Want to have test vectors of SAX! :-)
>
> TC: like givem a node EUI64 address, to have the slotoffset and choffset?
we could.

>
> [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
>

TC: will put in next version!

>
>
> [minor comment #8]
>
> s/Tx Cell/TX cell/
> s/Tx cell/TX cell/
>

TC: Will go through the text in the next version about the consistency!
Thanks!

>
> Best,
> Yatch
>
> _______________________________________________
> 6tisch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tisch
>


-- 
Chang Tengfei,
Postdoctoral Research Engineer, Inria