Pascal and Diego, thank you very much for your comments.
Xavi, let me know what I can help.
ThanksQin
On Friday, September 29, 2017 8:30 AM, Xavi Vilajosana Guillen
<[email protected]> wrote:
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/r fc8126 Instead of RFC 5226Several occurences
<snip> Voila! Take care, Pascal
______________________________ _________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/l istinfo/6tisch
--
______________________________ _________
Thomas Watteyne, PhDResearch Scientist & Innovator, InriaSr Networking Design
Eng, Linear TechFounder & co-lead, UC Berkeley OpenWSNCo-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]
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 |
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
