Re: [6tisch] draft-ietf-6tisch-6top-sfx-01 comments

[Lotte Steenbrink]

Hello Diego,

> Am 11.03.2018 um 13:45 schrieb Prof. Diego Dujovne 
> :
> 
> 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  >:
> Dear members of the 6TiSCH working group,
> 
> as with my draft-ietf-6tisch-6top-protocol-09 comments 
> , 
> 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 SCHEDULEDCELLS 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 fi

Re: [6tisch] draft-ietf-6tisch-6top-sfx-01 comments

[Prof. Diego Dujovne]

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 :

> Dear members of the 6TiSCH working group,
>
> as with my draft-ietf-6tisch-6top-protocol-09 comments
> ,
> 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 SCHEDULEDCELLS 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*
> *

[6tisch] draft-ietf-6tisch-6top-sfx-01 comments

[Lotte Steenbrink]

Dear members of the 6TiSCH working group,

as with my draft-ietf-6tisch-6top-protocol-09 comments 
, 
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___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch