Hi, yes I will do it asap.
thanks Pascal for the comments!! X 2017-09-29 14:12 GMT+02:00 Thomas Watteyne <[email protected]>: > Thanks Pascal for the feedback. @Xavi, would you have a second to turn > those suggestions into issue on the bitbucket repo? > > On Fri, Sep 29, 2017 at 12:31 PM, Pascal Thubert (pthubert) < > [email protected]> wrote: > >> Dear authors: >> >> >> >> All in all, I think the document is ready but believe that a pass on >> language from a native person may help. >> >> >> >> Also, the document should include a terminology where all the terms are >> defined, e.g. NumCandidates and so on. >> >> >> >> Still, Please find my comments, with a [PT] tag associated with text >> snippets, below: >> >> >> >> <snip> >> >> >> >> Abstract >> >> >> >> This document defines the 6top Protocol (6P), which enables >> >> distributed scheduling in 6TiSCH networks. 6P allows neighbor nodes >> >> to add/delete TSCH cells to one another. 6P is part of the 6TiSCH >> >> Operation Sublayer (6top), the next higher layer to the IEEE Std >> >> 802.15.4 TSCH medium access control layer. The 6top Scheduling >> >> Function (SF) decides when to add/delete cells, and triggers 6P >> >> Transactions. Several SFs can be defined, each identified by a >> >> different 6top Scheduling Function Identifier (SFID). This document >> >> lists the requirements for an SF, but leaves the definition of the SF >> >> out of scope. SFs are expected to be defined in future companion >> >> specifications. >> >> >> >> [PT] that’s too much text on SF which is out of scope. Enough to say that >> the 6top sublayer comprises the 6P protocol defined here, and a SF that >> “decides when to add/delete cells, and triggers 6P Transactions” >> >> This must be repeated in the intro to position 6P vs. 6top vs. SF >> >> >> >> <snip> >> >> >> >> 1. Introduction >> >> >> >> All communication in a 6TiSCH network is orchestrated by a schedule >> >> [RFC7554]. This specification defines the 6top Protocol (6P), part >> >> of the 6TiSCH Operation sublayer (6top). 6P allows a node to >> >> [PT] that’s concise! Please introduce that the schedule indicates >> transmission cells in the [slotOffset,channelOffset] CDU matrix and point >> at the terminology draft and RFC 7554 for more information. >> >> You’ll be needing this a few lines below. >> >> >> >> communicate with a neighbor to add/delete TSCH cells to one another. >> >> This results in distributed schedule management in a 6TiSCH network. >> >> >> >> <snip> >> >> >> >> In the context of this specification, all the cells used by 6top are >> >> soft cells. Hard cells can be used for example when "hard-coding" a >> >> schedule [RFC8180]. >> >> >> >> [PT] Also ref the 6TiSCH architecture. >> >> >> >> <snip> >> >> >> >> >> >> >> >> >> >> The 6P messages exchanged between nodes A and B during a 6P >> >> Transaction SHOULD be exchanged on dedicated cells between A and B. >> >> If no dedicated cells are scheduled between nodes A and B, shared >> >> cells MAY be used. >> >> >> >> [PT] Define dedicated, the reader does not necessarily know what is meant >> here. Do we need a terminology? >> >> >> >> >> >> <snip> >> >> >> >> >> >> A 6P Transaction can consist of 2 or 3 steps. An SF MUST specify >> >> whether to use 2-step transactions, 3-step transactions, or both. >> >> >> >> [PT] Hum, the fact that 2 step and 3 steps are meant to enable >> respectively the requester or the responder to allocate the cells should be >> said clearly here, before 3.1.1. >> >> When the reader is here, he does not figure why there are 2 models. >> >> >> >> <snip> >> >> >> >> >> >> 3.1.1. 2-step 6P Transaction >> >> >> >> Figure 4 shows an example 2-step 6P Transaction. In a 2-step >> >> transaction, node A selects the candidate cells. Several elements >> >> are left out to simplify understanding. >> >> >> >> >> >> >> >> +----------+ +----------+ >> >> | Node A | | Node B | >> >> +----+-----+ +-----+----+ >> >> | | >> >> | 6P ADD Request | >> >> | Type = REQUEST | >> >> | Code = ADD | >> >> | SeqNum = 123 | >> >> | NumCells = 2 | >> >> timeout | CellList = [(1,2),(2,2),(3,5)] | >> >> --- |-------------------------------------->| >> >> | | | >> >> | | 6P Response | >> >> | | Type = RESPONSE | >> >> | | Code = SUCCESS | >> >> | | SeqNum = 123 | >> >> | | CellList = [(2,2),(3,5)] | >> >> X |<--------------------------------------| >> >> | | >> >> >> >> Figure 4: An example 2-step 6P Transaction. >> >> >> >> In this example, the 2-step transaction occurs as follows: >> >> >> >> >> >> [PT] MAC-layer acks should be shown for completeness, since they are >> being used in the logic of the protocol. >> >> >> >> <snip> >> >> >> >> 6P messages travel over a single hop. 6P messages are carried as >> >> payload of an IEEE 802.15.4 Payload Information Element (IE) >> >> [IEEE802154]. The messages are encapsulated with the Payload IE >> >> Header (per Section 7.4.3 of the [IEEE802154]). The Group ID is set >> >> >> >> >> >> [PT] Be careful when citing down to a section. I think that this implies >> that you place a dated reference to the IEEE spec, like 2015. And you do >> not want that. >> >> => I think you have to omit “per Section 7.4.3 of the” >> >> >> >> <snip> >> >> >> >> Other Fields: The list of other fields depends on the type of >> >> messages, and is detailed in Section 3.3. >> >> >> >> [PT] More precisely the other fields are the options below and how they >> are used is detailed in 3.3, no? >> >> >> >> +-------------+-------------------------------------------------+ >> >> | CellOptions | cells scheduled with A that are to be selected | >> >> | Value | by B when receiving a 6P message from A | >> >> +-------------+-------------------------------------------------+ >> >> |TX=0,RX=0,S=0| select all cells | >> >> +-------------+-------------------------------------------------+ >> >> |TX=1,RX=0,S=0| select the cells scheduled marked as RX | >> >> +-------------+-------------------------------------------------+ >> >> |TX=0,RX=1,S=0| select the cells marked as TX | >> >> +-------------+-------------------------------------------------+ >> >> >> >> [PT] Did you mix up RX and TX above? >> >> >> >> <snip> >> >> >> >> >> >> 3.2.4. 6P CellList >> >> >> >> A CellList field MAY be present in a 6P ADD Request, a 6P DELETE >> >> Request, a 6P RELOCATE Request, a 6P Response or a 6P Confirmation. >> >> It is composed of zero, one or more 6P Cell containers. The contents >> >> of the CellOptions field specify the options associated with all >> >> cells in the CellList. This necessarily means that the same options >> >> are associated with all cells in the CellList. >> >> >> >> [PT] If a CellList is as I expect the concatenation of 6P Cells, then >> maybe you should clarify it; also clarify where NumCandidate is found. >> >> >> >> <snip> >> >> >> >> >> >> The 6P Cell is a 4-byte field, its RECOMMENDED format is: >> >> >> >> >> >> [PT] Is there another format less RECOMMENDED? If not, just say, “its >> format is” or something: >> >> >> >> <snip> >> >> >> >> >> >> >> >> [Page 12] >> >> >> >> Internet-Draft 6tisch-6top-protocol September 2017 >> >> >> >> >> >> Figure 10 defines the format of a 6P ADD Response and Confirmation. >> >> >> >> 1 2 3 >> >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> |Version| T | R | Code | SFID | SeqNum | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> | CellList ... >> >> +-+-+-+-+-+-+-+-+- >> >> >> >> Figure 10: 6P ADD Response and Confirmation Formats. >> >> >> >> CellList: A list of 0, 1 or multiple 6P Cells. >> >> >> >> Consider the topology in Figure 1 where the SF on node A decides to >> >> add NumCells cells to node B. >> >> >> >> Node A's SF selects NumCandidate cells from its schedule as candidate >> >> >> >> >> >> [PT] First use of NumCandidate. Is that a definition? Should be in >> introduced and defined better. Maybe a terminology? >> >> >> >> <snip> >> >> >> >> >> >> >> >> >> >> >> >> In a 2-step 6P RELOCATE Transaction, the candidate CellList MUST >> >> therefore contain at least NumCells entries. >> >> >> >> >> >> >> >> [PT] No, it must contain exactly NumCells entries; otherwise, how do we >> know where the first CellList ends? >> >> >> >> <snip> >> >> >> >> >> >> specified offset. Node B SHOULD include as many cells as fit in the >> >> frame. If the response contains the last cell, Node B MUST set the >> >> Code field in the response to EOL, indicating to Node A that there no >> >> more cells that match the request. Node B MUST return at least one >> >> cell, unless the specified Offset is beyond the end of B's cell list >> >> in its schedule. If node B has less than Offset cells that match the >> >> request, node B returns an empty CellList and a Code field set to >> >> EOL. >> >> >> >> >> >> >> >> [PT] define EOL. Is there a table of Codes? >> >> >> >> <snip> >> >> >> >> >> >> >> >> >> >> 3.4. Protocol Functional Details >> >> >> >> 3.4.1. Version Checking >> >> >> >> All messages contain a Version field. If multiple Versions of the 6P >> >> protocol have been defined (in future specifications for Version >> >> values different from 0), a node MAY implement multiple protocol >> >> versions at the same time. When receiving a 6P message with a >> >> Version number it does not implement, a node MUST reply with a 6P >> >> Response with a Return Code field set to VER_ERR. The Version field >> >> in the 6P Response MUST be the same as the Version field in the >> >> corresponding 6P Request. In a 3-step transaction, the Version field >> >> in the 6P Confirmation MUST match that of the 6P Request and 6P >> >> Response in the same transaction. >> >> >> >> >> >> [PT] How does the node signal the version it supports? How can it even >> build a message that matches the version it does not know? I think it >> should respond with a format that it understands and hat hopefully the >> requester also understands. >> >> >> >> I wonder if there should not be an ERROR message used to report any >> error. It would be defined in this version and would be mandatory to >> implement in all further versions with this version number. >> >> For instance, If a node with an old version receives a message with an >> unknown version, it could return error, wrong version, with the supported >> version as data. >> >> >> >> <snip> >> >> >> >> >> >> 3.4.2. SFID Checking >> >> >> >> Similar, there is now way to enumerate which SFs are supported. >> >> >> >> <snip> >> >> >> >> Response with return code BUSY. In case the requested cells are >> >> locked, it MUST reply to that request with a 6P Response with return >> >> code NORES. The node receiving BUSY or a NORES MAY implement a retry >> >> mechanism, defined by the SF. >> >> >> >> Again, all these codes should have been introduced earlier, at least by a >> forward pointer to table 34. >> >> >> >> <snip> >> >> >> >> >> >> >> >> 3.4.4. Timeout >> >> >> >> A timeout occurs when the node sending the 6P Request has not >> >> received the 6P Response within a specified amount of time determined >> >> by the SF. In a 3-step transaction, a timeout also occurs when the >> >> node sending the 6P Response has not received the 6P Confirmation. >> >> The timeout should be longer than the longest possible time it can >> >> take for the exchange to finish. The value of the timeout hence >> >> depends on the number of cells scheduled between the neighbor nodes, >> >> the maximum number of link-layer retransmissions, etc. The SF MUST >> >> determine the value of the timeout. The value of the timeout is out >> >> of scope of this document. >> >> >> >> >> >> Is there a dependency on the value of a timer on one side vs. the other? >> Eg in a 3-step, do we want the requester to time out first and retry, or >> the responder to retry his response before the requester times out? >> >> >> >> <snip> >> >> >> >> 3.4.6.2. Detecting and Handling Schedule Inconsistency >> >> Inconsistency may happen when L2 acknowledgment of the last packet in >> >> a transaction is lost, i.e. RESPONSE (in 2-step 6P transaction) or >> >> CONFIRMATION (in 3-step 6P transaction) have been received on one >> >> side while timeout happens on the other side. Take 2-step 6P >> >> transaction as example, i.e. timeout happens when node B is waiting >> >> for L2 acknowledgment to its Response message. Upon the timeout, the >> >> SF running on the node that timeout (e.g node B) MUST take action to >> >> validate the schedule state on both sides. >> >> >> >> What makes the node decide what the best course is? Shouldn’t you >> RECOMMEND a way? >> >> Isn’t the last transaction the one that brings an issue? Can we ask the >> number of the last transaction on the other side and use to figure if it is >> the req or the ack that was missed? >> >> >> >> <snip> >> >> >> >> inconsistency is detected. When such inconsistency is detected, node >> >> B MUST respond with the return code INCON_ERR and the transaction >> >> MUST be discarded. It is up to the SF to decide what to do next. >> >> For example, upon receiving INCON_ERR, node A starts a LIST >> >> transaction to node B to obtain the scheduled cells with B. >> >> >> >> >> >> I disagree, it is not up to the SF. The SF asks something, and should be >> answered whether it happened or not. Trouble and cleaning trouble should be >> done at 6P. >> >> OTOH, SF needs to know when an action happens like a clear or something, >> otherwise we have an inconsistency between 6P and SF. >> >> BTW upon a clear that is not on both sides, the right action is probably >> to clear again, no? After a number of tries, failure means a software issue. >> >> >> >> <snip> >> >> >> >> 4. Guidelines for 6top Scheduling Functions (SF) >> >> >> >> This is more like a dependency, things that SF MUST do. The title above >> should be changed, and real guidelines should go to appendix (e.g. 4.3) >> >> >> >> <snip> >> >> >> >> >> >> o MAY redefine the format of the CellList field. >> >> o MAY redefine the format of the CellOptions field. >> >> o MAY redefine the meaning of the CellOptions field. >> >> >> >> >> >> >> >> No, all SF knows about Cells is via APIs, not packet formats. >> >> The format on the wire is 6P business. 6P must parse it and it must >> understand it. >> >> If this is changed, then we need a new protocol version. >> >> >> >> <snip> >> >> >> >> 4.3. Recommended Structure of an SF Specification >> >> >> >> These are guideline that should go in the appendix sc >> >> >> >> <snip> >> >> >> >> >> >> 5. Implementation Status >> >> >> >> This section records the status of known implementations of the >> >> protocol defined by this specification at the time of posting of this >> >> Internet-Draft, and is based on a proposal described in [RFC6982]. >> >> The description of implementations in this section is intended to >> >> assist the IETF in its decision processes in progressing drafts to >> >> RFCs. Please note that the listing of any individual implementation >> >> here does not imply endorsement by the IETF. Furthermore, no effort >> >> has been spent to verify the information presented here that was >> >> supplied by IETF contributors. This is not intended as, and must not >> >> be construed to be, a catalog of available implementations or their >> >> features. Readers are advised to note that other implementations may >> >> exist. >> >> >> >> According to [RFC6982], "this will allow reviewers and working groups >> >> to assign due consideration to documents that have the benefit of >> >> running code, which may serve as evidence of valuable experimentation >> >> and feedback that have made the implemented protocols more mature. >> >> It is up to the individual working groups to use this information as >> >> they see fit". >> >> >> >> >> >> The 2 sections above should go. >> >> >> >> <snip> >> >> >> >> >> >> 6. Security Considerations >> >> >> >> 6P messages are carried inside 802.15.4 Payload Information Elements >> >> (IEs). Those Payload IEs are encrypted and authenticated at the link >> >> layer through CCM*. 6P benefits from the same level of security as >> >> >> >> >> >> Nede ref on CCM* >> >> >> >> <snip> >> >> >> >> >> >> >> >> The IANA policy for future additions to this sub-registry is "IETF >> >> Review or IESG Approval" as described in [RFC5226]. >> >> >> >> Please reference normatively https://tools.ietf.org/html/rfc8126 >> Instead of RFC 5226 >> >> Several occurences >> >> >> >> <snip> >> >> >> >> Voila! >> >> >> >> Take care, >> >> >> >> Pascal >> >> >> >> >> >> _______________________________________________ >> 6tisch mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/6tisch >> >> > > > -- > _______________________________________ > > Thomas Watteyne, PhD > Research Scientist & Innovator, Inria > Sr Networking Design Eng, Linear Tech > 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
