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

[<[e-mail]>]

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?


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


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


- Section 5.2: parent switch

We can now remove items 1. and 2. because we don't have AutoUpCells.


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


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


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