Hello Diego,

> Am 11.03.2018 um 13:45 schrieb Prof. Diego Dujovne 
> <diego.dujo...@mail.udp.cl>:
> 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?

We're planning to open source it, but it is not camera ready yet. If you'd like 
to have a look beforehand, I can send you a snapshot or we could have a short 
chat in London. Since the SFX and 6P implementations were just preliminary work 
for the actual thesis contribution, I don't expect to have any results to share 
before April.

Best regards,

> Thank you.
> Regards,
>                           Diego Dujovne
> 2018-03-07 13:48 GMT-03:00 Lotte Steenbrink <lotte.steenbr...@fu-berlin.de 
> <mailto: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 
> and "If SCHEDULEDCELLS<REQUIREDCELLS, add one or more cells" to mean "If 
> 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
> -- 
> Profesor Asociado
> Escuela de Informática y Telecomunicaciones
> Facultad de Ingeniería - Universidad Diego Portales - Chile
> www.ingenieria.udp.cl <http://www.ingenieria.udp.cl/>
> (56 2) 676 8125
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org <mailto:6tisch@ietf.org>
> https://www.ietf.org/mailman/listinfo/6tisch 
> <https://www.ietf.org/mailman/listinfo/6tisch>
6tisch mailing list

Reply via email to