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

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Tengfei

Many thanks for this update : )

Please find some comments below


“
   To ensure there is enough bandwidth available on the minimal cell, a
   node implementing MSF SHOULD enforce some rules for limiting the
   traffic of broadcast frames.  For example, a Trickle Timer defined in
   [RFC6550<https://tools.ietf.org/html/rfc6550>] MAY be applied on DIOs.  However, this behvaior is
   implementation-specific which is out of the scope of MSF.

“
As you point out that text does not really belong here. Maybe just say that the normal operation of this spec requires some bandwidth available, e.g., on the minimal cell.
Typo in behavior


“4.1<https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-4.1>.  Start State
“
This phase also includes a 6LoWPAN ND phase to exchange link local addresses with the JP and later with the 6LR. Seems that some implementation bypass that but that’s really not clean. Suggestion to add a reference to https://tools.ietf.org/html/draft-ietf-6tisch-architecture-24#section-4.2 to describe that phase and say that it requires both minimal sec ad 6LoWPAN ND (now RFC 8505).


“

      Autonomous Tx Cell (AutoTxCell), one cell at a

      [slotOffset,channelOffset] computed as a hash of the layer 2 EUI64

      source address in the frame to be transmitted (detailed in

      Section 4.4<https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-4.4>).  Its cell options bits are assigned as TX=1, RX=0,

      SHARED=1.
“
You mean the destination address as opposed to source address?


“

   During this step, the pledge MAY synchronize to any EB it receives

   from the network it wishes to join.
“
In TSCH, time creates an event horizon whereby one only hears transmissions that start during guard time around the scheduled Rx time. If the text quoted above means only listen to timeslots that are aligned to the time in the particular EB, then the node will no more hear beacons that are not aligned with this. E.g., an attacker could offset EBs by 2ms from the network and nodes that synchronize will not hear other beacons any more. So a suggestion is that a node that listen to beacons does not synchronize till it has heard the count of beacons it is supposed to get.


“
4.5<https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-4.5>.  Step 4 - Acquiring a RPL rank


   Per [RFC6550<https://tools.ietf.org/html/rfc6550>], the joined node receives DIOs, computes its own rank,
   and selects a preferred parent.

“

Suggestion to uppercase Rank like in RFC 6550


“
8<https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-8>.  Rules for CellList

“
Maybe add a rule to listen to the cells for a few slotframes to ensure that they are not used by neighbors. This can be done proactively, like the node monitors the 5 randomly chosen cells all the time, even when there is no excess traffic, so a list of empty cells is ready when needed.


“
6P Timeout Value

“
I guess it is per peer? Shouldn’t it evolve like the RTO in RFC 6298 ?


“

   | IANA_6TISCH_SFID_MSF | Minimal Scheduling Function | RFCXXXX     |
   |                      | (MSF)                       | (NOTE:this) |

“

  *   maybe

   | IANA_6TISCH_SFID_MSF | Minimal Scheduling Function | RFC_THIS    |
   |                      | (MSF)                       |             |


All the best,

Pascal

From: 6tisch <[e-mail]> On Behalf Of Tengfei Chang
Sent: mardi 2 juillet 2019 12:57
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