Re: [6tisch] draft-ietf-6tisch-6top-protocol-09 comments
That is perfect, thanks for confirming. On Thu, Mar 22, 2018 at 11:26 AM, Xavi Vilajosana Guillen < xvilajos...@uoc.edu> wrote: > Dear Thomas, all, > > I will provide an answer today and modify the draft accordingly in the > following hours. V11 will be published by next week. > > regards > Xavi > > > > 2018-03-22 11:31 GMT+01:00 Thomas Watteyne : > >> Lotte, >> Thanks for the detailed comment, and for the discussions around the >> 6TiSCH WG meeting yesterday. >> >> Xavi, >> Per the meeting yesterday, I believe it's important these points make it >> into the draft, but I don't see any point which is extremely complicated to >> answer. Can you let the WG know about the timeline for you to address them? >> >> Thomas >> >> On Wed, Mar 7, 2018 at 5:47 PM, Lotte Steenbrink < >> lotte.steenbr...@fu-berlin.de> wrote: >> >>> Hello Xavi, >>> thank you for your comments! Answers inline. I also found another >>> question in my notes, I hope you don't mind me wedging it into this thread: >>> >>> If I understand it correctly, in a 2-Way transaction of a Relocate/Add >>> Request, Node A should only start using the newly negotiated cells after it >>> has sent its LL ACK of Node B's response, and Node B should only start >>> using the newly negotiated cells after it has received said LL ACK. >>> In ASCII Art: >>> >>> Node A Node B >>> | | >>> | - Relocate Req -> | >>> | | >>> | < * * LL ACK * * | >>> | | >>> | | >>> | <- Relocate Rsp - | >>> | | >>> | * * LL ACK * * > | >>> | | >>> start using | | start using >>> new cells | | new cells >>> >>> Otherwise, (assuming the worst case: all cells on the A--B link have >>> been rescheduled), one Node will send their response on the new cells, >>> while the other will still be listening in the old cells. Even if the worst >>> case doesn't apply and Node A and B still share some "old" cells or are >>> able to communicate during fixed shared cells, this might still introduce >>> costly retransmissions and delays. >>> >>> Did I understand this correctly? If so, is this mentioned in the draft >>> somewhere and I just didn't see it? If not, would it make sense to state >>> this explicitly? (I only stumbled across this after I tested things with >>> said worst case described above). >>> >>> Am 02.03.2018 um 17:15 schrieb Xavi Vilajosana Guillen < >>> xvilajos...@uoc.edu>: >>> >>> Dear Lotte, >>> >>> thanks so much for your detailed review, as implementer, this is really >>> useful! >>> >>> See inline our responses ( XV: ). The proposed corrections will be >>> incorporated in the next version of the draft that will be published asap >>> (before cut-off date). >>> >>> kind regards, >>> Xavi >>> >>> Dear 6TiSCH Working Group, >>> >>> somehow I missed the WGLC announcement for the 6top protocol draft. I'm >>> not quite sure if I'm too late with my review/questions now, but in case >>> I'm not, I'd like to share what I've got so far. >>> >>> As for the context of my E-Mail: I'm currently implementing the 6top >>> Protocol as part of my master's thesis. It's not a full implementation, >>> just the parts that I currently need: 3-Step transactions are missing and >>> DELETE Requests are still Work In Progress, for example. I'm new-ish to the >>> ideas of 6TiSCH and TSCH in general, so my comments come from an outsiders' >>> point of view. >>> >>> While implementing 6P, I've stumbled across some parts of the document >>> where I'm not quite sure if there's an inconsistency or if I'm just missing >>> something. In any case, I think it might be helpful to clear these parts up >>> (in the draft or on the WG Mailing List) before publishing 6P as Proposed >>> Standard. (Any feedback to my questions would be greatly appreciated, and >>> all statements proposing a change come with an implicit "I'd be happy to >>> write/suggest text for that", of course.) >>> >>> Overall, I've found the draft to be nicely written and easy to read, but >>> lacking clear instructions in places. The idea of how 6P works is quick to >>> grasp, also thanks to the illustrations in Fig. 4 and 5. However, when it >>> comes to implementing the protocol, I've found myself skipping all over the >>> document to gather information on what's what. Especially the message >>> format and handling feels incomplete; not all message types are illustrated >>> or documented in full and one often has to infer what to check and send >>> when. >>> In the following, I will detail what exactly was unclear to me. >>> >>> 6P ADD Response where NumCells == 0 >>> - >>> Section 3.3.1. says: >>> >>> "[...] The returned list can contain NumCells elements (succeeded) or >>> between 0
Re: [6tisch] draft-ietf-6tisch-6top-protocol-09 comments
Dear Thomas, all, I will provide an answer today and modify the draft accordingly in the following hours. V11 will be published by next week. regards Xavi 2018-03-22 11:31 GMT+01:00 Thomas Watteyne : > Lotte, > Thanks for the detailed comment, and for the discussions around the 6TiSCH > WG meeting yesterday. > > Xavi, > Per the meeting yesterday, I believe it's important these points make it > into the draft, but I don't see any point which is extremely complicated to > answer. Can you let the WG know about the timeline for you to address them? > > Thomas > > On Wed, Mar 7, 2018 at 5:47 PM, Lotte Steenbrink < > lotte.steenbr...@fu-berlin.de> wrote: > >> Hello Xavi, >> thank you for your comments! Answers inline. I also found another >> question in my notes, I hope you don't mind me wedging it into this thread: >> >> If I understand it correctly, in a 2-Way transaction of a Relocate/Add >> Request, Node A should only start using the newly negotiated cells after it >> has sent its LL ACK of Node B's response, and Node B should only start >> using the newly negotiated cells after it has received said LL ACK. >> In ASCII Art: >> >> Node A Node B >> | | >> | - Relocate Req -> | >> | | >> | < * * LL ACK * * | >> | | >> | | >> | <- Relocate Rsp - | >> | | >> | * * LL ACK * * > | >> | | >> start using | | start using >> new cells | | new cells >> >> Otherwise, (assuming the worst case: all cells on the A--B link have been >> rescheduled), one Node will send their response on the new cells, while the >> other will still be listening in the old cells. Even if the worst case >> doesn't apply and Node A and B still share some "old" cells or are able to >> communicate during fixed shared cells, this might still introduce costly >> retransmissions and delays. >> >> Did I understand this correctly? If so, is this mentioned in the draft >> somewhere and I just didn't see it? If not, would it make sense to state >> this explicitly? (I only stumbled across this after I tested things with >> said worst case described above). >> >> Am 02.03.2018 um 17:15 schrieb Xavi Vilajosana Guillen < >> xvilajos...@uoc.edu>: >> >> Dear Lotte, >> >> thanks so much for your detailed review, as implementer, this is really >> useful! >> >> See inline our responses ( XV: ). The proposed corrections will be >> incorporated in the next version of the draft that will be published asap >> (before cut-off date). >> >> kind regards, >> Xavi >> >> Dear 6TiSCH Working Group, >> >> somehow I missed the WGLC announcement for the 6top protocol draft. I'm >> not quite sure if I'm too late with my review/questions now, but in case >> I'm not, I'd like to share what I've got so far. >> >> As for the context of my E-Mail: I'm currently implementing the 6top >> Protocol as part of my master's thesis. It's not a full implementation, >> just the parts that I currently need: 3-Step transactions are missing and >> DELETE Requests are still Work In Progress, for example. I'm new-ish to the >> ideas of 6TiSCH and TSCH in general, so my comments come from an outsiders' >> point of view. >> >> While implementing 6P, I've stumbled across some parts of the document >> where I'm not quite sure if there's an inconsistency or if I'm just missing >> something. In any case, I think it might be helpful to clear these parts up >> (in the draft or on the WG Mailing List) before publishing 6P as Proposed >> Standard. (Any feedback to my questions would be greatly appreciated, and >> all statements proposing a change come with an implicit "I'd be happy to >> write/suggest text for that", of course.) >> >> Overall, I've found the draft to be nicely written and easy to read, but >> lacking clear instructions in places. The idea of how 6P works is quick to >> grasp, also thanks to the illustrations in Fig. 4 and 5. However, when it >> comes to implementing the protocol, I've found myself skipping all over the >> document to gather information on what's what. Especially the message >> format and handling feels incomplete; not all message types are illustrated >> or documented in full and one often has to infer what to check and send >> when. >> In the following, I will detail what exactly was unclear to me. >> >> 6P ADD Response where NumCells == 0 >> - >> Section 3.3.1. says: >> >> "[...] The returned list can contain NumCells elements (succeeded) or >> between 0 and NumCells elements (partially succeeded). >> In the case that none of the cells could be allocated node B MUST send a >> 6P Response with return code set to NOALLOC, >> indicating that cells could not be allocated in the schedule, for example >> b
Re: [6tisch] draft-ietf-6tisch-6top-protocol-09 comments
Lotte, Thanks for the detailed comment, and for the discussions around the 6TiSCH WG meeting yesterday. Xavi, Per the meeting yesterday, I believe it's important these points make it into the draft, but I don't see any point which is extremely complicated to answer. Can you let the WG know about the timeline for you to address them? Thomas On Wed, Mar 7, 2018 at 5:47 PM, Lotte Steenbrink < lotte.steenbr...@fu-berlin.de> wrote: > Hello Xavi, > thank you for your comments! Answers inline. I also found another question > in my notes, I hope you don't mind me wedging it into this thread: > > If I understand it correctly, in a 2-Way transaction of a Relocate/Add > Request, Node A should only start using the newly negotiated cells after it > has sent its LL ACK of Node B's response, and Node B should only start > using the newly negotiated cells after it has received said LL ACK. > In ASCII Art: > > Node A Node B > | | > | - Relocate Req -> | > | | > | < * * LL ACK * * | > | | > | | > | <- Relocate Rsp - | > | | > | * * LL ACK * * > | > | | > start using | | start using > new cells | | new cells > > Otherwise, (assuming the worst case: all cells on the A--B link have been > rescheduled), one Node will send their response on the new cells, while the > other will still be listening in the old cells. Even if the worst case > doesn't apply and Node A and B still share some "old" cells or are able to > communicate during fixed shared cells, this might still introduce costly > retransmissions and delays. > > Did I understand this correctly? If so, is this mentioned in the draft > somewhere and I just didn't see it? If not, would it make sense to state > this explicitly? (I only stumbled across this after I tested things with > said worst case described above). > > Am 02.03.2018 um 17:15 schrieb Xavi Vilajosana Guillen < > xvilajos...@uoc.edu>: > > Dear Lotte, > > thanks so much for your detailed review, as implementer, this is really > useful! > > See inline our responses ( XV: ). The proposed corrections will be > incorporated in the next version of the draft that will be published asap > (before cut-off date). > > kind regards, > Xavi > > Dear 6TiSCH Working Group, > > somehow I missed the WGLC announcement for the 6top protocol draft. I'm > not quite sure if I'm too late with my review/questions now, but in case > I'm not, I'd like to share what I've got so far. > > As for the context of my E-Mail: I'm currently implementing the 6top > Protocol as part of my master's thesis. It's not a full implementation, > just the parts that I currently need: 3-Step transactions are missing and > DELETE Requests are still Work In Progress, for example. I'm new-ish to the > ideas of 6TiSCH and TSCH in general, so my comments come from an outsiders' > point of view. > > While implementing 6P, I've stumbled across some parts of the document > where I'm not quite sure if there's an inconsistency or if I'm just missing > something. In any case, I think it might be helpful to clear these parts up > (in the draft or on the WG Mailing List) before publishing 6P as Proposed > Standard. (Any feedback to my questions would be greatly appreciated, and > all statements proposing a change come with an implicit "I'd be happy to > write/suggest text for that", of course.) > > Overall, I've found the draft to be nicely written and easy to read, but > lacking clear instructions in places. The idea of how 6P works is quick to > grasp, also thanks to the illustrations in Fig. 4 and 5. However, when it > comes to implementing the protocol, I've found myself skipping all over the > document to gather information on what's what. Especially the message > format and handling feels incomplete; not all message types are illustrated > or documented in full and one often has to infer what to check and send > when. > In the following, I will detail what exactly was unclear to me. > > 6P ADD Response where NumCells == 0 > - > Section 3.3.1. says: > > "[...] The returned list can contain NumCells elements (succeeded) or > between 0 and NumCells elements (partially succeeded). > In the case that none of the cells could be allocated node B MUST send a > 6P Response with return code set to NOALLOC, > indicating that cells could not be allocated in the schedule, for example > because they are already used or reserved. > The returned list in this case MUST contain 0 elements." > > If the returned list contains 0 elements, it satisfies both the > requirements to send a SUCCESS as well as a NOALLOC response. Should I send > a) both a SUCCESS as well as a NOALLOC response > b) a NOALLOC response >
Re: [6tisch] draft-ietf-6tisch-6top-protocol-09 comments
Hello Xavi, thank you for your comments! Answers inline. I also found another question in my notes, I hope you don't mind me wedging it into this thread: If I understand it correctly, in a 2-Way transaction of a Relocate/Add Request, Node A should only start using the newly negotiated cells after it has sent its LL ACK of Node B's response, and Node B should only start using the newly negotiated cells after it has received said LL ACK. In ASCII Art: Node A Node B | | | - Relocate Req -> | | | | < * * LL ACK * * | | | | | | <- Relocate Rsp - | | | | * * LL ACK * * > | | | start using | | start using new cells | | new cells Otherwise, (assuming the worst case: all cells on the A--B link have been rescheduled), one Node will send their response on the new cells, while the other will still be listening in the old cells. Even if the worst case doesn't apply and Node A and B still share some "old" cells or are able to communicate during fixed shared cells, this might still introduce costly retransmissions and delays. Did I understand this correctly? If so, is this mentioned in the draft somewhere and I just didn't see it? If not, would it make sense to state this explicitly? (I only stumbled across this after I tested things with said worst case described above). > Am 02.03.2018 um 17:15 schrieb Xavi Vilajosana Guillen : > > Dear Lotte, > > thanks so much for your detailed review, as implementer, this is really > useful! > > See inline our responses ( XV: ). The proposed corrections will be > incorporated in the next version of the draft that will be published asap > (before cut-off date). > > kind regards, > Xavi > > Dear 6TiSCH Working Group, > > somehow I missed the WGLC announcement for the 6top protocol draft. I'm not > quite sure if I'm too late with my review/questions now, but in case I'm not, > I'd like to share what I've got so far. > > As for the context of my E-Mail: I'm currently implementing the 6top Protocol > as part of my master's thesis. It's not a full implementation, just the parts > that I currently need: 3-Step transactions are missing and DELETE Requests > are still Work In Progress, for example. I'm new-ish to the ideas of 6TiSCH > and TSCH in general, so my comments come from an outsiders' point of view. > > While implementing 6P, I've stumbled across some parts of the document where > I'm not quite sure if there's an inconsistency or if I'm just missing > something. In any case, I think it might be helpful to clear these parts up > (in the draft or on the WG Mailing List) before publishing 6P as Proposed > Standard. (Any feedback to my questions would be greatly appreciated, and all > statements proposing a change come with an implicit "I'd be happy to > write/suggest text for that", of course.) > > Overall, I've found the draft to be nicely written and easy to read, but > lacking clear instructions in places. The idea of how 6P works is quick to > grasp, also thanks to the illustrations in Fig. 4 and 5. However, when it > comes to implementing the protocol, I've found myself skipping all over the > document to gather information on what's what. Especially the message format > and handling feels incomplete; not all message types are illustrated or > documented in full and one often has to infer what to check and send when. > In the following, I will detail what exactly was unclear to me. > > 6P ADD Response where NumCells == 0 > - > Section 3.3.1. says: > > "[...] The returned list can contain NumCells elements (succeeded) or between > 0 and NumCells elements (partially succeeded). > In the case that none of the cells could be allocated node B MUST send a 6P > Response with return code set to NOALLOC, > indicating that cells could not be allocated in the schedule, for example > because they are already used or reserved. > The returned list in this case MUST contain 0 elements." > > If the returned list contains 0 elements, it satisfies both the requirements > to send a SUCCESS as well as a NOALLOC response. Should I send > a) both a SUCCESS as well as a NOALLOC response > b) a NOALLOC response > c) a SUCCESS response > in this case? > > I'd assume the answer is b), but since the wording around partially succeeded > allocations is explicitly mentioning 0 cells as an options, that assumption > may very well be wrong. Depending on what the correct answer is, I'd propose > to state it more explicitly in the draft. > > XV: This is clarified in the current text now. The only possible response is > RC_SUCCESS. The size of the list determines whether there is a fu
Re: [6tisch] draft-ietf-6tisch-6top-protocol-09 comments
Dear Lotte, thanks so much for your detailed review, as implementer, this is really useful! See inline our responses ( XV: ). The proposed corrections will be incorporated in the next version of the draft that will be published asap (before cut-off date). kind regards, Xavi Dear 6TiSCH Working Group, somehow I missed the WGLC announcement for the 6top protocol draft. I'm not quite sure if I'm too late with my review/questions now, but in case I'm not, I'd like to share what I've got so far. As for the context of my E-Mail: I'm currently implementing the 6top Protocol as part of my master's thesis. It's not a full implementation, just the parts that I currently need: 3-Step transactions are missing and DELETE Requests are still Work In Progress, for example. I'm new-ish to the ideas of 6TiSCH and TSCH in general, so my comments come from an outsiders' point of view. While implementing 6P, I've stumbled across some parts of the document where I'm not quite sure if there's an inconsistency or if I'm just missing something. In any case, I think it might be helpful to clear these parts up (in the draft or on the WG Mailing List) before publishing 6P as Proposed Standard. (Any feedback to my questions would be greatly appreciated, and all statements proposing a change come with an implicit "I'd be happy to write/suggest text for that", of course.) Overall, I've found the draft to be nicely written and easy to read, but lacking clear instructions in places. The idea of how 6P works is quick to grasp, also thanks to the illustrations in Fig. 4 and 5. However, when it comes to implementing the protocol, I've found myself skipping all over the document to gather information on what's what. Especially the message format and handling feels incomplete; not all message types are illustrated or documented in full and one often has to infer what to check and send when. In the following, I will detail what exactly was unclear to me. 6P ADD Response where NumCells == 0 - Section 3.3.1. says: "[...] The returned list can contain NumCells elements (succeeded) or between 0 and NumCells elements (partially succeeded). In the case that none of the cells could be allocated node B MUST send a 6P Response with return code set to NOALLOC, indicating that cells could not be allocated in the schedule, for example because they are already used or reserved. The returned list in this case MUST contain 0 elements." If the returned list contains 0 elements, it satisfies both the requirements to send a SUCCESS as well as a NOALLOC response. Should I send a) both a SUCCESS as well as a NOALLOC response b) a NOALLOC response c) a SUCCESS response in this case? I'd assume the answer is b), but since the wording around partially succeeded allocations is explicitly mentioning 0 cells as an options, that assumption may very well be wrong. Depending on what the correct answer is, I'd propose to state it more explicitly in the draft. XV: This is clarified in the current text now. The only possible response is RC_SUCCESS. The size of the list determines whether there is a full, partial or none allocation. Also, NOALLOC doesn't appear in Figure 36: 6P Return Codes, is this on purpose? XV: this RC has been removed. Is not used anymore. Response Format Specification and Illustrations - I would've found it very helpful to have Figures & subsections describing the format of SUCCESS, RESET and NOALLOC responses (and how to handle them) just like the requests are illustrated in fig. 9, 11, 13 (and 14). As an example, I would've assumed that the NOALLOC response looks like this: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| T | R | Code | SFID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (since the cellList is always empty anyways, there's no need to explicitly transmit it), but the text says "The returned list in this case MUST contain 0 elements", and while the text says that a message with code RC_RESET marks a "critical error, reset"– what exactly should be reset? The transaction state? How is it any different to a NOALLOC message then? Or are NOALLOC and RESET messages the same thing by a different name and NOALLOC is just a leftover from previous renamings? XV: The response format is detailed in Figure 13. In case of a 0 length CellList, the element is not present in the frame. The response CODE is RC_SUCCESS as described in the current text. The size of the list tells us how many of the cells have been actually allocated. The RC_RESET return code is returned upon a critical error, such an inconsistency that cannot be resolved. In this case the transaction is aborted and the cells scheduled between the peer nodes in the transactions is cleared. (all cells schedueld between them cleared). -
