[6tisch] Thomas' review of draft-ietf-6tisch-msf-02

[Thomas Watteyne <[e-mail]>]

Authors, 

Please find below my review of draft-ietf-6tisch-msf-02. It's a patch file to the txt version of the draft. 

You will find inline fixes of typos, and comments, which start at the new line with "TW>" 

Overall, the draft is in good shape. The recommendations I make are editorial. The biggest remark is that the draft mixes the terms "dedicated cells" and "managed cells". I also would like to see some text that describes the reasoning between "autonomous SHARED cells" and "autonomous non-SHARED cells". Also, because those terms are obscure, you could replace them throughout by "autonomous upstream cells" and "autonomous downstream cells". 

Thomas 

===== 

diff --git "a/C:\\Users\\twatteyn\\AppData\\Local\\Temp\\TortoiseGit\\draft-ietf-6tisch-msf-02-54bdb6a.000.txt" "b/C:\\Users\\twatteyn\\Desktop\\ietf\\draft-ietf-6tisch-msf-02.txt" 
index 89514c6..49e59bb 100644 
--- "a/C:\\Users\\twatteyn\\AppData\\Local\\Temp\\TortoiseGit\\draft-ietf-6tisch-msf-02-54bdb6a.000.txt" 
+++ "b/C:\\Users\\twatteyn\\Desktop\\ietf\\draft-ietf-6tisch-msf-02.txt" 
@@ -135,10 +135,9 @@ Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) March 2019 
The 6TiSCH Minimal Scheduling Function (MSF), defined in this 
specification, is a 6TiSCH Scheduling Function (SF). The role of an 
- SF is entirely defined in [RFC8480]: it complements [RFC8480] by 
+ SF is entirely defined in [RFC8480]. This specification complements [RFC8480] by 
providing the rules of when to add/delete cells in the communication 
- schedule. The SF defined in this document follows that definition, 
- and satisfies all the requirements for an SF listed in Section 4.2 of 
+ schedule. This specification satisfies all the requirements for an SF listed in Section 4.2 of 
[RFC8480]. 
MSF builds on top of the following specifications: the Minimal IPv6 
@@ -153,11 +152,11 @@ Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) March 2019 
the 7 steps described in Section 4. The end state of the join 
process is that the node is synchronized to the network, has mutually 
authenticated to the network, has identified a preferred routing 
- parent, has scheduled one default managed unicast cell (defined in 
+ parent, and has scheduled one default managed unicast cell (defined in 
Section 5.1) to/from its preferred routing parent. After the join 
process, the node can continuously add/delete/relocate cells, as 
described in Section 5. It does so for 3 reasons: to match the link- 
- layer resources to the traffic, to handle changing parent, to handle 
+ layer resources to the traffic, to handle changing parent, or to handle 
a schedule collision. 
MSF is designed to operate in a wide range of application domains. 
@@ -172,18 +171,19 @@ Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) March 2019 
the nodes to the root). Appendix C contains a performance evaluation 
of MSF. 
+TW> I would remove this sentence, as Appexdix C might be removed 
This specification follows the recommended structure of an SF 
- specification in Appendix A of [RFC8480], with the following 
+ specification, given in Appendix A of [RFC8480], with the following 
adaptations: 
- o We have reordered part of the sections, in particular to have the 
- section on the node behavior at boot Section 4 appear early in 
+ o We have reordered some sections, in particular to have the 
+ section on the node behavior at boot (Section 4) appear early in 
this specification. 
o We added sections on the interface to the minimal 6TiSCH 
- configuration Section 2, the use of the SIGNAL command Section 6, 
- the MSF constants Section 14, the MSF statistics Section 15, the 
- performance of MSF Appendix C. 
+ configuration (Section 2), the use of the SIGNAL command (Section 6), 
+ the MSF constants (Section 14), the MSF statistics (Section 15), and the 
+ performance of MSF (Appendix C). 
o This specification does not include an examples section. 
2. Interface to the Minimal 6TiSCH Configuration 
@@ -193,8 +193,9 @@ Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) March 2019 
shared cell providing minimal connectivity between the nodes in the 
network. The MSF implementation provided in this specification is 
based on the implementation of the Minimal 6TiSCH Configuration. An 
- implementor with full-awareness of the Minimal 6TiSCH Configuration 
+ implementor with full awareness of the Minimal 6TiSCH Configuration 
implications MAY implement MSF without it. 
+TW> I don't understand the statement "with full awareness of the Minimal 6TiSCH Configuration". Rephrase. 
MSF uses the minimal cell to exchange the following packets: 
@@ -203,6 +204,7 @@ Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) March 2019 
2. DODAG Information Objects (DIOs), defined by [RFC6550], with 
broadcast type. Unicast type DIOs SHOULD NOT be sent on minimal 
cell. 
+TW> just say "broadcast DIOs" and "unicast DIO". "Broadcast type" doesn't mean much. 
Because the minimal cell is SHARED, the back-off algorithm defined in 
[IEEE802154-2015] is used to resolve collisions. To ensure there is 
@@ -214,7 +216,7 @@ Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) March 2019 
2. send any other broadcast packets on a portion of the minimal 
cells not exceeding 1/(3(N+1)), where N is the number of 
neighbors of the node. For example, the broadcast DIO and DIS, 
- IPv6 Neighbor Discovery (ND)[RFC4861] and any other application 
+ IPv6 Neighbor Discovery (ND) [RFC4861] and any other application 
layer broadcast packets. 
@@ -229,8 +231,8 @@ Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) March 2019 
The RECOMMENDED behavior for sending EBs is to have a node send EBs 
with a probability of 1/(3(N+1)). The RECOMMENDED behavior for 
sending DIOs is to use a Trickle timer with rate-limiting. There is 
- no recommendation behavior for sending any other broadcast. However, 
- the traffic portion of all broadcast packets on minimal cell, except 
+ no recommended behavior for sending any other broadcast frame. However, 
+ the traffic portion of all broadcast frames on the minimal cell, except 
EBs, MUST not exceed 1/(3(N+1)). 
Section 4.3 describes how to evaluate the number of neighbors during 
@@ -240,31 +242,33 @@ Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) March 2019 
As detailed in Section 2.2 of [RFC8480], MSF MUST schedule cells from 
Slotframe 1, while Slotframe 0 is used for traffic defined in the 
Minimal 6TiSCH Configuration. The length of Slotframe 0 and 
- Slotframe 1 SHOULD be the same value. The default of 
+ Slotframe 1 SHOULD be the same value. The default value of 
SLOTFRAME_LENGTH is RECOMMENDED for both Slotframe 0 and Slotframe 1, 
- although any value can be advertised in the EBs. 
+ although any value can be used, and advertised in the EBs. 
+TW> minimal is not required, yet there is a MUST here. I suggest you start this paragraph by a statement such as "If MSF is used together with the ..." 
3. Autonomous Cells 
MSF nodes MUST initialize Slotframe 1 with a set of default cells for 
- unicast communication with their neighbors. These cells are referred 
- to as 'autonomous cells', because they are maintained autonomously by 
- each node. To distinguish from the autonomous cells, the cell 
- scheduled by 6P transaction is defined as 'managed cells'. How to 
+ unicast communication with their neighbors. 
+TW> remove the MUST? 
+ These cells are 
+ called "autonomous cells", because they are maintained autonomously by 
+ each node. Cells 
+ scheduled by 6P transactions are called "managed cells". How to 
schedule managed cells is detailed in Section 5. For autonomous 
cells, each node has: 
- o One cell at a [slotOffset,channelOffset] computed as a hash of the 
- node's EUI64 (detailed next). The cell options for this cell are 
+ o One cell at a [slotOffset,channelOffset] computed as a hash of its own EUI64 (detailed next). The cell options for this cell are 
TX=1, RX=1, SHARED=0. 
o One cell at a [slotOffset,channelOffset] computed as a hash of the 
- EUI64 of the Join Proxy or each neighbor in the IPv6 neighbor 
- table (detailed in Section 4.4 and Section 4.5). The cell options 
+ EUI64 for each neighbor in the IPv6 neighbor 
+ table, including the Join Proxy (detailed in Section 4.4 and Section 4.5). The cell options 
for this cell are TX=1, RX=1, SHARED=1. 
To compute a [slotOffset,channelOffset] from an EUI64 address, nodes 
MUST use the hash function SAX [SAX-DASFAA]. The coordinates are 
- computed to distribute the cells across all 16 channel offsets, and 
+ computed to distribute the cells across all channel offsets, and 
all but the first time offsets of Slotframe 1. The first time offset 
is skipped to avoid colliding with the minimal cell in Slotframe 0. 
The slot coordinates derived from a given EUI64 address are computed 
@@ -272,7 +276,7 @@ Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) March 2019 
o slotOffset(MAC) = 1 + hash(EUI64, length(Slotframe_1) - 1) 
o channelOffset(MAC) = hash(EUI64, 16) 
- 
+TW> don't you need a modulo operator here? THe hash function can return a very large number. 
@@ -282,11 +286,13 @@ Chang, et al. Expires September 12, 2019 [Page 5] 
Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) March 2019 
- For interoperability purpose, an example how the hash function is 
+ For interoperability purposes, an example how the hash function is 
implemented is detailed in Appendix B. 
- Because of hash collisions, there are cases where the autonomous 
- SHARED and non-SHARED cells are scheduled at the same time offset 
+ Because of hash collisions, there will be cases when the autonomous 
+ SHARED and non-SHARED cells 
+TW> what do you call "autonomous SHARED and non-SHARED cells"? Do you mean autonomous and managed cells? 
+ are scheduled at the same time offset 
and/or channel offset. Hash collisions among a set of cells at a 
given time offset is resolved at run-time as follows: 
@@ -294,29 +300,33 @@ Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) March 2019 
precedence. 
o If all SHARED cells have empty outgoing queues, the non-SHARED 
cell takes precedence. 
+TW> please specify what you mena by SHARED and non-SHARED 
Both SHARED and non-SHARED autonomous cells are scheduled to transmit 
unicast packets. The autonomous SHARED cells can only be used to 
- transmit packets to the neighbor whose EUI64 address is used in hash 
- function to create this cell. The autonomous non-SHARED cells can be 
+ transmit packets to the neighbor whose EUI64 address is used in the hash 
+ function to schedule this cell. Autonomous non-SHARED cells can be 
used to transmit packet to any neighbors. The traffic on the 
autonomous cells are scheduled as: 
- o The Join Request MUST be sent on a SHARED cell, the 6P Request 
- packet MAY be sent on a SHARED cell. 
- o The Join Response MUST be sent on a non-SHARED cell, the 6P 
- Response packet MAY send on a non-SHARED cell. 
+ o Join Request packets MUST be sent on SHARED cells. 
+ o Join Response packets MUST be sent on non-SHARED cells. 
+ o 6P Request frames MAY be sent on SHARED cells. 
+ o 6P Response frames MAY be sent on non-SHARED cells. 
Throughout the network lifetime, nodes MUST maintain the autonomous 
cells as follows: 
o The non-SHARED cell MUST always remain scheduled. 
+TW> what do you mean? 
o Whenever a new IPv6 neighbor is discovered, add a SHARED cell for 
it. 
o Whenever an IPv6 neighbor is removed, remove the SHARED cell that 
was assigned to it. 
o 6P CLEAR MUST NOT erase autonomous cells. 
+TW> The whole terminology of shared and non-shared autonomous cells is confusing, as it is used following a paragraph that explains that there are autonomous and managed cells. Please start by explaining, possibly with an example/diagram, what you mean. 
+ 
4. Node Behavior at Boot 
This section details the behavior the node SHOULD follow from the 
@@ -342,9 +352,10 @@ Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) March 2019 
A node implementing MSF MUST implement the Minimal Security Framework 
for 6TiSCH [I-D.ietf-6tisch-minimal-security]. As a corollary, this 
- means that a pledge, before being switched on, is pre-configured with 
+ means that a pledge, before being switched on, may be pre-configured with 
the Pre-Shared Key (PSK) for joining, as well as any other 
configuration detailed in [I-D.ietf-6tisch-minimal-security]. 
+ This is not needed if the node implements a security solution not based on PSKs, such as [draft-ietf-6tisch-dtsecurity-zerotouch-join]. 
4.2. Step 1 - Choosing Frequency 
@@ -377,14 +388,15 @@ Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) March 2019 
The decision of which neighbor to use as a JP is implementation- 
specific, and discussed in [I-D.ietf-6tisch-minimal-security]. 
-4.4. Step 3 - Setting up Autonomous Cells during Join Process 
+4.4. Step 3 - Setting up Autonomous Cells during the Join Process 
- After selected the JP, nodes MUST set up their autonomous SHARED 
- cells, as described in Section 3. A Join Request is sent then by 
- pledge to its JP. The JP forwards the request/response between the 
- JRC and the JP, possibly over multiple hops. When JP received the 
- Join Response from JRC, it sends a Join Response to the pledge, where 
- the pledge learns the keying material used in the network, as well as 
+ After selected a JP, a node MUST set up autonomous SHARED 
+ cells to that JP, as described in Section 3. A Join Request is then sent by the 
+ pledge to its JP. The JP forwards the Join Request to the JRC, possibly over multiple hops. 
+ Similarly, the JRC sends the Join Response to the JP, possibly over multiple hops. 
+ When the JP receive the 
+ Join Response from the JRC, it sends that Join Response to the pledge. 
+ The pledge thereby learns the keying material used in the network, as well as 
other configurations, and becomes a "joined node". The Join Request 
@@ -394,31 +406,27 @@ Chang, et al. Expires September 12, 2019 [Page 7] 
Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) March 2019 
- and Response traffics are happened on the autonomous cells, which are 
+ and Response traffic happens on autonomous cells, which are 
scheduled as following: 
- o The Joining Request packet MUST be sent on the autonomous SHARED 
- cell to the JP by the pledge. A retransmition with backoff 
- mechanism will be sent later if collision happens. 
- o The Joining Response packet MUST be sent on the autonomous non- 
- SHARED cell to the pledge by the JP. A retransmition will be sent 
- immediately at next autonomous non-SHARED cell if collision 
- happens. 
+ o The Join Request MUST be sent on the autonomous SHARED 
+ cell the pledge has to the JP. Because it is SHARED, a back-off mechanism kicks in at the plegde when it doesn't receive a link-layer response. 
+ o The Join Response MUST be sent on the autonomous non- 
+ SHARED cell the JP has to be pledge. Because it is non-SHARED, the JP retransmit immediately it case it doesn't receive a link-layer response (i.e. there is no back-off). 
- After joined, nodes MUST set up their autonomous non-SHARED cell, as 
- described in Section 3. The root node MUST set up its autonomous 
- non-SHARED cell when it is configured as root. 
+ After joining, nodes MUST set up their autonomous non-SHARED cell, as 
+ described in Section 3. The root node is consider "joined" as soon as it is configured as root. 
4.5. Step 4 - Installing Autonomous Cells for each neighbor in neighbor 
table 
Because it has learnt the link-layer keying material used in the 
- network, the joined node can now decrypt any packets sent by its 
- neighbors. Once a new neighbor is added to the neighbor table, a new 
- autonomous SHARED cell MUST be added to that neighbor. The 
+ network, a joined node can decrypt any packets sent by its 
+ neighbors. Once a new neighbor is added a node's neighbor table, the node MUST add 
+ an autonomous SHARED cell to that neighbor. The 
autonomous SHARED cell MUST be removed if the corresponding neighbor 
- is removed from the neighbor table. How to decide the neighbors to 
- keep in neighbor table is implementation-specific. 
+ is removed from the neighbor table. How to decide which neighbors to 
+ remove in the neighbor table is implementation-specific. 
4.6. Step 5 - Acquiring a RPL rank 
@@ -459,6 +467,7 @@ Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) March 2019 
managed unicast cells with that neighbor from its own schedule. In 
addition, it MAY issue a 6P CLEAR to that neighbor (which can fail at 
the link-layer). The node MAY be removed from the neighbor table. 
+TW> some context or condition is missing from this last sentence. 
If so, the autonomous SHARED cell will be removed following the 
procedure described in Section 3. 
@@ -472,10 +481,11 @@ Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) March 2019 
o it has identified its preferred routing parent 
o it has one autonomous non-SHARED cell and a set of autonomous 
SHARED cells to/from its neighbors 
+TW> split in multiple bullet points for SHARED and non-SHARED 
o it is periodically sending DIOs, potentially serving as a router 
for other nodes' traffic 
o it is periodically sending EBs, potentially serving as a JP for 
- new joining nodes 
+ new pledges 
5. Rules for Adding/Deleting Cells 
@@ -526,13 +536,16 @@ Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) March 2019 
removed by 6P, so that there always exists an autonomous cell between 
a node and its preferred parent, even if no frames are being 
exchanged between them. Autonomous cells are used indistinguishably 
- together with dedicated cells, for broadcast or unicast traffic with 
+TW> what do you mean by "used indistinguishably"? 
+ together with dedicated cells, 
+TW> previously, you used the term managed cells but now dedicated. I suggest you use the term managed throughout 
+ for broadcast or unicast traffic with 
the target neighbor. The procedure to remove autonomous cells is 
described in Section 3. 
Adding/removing/relocating cells involves exchanging frames that 
- contain 6P commands. All 6P frames MUST be sent on the autonomous 
- cell or managed cell if the node has. 
+ contain 6P commands. All 6P frames MUST be sent on autonomous 
+ or managed cells. 
The node MUST maintain the following counters for its preferred 
parent: 
@@ -551,9 +564,7 @@ Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) March 2019 
* The node sends a frame to its preferred parent. The counter 
increments regardless of whether a link-layer acknowledgment 
was received or not. 
- * The node receives a frame from its preferred parent. The 
- frame MUST be able to decrypt with the key assigned during 
- joining process. 
+ * The node receives a frame from its preferred parent, and unsecuring of that frame is successful. 
@@ -570,36 +581,39 @@ Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) March 2019 
1. Both NumCellsElapsed and NumCellsUsed are initialized to 0 when 
the node boots. 
- 2. After End State defined in Section 4.9, if there is no managed 
- unicast cell to the preferred parent, trigger 6P to add a signle 
+ 2. After the End State defined in Section 4.9, if there is no managed 
+ unicast cell to the preferred parent, trigger 6P to add a 
cell to it. 
3. When the value of NumCellsElapsed reaches MAX_NUMCELLS: 
* If NumCellsUsed > LIM_NUMCELLSUSED_HIGH, trigger 6P to add a 
- single cell to the preferred parent 
+ cell to the preferred parent 
* If NumCellsUsed < LIM_NUMCELLSUSED_LOW, trigger 6P to remove a 
- single cell to the preferred parent 
+ cell to the preferred parent 
* Reset both NumCellsElapsed and NumCellsUsed to 0 and go to 
step 2. 
- To have the counters working, at least one unicast cell need to be 
+ To have the counters working, at least one unicast cell needs to be 
maintained all the time and never be removed. 
+TW> OK, so in all cases a node will have 2 cells to its preferred parent: one autonomous, one managed. 
- The reason why the counter only counts the managed unicast cell, NOT 
- including the autonomous SHARED cell is to avoid the effects of 
- collision. If the autonomous SHARED cell is counted as well, 
+ The reason why the counter only counts managed unicast cell (NOT 
+ autonomous SHARED cells) is to avoid the effect of 
+ collisions. If autonomous SHARED cell were counted as well, 
NumCellsUsed > LIM_NUMCELLSUSED_HIGH could be caused by the collision 
- on the cell. A 6P add request on the autonomous SHARED cell will 
+ on the cell. A 6P add request on the autonomous SHARED cell would 
make the collision even worse. 
Both NumCellsElapsed and NumCellsUsed counters can be used to cell 
+TW> something missing 
with cell option TX=1 or RX=1. With the rules defined above, the 
- cell to add or remove can be transmitting cell or receiving cell 
+ cell to add or remove can be a transmitting or receiving cell 
according to which type of cell the two counters are used for. 
+TW> don't understand. 
- Similar to Join Request and Response, the 6P Request is scheduled to 
- send on the autonomous SHARED cell to the node's parent. The 6P 
- Response is scheduled to send back on the autonomous non-SHARED cell 
+ Similar to Join Request and Response messages, 6P Request frames are 
+ sent on the autonomous SHARED cell to the node's parent. The 6P 
+ Response is sent back on the autonomous non-SHARED cell 
to the node. 
5.2. Switching Parent 
@@ -607,7 +621,7 @@ Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) March 2019 
A node implementing MSF SHOULD implement the behavior described in 
this section. 
- Part of its normal operation, the RPL routing protocol can have a 
+ As part of its normal operation, the RPL routing protocol can have a 
node switch preferred parents. The procedure for switching from the 
old preferred parent to the new preferred parent is: 
@@ -619,7 +633,7 @@ Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) March 2019 
1. if the new parent is not in the neighbor table, the autonomous 
- SHARED cell MUST be added as defined in Section 3 
+ SHARED cell MUST be added, as defined in Section 3 
2. the node counts the number of managed unicast cell cells it has 
per slotframe to the old preferred parent 
3. the node triggers one or more 6P ADD commands to schedule the 
@@ -636,6 +650,7 @@ Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) March 2019 
Since scheduling is entirely distributed, there is a non-zero 
probability that two pairs of nearby neighbor nodes schedule a 
managed unicast cell at the same [slotOffset,channelOffset] location 
+TW> why "managed unicast"? why not simply "managed"? 
in the TSCH schedule. In that case, data exchanged by the two pairs 
may collide on that cell. We call this case a "schedule collision". 
@@ -817,6 +832,7 @@ Internet-Draft 6TiSCH Minimal Scheduling Function (MSF) March 2019 
quarantine, drop all frames received from that node. 
waitretry: Abort the 6P Transaction. Wait for a duration randomly 
and uniformly chosen in [WAITDURATION_MIN,WAITDURATION_MAX]. 
+TW> these names are a bit obscure. Use WAITRETRYDURATION_MIN and WAITRETRYDURATION_MAX? 
Retry the same transaction. 
13. Schedule Inconsistency Handling 
@@ -1020,10 +1036,10 @@ Appendix B. Example of Implementation of SAX hash function 
o c, which is the characters of string s, to be hashed 
In MSF, the T is replaced by the length slotframe 1. String s is 
- replaced by the mote EUI64 address. The characters of the string c0, 
+ replaced by the mote's EUI64 address. The characters of the string c0, 
c1, ..., c7 are the 8 bytes of EUI64 address. 
- The SAX hash function requires shift operation which is defined as 
+ The SAX hash function requires a shift operation which is defined as 
follow: 
o L_shift(v,b), which refers to left shift variable v by b bits