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, Lotte > 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 > 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 > > > > > -- > DIEGO DUJOVNE > 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 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
