Dear members of the 6TiSCH working group,

as with my draft-ietf-6tisch-6top-protocol-09 comments 
<https://mailarchive.ietf.org/arch/msg/6tisch/qs4mJI5I0hGcPLTPkVOj60mSjdc>, 
during the past weeks, I've attempted to implement SFX as part of my master's 
thesis. During this process, I've come across some parts of the Draft that 
seemed incomplete to me or where I was unsure if I interpreted them correctly. 
Even though the draft cut-off date for IETF101 has passed, I thought it might 
be helpful to share what the parts in question were before SFX goes into 
Working Group Last Call.
Again, I'm grateful for any feedback and any statement of mine suggesting a 
change comes with an implicit "I'd be happy to write/suggest text for that".

Allocation Policy Instructions
-------------------------------------------
Is there a reason the Allocation policy Instructions on Page 5/6 don't specify 
exact values? E.g. I would interpret 
"If REQUIREDCELLS<(SCHEDULEDCELLS-SF0THRESH), delete one or more cells" to mean 
"If REQUIREDCELLS<(SCHEDULEDCELLS-SF0THRESH), delete 
SCHEDULEDCELLS-REQUIREDCELLS cells" 
and "If SCHEDULEDCELLS<REQUIREDCELLS, add one or more cells" to mean "If 
SCHEDULEDCELLS<REQUIREDCELLS, add REQUIREDCELLS-SCHEDULEDCELLS cells".
is this correct?

NumCells and cellList size
--------------------------------------
As far as I understand it, 6P allows the originator of an ADD or RELOCATE 
request to offer more possible cells in the celList/candidateCellList than 
actually needed (as specified by numCells). As far as I can see, SFX does not 
appear to take advantage of this feature– is this deliberate or will this be 
added in the future?

Whitelisting Policies
------------------------------
I'm assuming that once a node sends an ADD request, it removes all timeOffsets 
proposed in the cellList from the Whitelist. When it receives a SUCCESS 
response, it then re-adds the timeOffsets of cells that weren't picked by the 
neighbor. The same applies to error responses (all suggested timeOffets are 
re-added). The same goes for DELETE and RELOCATE requests (but the other way 
round).
Is this correct? If so, I'd propose to explicitly state this in sections 14 and 
5.3. (or another section dedicated to sending request messages)

Additionally, I'm assuming the randomly picked channelOffset should be != 0. 
Would it make sense to mention this explicitly or is it too obvious?

(Similar questions probably apply to the blacklist case, but I haven't 
implemented that one.)

Deletion policy
---------------------
Section 6. only describes how to select cells for an ADD request, but not for a 
DELETE or RELOCATE request. 
Are cells for a DELETE request to be selected randomly from the cells scheduled 
between Node A and B?
Are cells for the candidateCellist of a RELOCATE request to be selected 
randomly from unused whitelisted cells, similar to the approach for ADD 
requests described in Section 6?

(Interpretation of the) Timeout value
---------------------------------------------------
Section 7. 6P Timeout Value says "There is no measurement unit associated to 
the timeout value.". However, the 6P draft also doesn't define a measurement 
unit. How do I know if my neighbour interprets the timeout I'm sending them as 
an offset or absolute time, milliseconds, seconds, incoming 6P transactions or 
what-have-you? Is there a recommended measurement unit for the timeout value?
Additionally, if 6P mandates that all SFs MUST specify a value for the 6P 
timeout, why is it up to the SF to put the timeout variable somewhere in their 
metadata field (as opposed to having a dedicated timeout octet in the 6P 
messages). I'm assuming this is to allow SFs to store timeouts in as many 
octets (or less) as they like, but imho it creates an odd dependency between 6P 
and the SF. I realize that 6P can't exist autonomously without a SF anyway, but 
in this case it mandates a value that doesn't exist in its own "default" 
messages. Personally, I'd assume there to be an 8-bit timeout field to the 
header of 6P REQUEST messages, which can then be extended in the metadata 
field, should a specific SF need more space than that.

