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 >> 08860 Castelldefels (Barcelona). Catalonia. Spain >> [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 [email protected] <[email protected]> http://xvilajosana.org http://wine.rdi.uoc.edu Parc Mediterrani de la Tecnologia Av Carl Friedrich Gauss 5, B3 Building 08860 Castelldefels (Barcelona). Catalonia. Spain [image: Universitat Oberta de Catalunya]
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
