[6tsch] comments unpublished draft-vilajosana-6tisch-minimal-00.txt

[Thomas Watteyne <[e-mail]>]

Xavi, Kris,

Per the last 6TiSCH webex on Friday, I reviewed the unpublished version
of draft-vilajosana-6tisch-minimal-00, in particular the file
https://bitbucket.org/6tsch/draft-vilajosana-6tsch-basic/src/3ead236bdc563747fea826e8d632fd99f3bb868e/draft-vilajosana-6tisch-minimal-00.txt?at=master.
You will find the remarks below.

Thomas

----

Remarks:

   1. In the abstract, you might consider indicating that the minimal
   configuration can be used for more than interop testing. Example rewording:
   "This minimal mode of operation can be used during network bootstrap, as a
   fallback mode of operation when no dynamic scheduling solution is available
   or functioning, or during early interoperability testing and development".
   2. Similarly, I would highlight these cases also in the introduction,
   maybe providing one sentence per case. A reference
   to draft-ietf-roll-rpl-industrial-applicability might be appropriate at
   that point.
   3. "[IEEE802154e] provides a mechanism whereby the details of slotframe
   length, timeslot timing, and channel hopping pattern are communicated to a
   node during initial synchronization". I believe the EB can also indicate
   the cells to use.
   4. "the radio of the nodes remains off." You might want to indicate that
   those 95 timeslots are available for a dynamic scheduling solution.
   5. in the "Minimal schedule overview" figure, why "TxRxS" and not simply
   "TxRx"?
   6. "All scheduled cells in the minimal schedule are configured as Hard
   cells [I-D.watteyne-6tsch-tsch-lln-context][I-D.draft-wang-6tsch-6top]
   since reallocation is not considered in that simple approach." That's not
   strictly true if we consider a dynamic scheduling approach can schedule the
   remaining 95 slots. Maybe specify that the cell allocated by this document
   are hard cells, but that this does not necessarily apply to any additional
   cells scheduled by a dynamic scheduling solution.
   7. Unscheduled cells should not occupy any memory -> Unscheduled cells
   SHOULD NOT occupy any memory
   8. the transmissions is considered failed at the MAC layer, and the
   upper layer needs to be notified -> the transmissions is considered failed
   and the MAC layer MUST notify the upper layer
   9. 2.4.  Time Slot timing is redundant
   with draft-watteyne-6tsch-tsch-lln-context. We could consider moving the
   diagram and text to that draft, and leave just the table in this draft,
   together with a reference to the draft-watteyne-6tsch-tsch-lln-context.
   Thoughts welcome.
   10. "this document recommends to hard-code the different durations to
   the values listed below." This it not strictly true, since the intro says
   that one can dynamically learn through the EB. Please say the same in this
   text.
   11. it is recommended to sent EBs at least once every 10s -> a mote
   SHOULD send an EB every 10s
   12. EBs must be sent with the Beacon IEEE802.15.4 frame type -> EBs MUST
   be sent with the Beacon IEEE802.15.4 frame type
   13. "this document recommends that they carry the following Information
   Elements (IEs)". Since nodes can either hard-code or learn on the fly, I
   believe the list of IEs is a MUST.
   14. Section 3 contains the value of all fields. Please specify that this
   is redundant with [IEEE802.15.4e] and [I-D.watteyne-6tsch-tsch-lln-contex],
   and provided here for clarity.
   15. In 3.1.2., what's the value of Join Priority?
   16. "each node SHOULD indicate the schedule in each EB through a Frame
   and Cell IE". Per discussion above, maybe MUST?
   17. please give each neighbor statistics a name, e.g. numTx
   18. "Neighbour address". Which address? EUI, IPv6, both?
   19. Per last call use timestamp rather than ASN in "Timestamp when that
   neighbour was heard for the last time. This can be based on the ASN counter
   or any other time base."
   20. "Connectivity statistics (RSSI, LQI, etc),". I would simply RSSI,
   since LQI is not well defined.
   21. "Each node selects at least one time parent amongst its known
   neighbours." I suggest "Each node MUST select a time source neighbor among
   the neighbors in its RPL routing parent set"
   22. PAN coordinator is an old term. Let's use the term DAG root.
   23. "it is NOT allowed" -> "is MUST NOT" (NOT cannot be used alone)
   24. "start advertising the network" -> "send EBs"
   25. I would remove "e.g RSSI when the EB has been received as no other
   metrics are available at that moment"
   26. Strictly speaking, "time parent" does not exist. Please use the term
   "time source neighbor"
   27. "A backup time parent can also be selected (as required by RPL and
   described in Section 7.1 following the same rule)." It is unclear how that
   backup is used. What you could say is that, if connectivity to the time
   source neighbor is lost, a new time source neighbor MUST be chosen among
   the neighbor in the RPL routing parent set.
   28. I understand "Optionally, a node [...] selected" is about
   hysteresis. As is, it is not clear what exactly is defined. I would simply
   state that "some form of hysteresis SHOULD be implemented to avoid frequent
   changes in time source neighbors"
   29. "Lower-layer packets " -> "Frames generated by the MAC layer (e.g.
   EBs and ACK)"
   30. "A minimal TSCH configuration [...] tests" is WAY to verbose. Please
   reword by something as simple as "Nodes in the network MUST use the RPL
   routing protocol".
   31. Same thing for the long intro to Section 7.1.
   32. In 7.1.1, I would not repeat RFC6552, just state that a mote MUST
   use step_of_rank as 2*ETX
   33. "This information can be extracted from the neighbours information
   described in Section 5.1." Please replace by equation based on counters.
   34. I would keep 7.1.2, which helps clarify.
   35. Same for 7.2.2, please remove repeats, and list simply the
   configuration.
   36. If possible, please federate the discussion about hysteresis for
   both the routing and time source selection, since it's one and the same
   thing.
   37. What's the recommended value for PARENT_SWITCH_THRESHOLD?