Additionally, the 6P draft says that a Scheduling Function specification "MUST 
specify a value for the 6P Timeout, or a rule/equation to calculate it.". 
Personally, I don't feel that the current content of section 8 fulfills this 
requirement, and I don't feel equipped (yet) to pick a suitable timeout value 
on my own. More guidance from section 8 would be greatly appreciated.

Metadata information/SLOTFRAME
--------------------------------------------------
Section 8. Meaning of Metadata Information defines a [SLOTFRAME] entry in the 
Metadata field. However, this SLOTFRAME number is never used. I'm assuming it 
may be used to specify in which slotframe the suggested cells in cellList are 
located, as noted in the 6P draft: "For example, Metadata can specify in which 
slotframe to add the cells." (this would also mean that requests have to be 
split up by slotframe, not just by link option), or to keep track of when a 
transaction can be retriggered (as noted on Page 7, "If the transaction is not 
successful, SFX will be retriggered on the next slotframe if the number of used 
cells changes.")
Will wording on how to use this information be added in the future?

ADD Requests on node init
---------------------------------------
Since Section 9. Node Behavior At Boot says "at least a SFXTHRESH number of 
cells MUST be allocated to each of the neighbours.", I'm assuming the node is 
expected to send ADD requests for SFXTHRESH cells to all of its neighbors at 
boot (or when joining the network).
What happens if many nodes boot at the same time and consequently have to 
answer a lot of ADD requests in parallel? Should they make sure they don't 
propose the same cell (or cells with the same slotOffset) to different 
neighbors to prevent conflicts? If so, I think it would be helpful to specify 
all of this explicitly.

Section 14 naming
----------------------------
Would it make sense to rename "14. 6P Error Handling" to "15. 6P Response 
Handling", since it also discusses RC_SUCCESS messages, which aren't error 
messages (as the current title may suggest)?

Handling Inconsistencies
-------------------------------------
6P mandates that "The specification for an SF [...] MUST specify how to handle 
a schedule inconsistency". However, SFX does not (yet, I assume) specify how to 
handle inconsistencies. Is there any timeframe in which this will be added, or 
a rough sketch of how SFX would handle an inconsistency?

Minor nitpicks
--------------------
Section 5.3. has the sentences "The number of cells to be added/deleted is out 
of the scope of this document and it is implementation dependent." as well as 
"The number of cells to add or delete is implementation-specific.". To me, 
these sentences seem to say the same thing– would it make sense to delete the 
second sentence?

Section 6 says "When issuing a 6top ADD Request [...]", shouldn't it say "When 
issuing a 6P ADD Request [...]"?

Section 7 says "The timeout MUST be added as an 7-bit on the Metadata header to 
the neighbour.", but the metadata sections is only explained one section later, 
which caused some initial confusion for me. I think it might improve the 
reading flow if the draft said  "The timeout MUST be added as an 7-bit on the 
Metadata header to the neighbor, as detailed in section 9."
Section 7 also says "If the timeout expires, the node issues a RESET return 
code will be issued to the neighbour". I believe this is a typo; the sentence 
should say "If the timeout expires, the node issues a RESET return code to the 
neighbour" instead.

Section 14 says multiple times: "The node MAY retry to contact this neighbor 
later." How soon is later? Does it make sense to specify how long "later" is, 
or provide some guidance on how to pick a suitable "later" (maybe in relation 
to the 6P timeout value)?



Overall, I think that the Draft does a great job at explaining what SFX is all 
about– it's easy to grasp SFX's unique characteristics such as the 
overprovisioning mechanism and PDR-based cell relocation. It is easy to read 
and written in clear language.
However, from an implementation perspective, I've found that it lacks 
specificness (?) and structure in places– I'm missing the boring "if X happens, 
check Y and Z and then do Foo" parts. 


With best regards,
Lotte Steenbrink

_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Reply via email to