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) < pthub...@cisco.com> 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 > 6tisch@ietf.org > 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 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
