That is perfect, thanks for confirming. On Thu, Mar 22, 2018 at 11:26 AM, Xavi Vilajosana Guillen < [email protected]> 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 <[email protected]>: > >> 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 < >> [email protected]> 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 < >>> [email protected]>: >>> >>> 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. >>> >>> >>> LS: Great, thank you! >>> >>> >>> 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). >>> >>> >>> LS: Ah, I think now I get it. Thank you. >>> >>> >>> ----- >>> On a side note, fig. 14 is missing the descriptions for the T and Code >>> fields (i.e. to which values they should be set) that the other figures >>> have, and while it's possible to infer these values from the draft, I >>> personally think it'd be handy to have them near the figure as well. :) >>> >>> XV: the description is detailed right before the figure. >>> >>> The Type field (T) is set to REQUEST.. >>> The Code field is set to ADD. >>> >>> >>> LS: It is in the new Figure 14, which is the old Figure 13 (i.e. >>> "RELOCATE Request Format"). It isn't in the new Figure 15, which is the old >>> figure 14 (i.e. RELOCATE Response and Confirmation Formats)– or any of the >>> response format sketches, as far as I can see it. But I suppose since >>> they're pretty close to each other, one could assume that the reader still >>> has that pierce of information memorized. >>> >>> >>> Erroneous CellOptions in ADD request >>> ------------------------------------------------------- >>> What happens if a node receives an ADD request where more than one link >>> type (RX, TX or SHARED) is set in the cellOptions field? I'd assume it >>> would send an error response, but of which type? RC_CELLLIST? >>> >>> XV: A table indicating the meaning of the celloptions for >>> ADD/DELETE/RELOCATE request has been added. >>> Basically the installed cells from the cell list are of the type >>> specified by the CellOptions. There are some celloptions that have no >>> meaning and RC_ERR is returned in that case. >>> >>> >>> LS: Great, that makes it easier to understand, thank you.. I think it >>> would be helpful to add an additional hint to this information to section >>> 3.3.1, for example by extending the 3rd paragraph after Figure 11 to: >>> >>> "Upon receiving the request, node B checks whether the cellOptions are >>> set to a legal value as noted by Figure 8. If this is not the case, a >>> Response with code RC_ERR is returned. Otherwise, node B's SF verifies >>> which of the cells [...]" >>> >>> >>> Handling CandidateCellList.size() < numCells in Relocate responses >>> ------------------------------------------------------------ >>> ------------------------------- >>> Section 3.3.3 states that in a 6P RELOCATE request, " NumCandidate MUST >>> be larger or equal to NumCells", but doesn't specify how Node B should >>> react if it receives a Relocate request that violates this requirement.. >>> Does it respond with an RC_CELLLIST error message? >>> If so, I'd propose to change the first sentences of the paragraph >>> starting with "Upon receiving the request" to something along the lines of: >>> >>> "Upon receiving the request, Node B checks if the length of >>> candidateCellList is be larger or equal to NumCells. Node B's SF verifies >>> that all the cells in the Relocation CellList are indeed scheduled with >>> node A and are of the link type specified in the CellOptions field. If any >>> of these checks fail, node B MUST send a 6P Response to node A with return >>> code RC_CELLLIST. [...]" >>> >>> XV: good point. We added that check. >>> >>> 6P CLEAR Response format >>> ---------------------------------------- >>> 1. If the value of SeqNum doesn't matter for CLEAR messages, why do they >>> have a SeqNum field nonetheless? >>> 2. Section 3.2.2 says "The Code field contains a 6P Return Code when the >>> 6P message is of Type RESPONSE or CONFIRMATION." However, the 6P Return >>> Codes >>> listed in Section 6.2.4. don't list an RC_CLEAR code. Should an RC_CLEAR >>> code be added to section 6.2.4. or should CLEAR response messages in >>> fact have CMD_CLEAR set in their code field? (For the record, the former >>> seems more intuitive to me personally) >>> Or am I misunderstanding something entirely? >>> >>> XV: the seqnum matters for all messages. CLEAR is the only command that >>> is not checking it as a clear can be issued after an inconsistency is >>> detected. >>> CLEAR is a command. Not a Response code. Clear is issued as a separate >>> action after some inconsistency is detected for example. >>> We added a clarification for the CLEAR Request on what are the possible >>> return codes. >>> " The Response Code to a 6P CLEAR command SHOULD be RC_SUCCESS unless >>> the operation cannot be executed. >>> When the CLEAR operation cannot be executed the Response Code MUST be >>> set to RC_RESET." >>> >>> >>> LS: Of course! I'm not quite sure what I was thinking, but I think the >>> extra text makes things extra clear. Thank you. :) >>> >>> >>> Handling RC_CELLLIST Response messages >>> ---------------------------------------------------------------- >>> The Draft states that a faulty RELOCATE message should be responded to >>> with a 6P response with RC_CELLLIST set. >>> However, the draft does not specify how to handle a RC_CELLLIST >>> response. >>> I'm assuming that it means the same as RC_RESET or RC_NOALLOC: abort >>> transaction, don't add/delete anything. Is this correct? In any case, >>> I think this should be made clear in the draft. >>> >>> XV: we clarified this in the draft. Thanks. >>> " In case the received Response Code is RC_ERR_CELLLIST. The transaction >>> is aborted and no cell is relocated." >>> >>> >>> LS: Great, thank you. (I think there should be a comma instead of a full >>> top behind RC_ERR_CELLLIST, though?) >>> >>> Handling RC_RESET Response messages >>> ------------------------------------------------------------ >>> Section 3.4.3 says: >>> "If a node receives a 6P Request from a given neighbor before having >>> sent the 6P Response to the previous 6P Request from that neighbor, it MUST >>> send back a 6P Response with a return code of RC_RESET (as per Figure 36). >>> A node receiving RC_RESET code MUST abort the transaction and consider it >>> never happened." >>> >>> I'm assuming that the node sending the RC_RESET response discards all >>> data on this transaction after it has sent the Response, is this correct? >>> If so, I'd propose to state this explicitly. >>> >>> XV: this text has been clarified so it is pointed that the sender also >>> discards the second transaction. >>> >>> Timeout management >>> ------------------------------- >>> Section 3.4.4. explains how a timeout works and when it occurs, but not >>> what is supposed to happen when it occurs. From section 3.1.1. >>> I gathered that open transactions are aborted on timeout. It might seem >>> trivial, but I think it'd be handy to explicitly mention this in section >>> 3.4.4. >>> >>> XV: We added a clarification in section 3.4.4. >>> "When a timeout occurs the transaction MUST be cancelled at the node >>> where the timeout occurred." >>> >>> SeqNum maintenance >>> -------------------------------- >>> Am I correct in assuming that the SeqNum is maintained as a shared >>> SeqNum on a per-link basis (as opposed to A and B maintaining an internal >>> SeqNum each, and keeping track of the others' seqNum as well)? >>> i.e. if Node A and Node B share a link which was created by an ADD >>> request from A to B, they commit to maintaining (i.e. increasing with every >>> transaction) the sequence number that A included in its initial ADD >>> request. This sequence number is valid only for the link between Nodes A >>> and B. >>> If Node A also has a link to a Node C, their (shared) Sequence Number >>> might be completely different. >>> >>> XV: yes this is how it works. The SeqNum is a representation of the >>> transactions between 2 particular nodes (e.g A and B). A and C will have >>> another one. >>> >>> >>> LS: That's reassuring to hear, thanks for clearing this up. I'm not sure >>> if this is me being used to Sequence Numbers being used in a slightly >>> different way, but it took me a bit to figure this out. In my opinion, your >>> second sentence "The SeqNum is a representation of the transactions >>> between 2 particular nodes (e.g A and B)." sums it up perfectly, and I >>> think it might be useful to wedge it between the second and third sentence >>> of section 3.4.6., so that it reads: >>> >>> "The SeqNum is the field in the 6top IE header used to match Request, >>> >>> Response and Confirmation. The SeqNum is used to detect and handle >>> duplicate commands (Section 3.4.6.1 >>> <https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-10#section-3.4.6.1>) >>> and schedule inconsistencies >>> (Section 3.4.6.2 >>> <https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-10#section-3.4.6.2>). >>> It is a representation of the transactions between 2 particular >>> >>> nodes: each node remembers the last used SeqNum for each neighbor." >>> >>> >>> >>> Handling a Request with SeqNum == 0 >>> ------------------------------------------------------------ >>> ---------------- >>> I couldn't find any language explicitly specifying what to do when a >>> SeqNum of 0 is received (except for Fig.. 30). >>> I'm assuming it is the following: >>> >>> - assume the node has reset: cancel any half-open transactions, let SF >>> decide how to handle the situation >>> - if 3-step transactions are used and there's an active transaction: >>> send response with 6p, send response with return code RC_SEQNUM and SeqNum >>> = 0 >>> - if there's no active transaction: we might just be hearing from this >>> new node for the first time because it was just freshly booted & added to >>> the >>> network (and thus its SeqNum is 0) >>> >>> is this correct? If so, would it make sense to state something like this >>> in section 3.4.6? >>> >>> XV: thanks, seeing how you understood it we think the current >>> description is clear. >>> >>> >>> LS: it actually took me a while to get it right... >>> >>> >>> >>> SeqNum == 0 (again) >>> ------------------------------ >>> What happens when >>> 1. Node A sends a Request to Node B >>> 2. Node A reboots (i.e. the sequence number is reset to 0) >>> 3. Node A sends another Request to B >>> >>> Does Node B recognize that A has reset and cancel the ongoing >>> transaction (as well as the whole "stale" link)? >>> Does it trigger the inconsistency handling of the SF? >>> Could this never occur because A should wait with sending any Request >>> for $timeout time so that all half-open transactions can expire? >>> >>> XV: if this is a 2-way transaction, B sends the ack to A and commits the >>> transaction. Then A resets. In the next transaction, B expects >>> A to have a SeqNum different than 0 but is 0. This is an inconsistency >>> situation. The SF MUST decide what to do. Either CLEAR or remove the >>> last installed cells from A. >>> if this is a 3-way transaction. If B receives the confirmation, the same >>> as before applies. if B does not receive the Confirmation message then >>> B timeouts and the transaction in cancelled. B upon receiving a SeqNum >>> from A will be detect a possible inconsistency situation again. >>> >>> >>> LS: Wait a second, wouldn't Node A send a CLEAR after reboot anyway, >>> which prevents the confusion which I was trying to construct because it >>> finishes any half-open transactions that might still exist? >>> >>> >>> >>> Cell Relocation >>> ---------------------- >>> Section 3.3.3. says that NumCells MUST be >= 1. What happens if (for >>> example) the Relocation CellList contains 5 cells, but NumCells == 1? >>> Shouldn't it be that NumCells MUST be == length(Relocation CellList)? >>> >>> XV: the draft states: The Relocation CellList MUST contain exactly >>> NumCells entries. >>> >>> >>> LS: Ah, I think I confused it with " NumCandidate MUST be 0, equal to >>> NumCells, or greater than NumCells." from the Candidate CellList >>> description then, sorry. >>> Re-reading it, though, the paragraph "The Relocation CellList MUST >>> contain exactly NumCells entries. The Candidate CellList MUST contain >>> at least NumCells entries." strikes me as a bit confusing– Section 3.3.3. >>> also says "NumCandidate MUST be 0, equal to NumCells, or greater than >>> NumCells", so a Relocate Request with NumCells = 5 and CandidateCells = >>> [] would be legal according to the second text snipped, but illegal >>> according to the first. Shouldn't it say "NumCandidate MUST be equal to >>> or greater than NumCells." in the second snippet? >>> >>> >>> Regarding the Bitbucket links in Appendix C >>> ---------------------------------------------------------------- >>> They don't seem to work for me, is this on purpose? >>> XV: this is a temporary changelog. Most of the issues have been closed >>> or even removed. This will be deleted at the end so no worries. >>> >>> >>> LS: Of course, I was just curious to have a look at the (resolved) >>> issues so that I won't ask questions/make suggestions which you've already >>> discussed and discarded. >>> >>> >>> With best regards, >>> Lotte Steenbrink >>> >>> >>> 2018-02-28 13:56 GMT+01:00 Lotte Steenbrink < >>> [email protected]>: >>> >>>> 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. >>>> >>>> Also, NOALLOC doesn't appear in Figure 36: 6P Return Codes, is this on >>>> purpose? >>>> >>>> *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? >>>> >>>> On a side note, fig. 14 is missing the descriptions for the T and Code >>>> fields (i.e. to which values they should be set) that the other figures >>>> have, and while it's possible to infer these values from the draft, I >>>> personally think it'd be handy to have them near the figure as well. :) >>>> >>>> *Erroneous CellOptions in ADD request* >>>> *-------------------------------------------------------* >>>> What happens if a node receives an ADD request where more than one link >>>> type (RX, TX or SHARED) is set in the cellOptions field? I'd assume it >>>> would send an error response, but of which type? RC_CELLLIST? >>>> >>>> *Handling CandidateCellList.size() < numCells in Relocate responses* >>>> >>>> *-------------------------------------------------------------------------------------------* >>>> Section 3.3..3 states that in a 6P RELOCATE request, " NumCandidate >>>> MUST be larger or equal to NumCells", but doesn't specify how Node B >>>> should react if it receives a Relocate request that violates this >>>> requirement. Does it respond with an RC_CELLLIST error message? If so, I'd >>>> propose to change the first sentences of the paragraph starting with "Upon >>>> receiving the request" to something along the lines of: >>>> >>>> "Upon receiving the request, Node B checks if the length of >>>> candidateCellList is be larger or equal to NumCells. Node B's SF verifies >>>> that all the cells in the Relocation CellList are indeed scheduled with >>>> node A and are of the link type specified in the CellOptions field. If any >>>> of these checks fail, node B MUST send a 6P Response to node A with >>>> return code RC_CELLLIST. [...]" >>>> >>>> *6P CLEAR Response format* >>>> *----------------------------------------* >>>> 1. If the value of SeqNum doesn't matter for CLEAR messages, why do >>>> they have a SeqNum field nonetheless? >>>> 2. Section 3.2.2 says "The Code field contains a 6P Return Code when >>>> the 6P message is of Type RESPONSE or CONFIRMATION." However, the 6P >>>> Return Codes listed in Section 6.2.4. don't list an RC_CLEAR code. Should >>>> an RC_CLEAR code be added to section 6.2.4. or should CLEAR response >>>> messages in fact have CMD_CLEAR set in their code field? (For the >>>> record, the former seems more intuitive to me personally) >>>> Or am I misunderstanding something entirely? >>>> >>>> *Handling RC_CELLLIST Response messages* >>>> *----------------------------------------------------------------* >>>> The Draft states that a faulty RELOCATE message should be responded to >>>> with a 6P response with RC_CELLLIST set. However, the draft does not >>>> specify how to handle a RC_CELLLIST response. I'm assuming that it >>>> means the same as RC_RESET or RC_NOALLOC: abort transaction, don't >>>> add/delete anything. Is this correct? In any case, I think this should be >>>> made clear in the draft. >>>> >>>> *Handling RC_RESET Response messages* >>>> *------------------------------------------------------------* >>>> Section 3.4.3 says: >>>> "If a node receives a 6P Request from a given neighbor before having >>>> sent the 6P Response to the previous 6P Request from that neighbor, it MUST >>>> send back a 6P Response with a return code of RC_RESET (as per Figure 36). >>>> A node receiving RC_RESET code MUST abort the transaction and consider it >>>> never happened." >>>> >>>> I'm assuming that the node sending the RC_RESET response discards all >>>> data on this transaction after it has sent the Response, is this correct? >>>> If so, I'd propose to state this explicitly. >>>> >>>> *Timeout management* >>>> *-------------------------------* >>>> Section 3.4.4. explains how a timeout works and when it occurs, but not >>>> what is supposed to happen when it occurs. From section 3.1.1 >>>> <https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-09#section-3.1.1> >>>> . >>>> I gathered that open transactions are aborted on timeout. It might seem >>>> trivial, but I think it'd be handy to explicitly mention this in section >>>> 3.4.4. >>>> >>>> *SeqNum maintenance* >>>> *--------------------------------* >>>> Am I correct in assuming that the SeqNum is maintained as a shared >>>> SeqNum on a per-link basis (as opposed to A and B maintaining an internal >>>> SeqNum each, and keeping track of the others' seqNum as well)? >>>> i.e. if Node A and Node B share a link which was created by an ADD >>>> request from A to B, they commit to maintaining (i.e. increasing with every >>>> transaction) the sequence number that A included in its initial ADD >>>> request. This sequence number is valid only for the link between Nodes A >>>> and B. If Node A also has a link to a Node C, their (shared) Sequence >>>> Number might be completely different. >>>> >>>> *Handling a Request with SeqNum == 0* >>>> >>>> *----------------------------------------------------------------------------* >>>> I couldn't find any language explicitly specifying what to do when a >>>> SeqNum of 0 is received (except for Fig. 30). >>>> I'm assuming it is the following: >>>> >>>> - assume the node has reset: cancel any half-open transactions, let SF >>>> decide how to handle the situation >>>> - if 3-step transactions are used *and *there's an active transaction: >>>> send response with 6p, send response with return code RC_SEQNUM and SeqNum >>>> = 0 >>>> - if there's no active transaction: we might just be hearing from this >>>> new node for the first time because it was just freshly booted & added to >>>> the network (and thus its SeqNum is 0) >>>> >>>> is this correct? If so, would it make sense to state something like >>>> this in section 3.4.6? >>>> >>>> *SeqNum == 0 (again)* >>>> *------------------------------* >>>> What happens when >>>> 1. Node A sends a Request to Node B >>>> 2. Node A reboots (i.e. the sequence number is reset to 0) >>>> 3. Node A sends another Request to B >>>> >>>> Does Node B recognize that A has reset and cancel the ongoing >>>> transaction (as well as the whole "stale" link)? Does it trigger the >>>> inconsistency handling of the SF? Could this never occur because A should >>>> wait with sending any Request for $timeout time so that all half-open >>>> transactions can expire? >>>> >>>> *Cell Relocation* >>>> *----------------------* >>>> Section 3.3.3. says that NumCells MUST be >= 1. What happens if (for >>>> example) the Relocation CellList contains 5 cells, but NumCells == 1? >>>> Shouldn't it be that NumCells MUST be == length(Relocation CellList)? >>>> >>>> *Regarding the Bitbucket links in Appendix C* >>>> *----------------------------------------------------------------* >>>> They don't seem to work for me, is this on purpose? >>>> >>>> >>>> With best regards, >>>> Lotte Steenbrink >>>> >>>> _______________________________________________ >>>> 6tisch mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/6tisch >>>> >>>> >>> >>> >>> -- >>> Dr. Xavier Vilajosana >>> Wireless Networks Lab >>> >>> *Internet Interdisciplinary Institute (IN3)Professor* >>> (+34) 646 633 681 <+34%20646%2063%2036%2081> >>> [email protected] <[email protected]> >>> http://xvilajosana.org >>> http://wine.rdi.uoc.edu >>> Parc Mediterrani de la Tecnologia >>> Av Carl Friedrich Gauss 5, B3 Building >>> <https://maps.google.com/?q=Av+Carl+Friedrich+Gauss+5,+B3+Building+08860+Castelldefels+(Barcelona).+Catalonia.+Spain&entry=gmail&source=g> >>> 08860 Castelldefels (Barcelona). Catalonia. Spain >>> <https://maps.google.com/?q=Av+Carl+Friedrich+Gauss+5,+B3+Building+08860+Castelldefels+(Barcelona).+Catalonia.+Spain&entry=gmail&source=g> >>> [image: Universitat Oberta de Catalunya] >>> >>> _______________________________________________ >>> 6tisch mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/6tisch >>> >>> >>> >>> _______________________________________________ >>> 6tisch mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/6tisch >>> >>> >> >> >> -- >> ________________________________________ >> >> Thomas Watteyne, PhD >> Research Scientist & Innovator, Inria >> Sr Networking Design Eng, Analog Devices >> Founder & co-lead, UC Berkeley OpenWSN >> Co-chair, IETF 6TiSCH >> >> www.thomaswatteyne.com >> ________________________________________ >> >> _______________________________________________ >> 6tisch mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/6tisch >> >> > > > -- > Dr. Xavier Vilajosana > Wireless Networks Lab > > *Internet Interdisciplinary Institute (IN3)Professor* > (+34) 646 633 681 <+34%20646%2063%2036%2081> > [email protected] <[email protected]> > http://xvilajosana.org > http://wine.rdi.uoc.edu > Parc Mediterrani de la Tecnologia > Av Carl Friedrich Gauss 5, B3 Building > <https://maps.google.com/?q=Av+Carl+Friedrich+Gauss+5,+B3+Building+08860+Castelldefels+(Barcelona).+Catalonia.+Spain&entry=gmail&source=g> > 08860 Castelldefels (Barcelona). Catalonia. Spain > <https://maps.google.com/?q=Av+Carl+Friedrich+Gauss+5,+B3+Building+08860+Castelldefels+(Barcelona).+Catalonia.+Spain&entry=gmail&source=g> > [image: Universitat Oberta de Catalunya] > > -- ________________________________________ Thomas Watteyne, PhD Research Scientist & Innovator, Inria Sr Networking Design Eng, Analog Devices Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH www.thomaswatteyne.com ________________________________________
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