Minor remarks (*a* means add, **a** means remove, please use Ctrl+F to
find):

   1. Number of time slots per **Slotframe** *slotframe*
   2. Amendament->Amendment
   3. Number of EB**s** cells
   4. These EBs *sent to the broadcast MAC address and* are not acknowledged
   5. Per the [IEEE802154e] **TSCH** standard
   6. options below that -> options below, which
   7. set,* *in
   8. in presence of collisions it uses the back-off mechanism defined in
   [IEEE802154e] -> the back-off mechanism defined in [IEEE802154e] is used to
   resolve contention
   9. node (RX), and a MAC -> node (RX). A MAC
   10. fully to **be able to** configure
   11. Size Slotframe (b32-b47) = 0x65 *(101)*
   12. "Slot Number (2B) = from (0x00 to 0x05)" why the parenthesis?
   13. Time Synch*ronization* information
   14. "but it should at least contain the following information, for each
   neighbour" -> "it SHOULD contain the following information for each
   neighbor"
   15. RPL objective function (OF) -> RPL Objective Function (OF)
   16. "parent, uses the Join Priority" -> parent, it uses the Join Priority
   17. of **the** [IEEE802154e]
   18. i.e*.* EBs sent
   19.  When a nodes Joins -> When a node joins
   20. " The later aims to avoid" -> "The latter avoids"
   21. match*es* RPL topology
   22. it is allowed to send Enhanced Beacons -> it SHOULD send Enhanced
   Beacons
   23. In case of a node receiving EBs -> In case a node receives EBs
   24. a*n* IEEE802.15.4
   25. Watteyene -> Watteyne

administrative remark:

   1. the repository is now called draft-vilajosana-6tsch-basic. Please
   rename to draft-vilajosana-6tisch-minimal. You might want to give people
   48h notice in case they have it cloned.
   2. please use the bitbucket issue tracker built into your repository to
   track these remarks.

Remarks about the XML file:

   1. While I reviewed the TXT version, I took the liberty to look at the
   XML file.
   2. For homogeneity with the other 6TiSCH drafts, please replace tabs by
   3 spaces, especially in figures. This should also fix indentation issues.
   3. The draft-wang-6tsch-6top is published. Please replace the explicit
   reference to "I-D.draft-wang-6tsch-6top" accordingly. This will also ensure
   the correct I-D version.