Lotte,
Thank you for your comments. They are very helpful
to improve and to complete the draft before WGLC.
Do you have some preliminary results on the implementation
(or an open source implementation) to contribute to the WG?
Thank you.
Regards,
Diego Dujovne
2018-03-07 13:48 GMT-03:00 Lotte Steenbrink <lotte.steenbr...@fu-berlin.de>:
> 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 6*P* 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
>
>
--
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - Universidad Diego Portales - Chile
www.ingenieria.udp.cl
(56 2) 676 8125
_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
