Re: [6tisch] call for review: draft-ietf-6tisch-msf-04

[Tengfei Chang <[e-mail]>]

Hi Toshio,

Thanks for reviewing the draft, let me reply you inline below:

On Thu, Jul 4, 2019 at 4:16 AM <[e-mail]> wrote:

> Thanks for the update, Tengfei.
>
>
>
> I think Auto{Tx,Rx}Cells are simpler than Auto{Up,Down}Cells, because
>
> they are independent of parent switching.
>
>
>
> Here are my comments.
>
>
>
>
>
> - Section 3: address for AutoTxCells
>
>
>
> msf-04> Autonomous Tx Cell (AutoTxCell), one cell at a
>
> msf-04> [slotOffset,channelOffset] computed as a hash of the layer 2
>
> msf-04> EUI64 source address in the frame to be transmitted
>
> msf-04>
>
> msf-04> ...
>
> msf-04>
>
> msf-04> Add an AutoTxCell to the layer 2 source address which is
>
> msf-04> indicated in a frame when:
>
>
>
> The destination address (not source address) of the frame should be
>
> used to calculate the AutoTxCell, shouldn't it?
>

Yes, it should. Thanks for indicating it! Will be fixed in next version.

>
>
>
>
> - Section 3: conflict between autonomous and negotiated cells
>
>
>
> msf-04> In case of conflicting with a negotiated cell, autonomous
>
> msf-04> cells take precedence over negotiated cell.
>
>
>
> Now that autonomous cells and negotiated cells are in different
>
> slotframes, this statement is a natural result of Section 6.2.6.4 of
>
> IEEE 802.15.4-2015. I think it's a good idea to refer to it here.
>

Yes,  will be added in next version.

>
>
>
>
> - Section 5.1: CellOptions of 6P ADD
>
>
>
> There is no specification on CellOptions (Tx/Rx/Shared) of 6P ADD
>
> requests as a result of traffic adaptation. Is it up to implemtation?
>

Yes, it's kind of implied in the draft that it can be Tx=1 only or Rx=1
only.
Will add this statement in the draft next version.

>
>
>
>
> - Section 5.2: parent switch
>
>
>
> We can now remove items 1. and 2. because we don't have AutoUpCells.
>

Removed. Thanks!

>
>
>
>
> - Section 5.3: counters for handling schedule collision
>
>
>
> msf-04> The node MUST maintain the following counters for each managed
>
> msf-04> unicast cell to its preferred parent:
>
>
>
> I think the node should maintain the counters for each negotiated Tx
>
> cell to ANY neighbor, not only to the preferred parent. That is
>
> because schedule collision can occur to any Tx cell.
>
>
>
> If a node had counters for each neighbor, the paragraph starting with
>
> the following sentance would be unnecessary.
>
>
>
> msf-04> Each time the node switches preferred parent (or during the
>
> msf-04> join process when the node selects a preferred parent for the
>
> msf-04> first time), both NumTx and NumTxAck MUST be reset to 0.
>
>
>
> Although managing the counters for each neighbor is conceptually
>
> simple, I admit it might be too much overhead for constrainted nodes.
>

Thanks for the comments! However, along the network time, the node won't
send upper layer packet s to non-parent neighbor.
In case of switching parent, the traffic will go on autoTx cell.

>
>
>
>
> BTW, there are still two occurrences of "managed unicast cell" in the
>
> draft.
>

Will corrected in next version.

>
>
>
>
> Best regards,
>
> Toshio Ito
>
>
>
> *From:* 6tisch <[e-mail]> *On Behalf Of *Tengfei Chang
> *Sent:* Tuesday, July 02, 2019 7:57 PM
> *To:* [e-mail]
> *Subject:* [6tisch] call for review: draft-ietf-6tisch-msf-04
>
>
>
> Dear all,
>
>
>
> As you may noticed that a new version of MSF is just published at here:
>
> https://tools.ietf.org/html/draft-ietf-6tisch-msf-04
>
> There are some moderate changes comparing to previous one.
>
>
>
> Mainly in two aspects:
>
>
>
> 1. change the concept of autonomous cell
>
>
>
> In the new version, there will be two type of autonomous cells:
>
> - autoTxCell, which is scheduled on demand for just transmitting
>
> -autoTxCell, which is schedule permanently, for just receiving
>
> (the previous version the autonomous cell are used as bidirectional)
>
>
>
> More details about how to use those autonomous cell is available in the
> draft.
>
>
>
> 2. re-added the downstream traffic adaptation feature
>
>
>
> Though, there are cases that the node doesn't receive packet because of
> collision, we assume the influence won't be much to adapt the downstream
> traffic.
>
> We will evaluate the performance of this changes.
>
>
>
> We are targeting to have a new version before the submission deadline.
>
> During the time, we will evaluate the v4 MSF and would like to have your
> comments as well.
>
>
>
> Thanks in advance!
>
>
>
> Tengfei
>
>
>
> --
>
> Chang Tengfei,
>
> Postdoctoral Research Engineer, Inria
>


-- 
Chang Tengfei,
Postdoctoral Research Engineer, Inria