All,
Let me chime in. See my coments inline.
Thanks,
Diego
2017-09-29 9:12 GMT-03:00 Thomas Watteyne <thomas.watte...@inria.fr>:
> 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
>>
>
According to the 6P draft,
The SF has currently 4 main tasks/functions:
- Decide when to add/delete cells
- Decide when to relocate cells
- Keep up-to date statistics on cells
- Define every transaction timeout
I think that if specific items are mentioned in the
introduction, either all or none of them should
be mentioned.
>
>>
>> <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.
>>
>
It must be specified that this is a fixed definition of the SF by design,
and it cannot be changed dynamically, so this
item must be specified on the SF requirements list.
>
>>
>> <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.}
>>
>
Agree. Again, the SF requirements list must include "MUST verify that the
SF is supported on the target neighbour", for example
>
>>
>> <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?
>>
>
The SF is in charge of the timeout calculation, and it does it in a
per-transaction basis (there is no a single value,
but depends on the transaction). Does an exchange include all the
sequential ADD requests until the whole number
of required cells is satisfied? Is an exchange a single ADD command, for
example? If it is a single ADD command,
why it does depend on the number of cells to be scheduled between neighbour
nodes? Is it because of the packet
size?
>
>>
>> <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?
>>
>
How can the SF validate the state on both sides?
>
>>
>> <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.
>>
>
I do agree with Pascal on this point too. Unless the SF (on both sides) has
a way to rollback the schedule changes
without affecting other connections (imagine the case when the schedule
version was not updated on the neighbour
and a number of transactions with other neighbours happened before it was
detected), issuing a clear is the best
way of solving the inconsistency. The SF will have to issue a new ADD
command to recover the resources lost.
>
>>
>> <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>
>>
>
I agree with Pascal, at the SF there is still a field where SF-to-SF
messages can be issued (Metadata)
This requires at least a change also on section 3.2.3:
The CellOptions is an opaque set of bits, sent unmodified to the SF.
The SF MAY redefine the format of the CellOptions bitmap. The SF MAY
redefine the meaning of the CellOptions bitmap.
And on section 3.2.4:
The CellList is an opaque set of bytes, sent unmodified to the SF.
The SF MAY redefine the format of the CellList field.
>
>>
>> 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
>
>
--
DIEGO DUJOVNE
Profesor Asociado
Escuela de Informática y Telecomunicaciones
Facultad de Ingeniería - Universidad Diego Portales - Chile
www.ingenieria.udp.cl
(56 2) 676 8125
_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
