Subject: [6tisch] 6P unclarities

From: Simon Duquennoy <[email-masked]>
Date: Tue, 22 Nov 2016 20:40:45 +0100

Hi all,

Reading the current draft draft-ietf-6tisch-6top-protocol-03, a few
points were not clear to me:

* Section 4.2.7: why do cells only have a recommended format? I guess
it's up to the SF, but if so, this is worth stating explicitly.

* Section 4.2.7: what happens when cells don't fit a single packet?
This was answered here [1] but I couldn't find any info in the text.

* Section 4.3: protocol behavior. only 2-way transactions are
detailed, why not 3-way?

* Section 4.3: when to use 2 or 3-way transactions? Is the latter for
added reliability or only to handle the case where the request has
CellList == []. Clarification needed IMO.

* Section 4.3: do we wait for a link-layer ACK on the Response (or
Confirmation) before committing the transaction?

* Section 4.3: no description of the STATUS command?

* Section 4.3.2: interaction among different SFs: does LIST return
only the current SF's cells or all cells in the system? Can DELETE
remove cells installed by other SFs? Does CLEAR clear cells installed
by other SFs?

* Section 4.3.11.1: single bit for the GTX/GRX count value means two
consecutive failed transactions will be forever unnoticed. Is that ok?
Couldn't we use a single 4-bit counter instead of two 2-bit? Wouldn't
a simple counter work instead of lollipop?

* Terminology: I've seen both "2-steps" and "2-ways" used in the document

* General / open: is there any option to install broadcast cells? (a
bit tricky as this needs consensus over 2+ nodes, this probably takes
a 2PC or 3PC, but can be needed)

* General / open: should we recommend / force having at least one
rendez-vous cell (via minimal or otherwise), so as to guarantee
reachability of all nodes? Else, a single failed CLEAR transaction
results in definitive loss of connectivity between two nodes.

Apologies if this was covered in previous discussions I might have
missed. Please let me know if I should have opened tickets on the
issue tracker instead.

Thanks,
Simon

[1] https://www.ietf.org/mail-archive/web/6tisch/current/msg04758.html

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Wed, 23 Nov 2016 02:12:03 +0100

Hi all,

I also have comments on draft-ietf-6tisch-6top-protocol-03; some of
them are covered by Simon. :-)
# I put a tag for each item: [C] for comment/suggestion, [Q] for
# question.

* Section 4.2.2:

- [Q] Why must the value of SeqNum increment *by exactly one* at each
       new 6P request to a certain neighbor?

* Section 4.2.6:

- [C] There are ineffective combinations of CellOptions in Figure 11,
       for example, "TX=0,RX=0,S=1".

- [C] I'd suggest listing only valid combinations of CellOption bits
       and mentioning others are invalid.

- [C] The phrase, "marked as", in Figure 11 is a bit ambiguous... Something
       like "its linkOptions matches exactly" is better?

* Section 4.2.13:

- [C] The length of "Num. Cells" is 2-octet long in the text, but
       1-octet in the figure.
       # The Wirehark patch for draft-03 treats the field as a
       # one-octet field.

draft> When responding to an STATUS request, the "Other Field"
draft> contains the number of cells scheduled between node A and node
draft> B that match the CellOptions field, encoded as a 2-octet
draft> unsigned integer.  This is shown in Figure 12.
draft>
draft>                       1                   2                   3
draft>   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
draft>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
draft>  |Version| T | R |     Code      |     SFID      | SeqNum|GAB|GBA|
draft>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
draft>  | Num. Cells    |
draft>  +-+-+-+-+-+-+-+-+
draft>
draft>                              Figure 12

* Section 4.3:

simon> do we wait for a link-layer ACK on the Response (or
simon> Confirmation) before committing the transaction?

I came up with the same question while thinking about the
inconsistency handling thing.

- [C] I guess, most of implementation send a data frame with an
       acknowledged transmission. But, according to IEEE 802.15.4, it
       seems an option even for the Data frame. If a 6P frame is always
       expected to require a MAC level acknowledgement, it'd be better
       to mention like, "a 6P frame SHOULD/MUST have one in the AR
       field".

- [Q] If yes to the question by Simon, is it a right thing for 6P, an
       upper layer protocol on IEEE 802.15.4 MAC, to use the MAC level
       acknowledgement as signaling for its own purpose?

- [C] If an operation is executed after sending a response, I guess so
       as per 4.3.11, the description of RC_SUCCESS in Figure 9 would
       need to be updated. Strictly speaking, an ADD/DELETE/CLEAR
       operation is yet to be done at the time of sending a response
       with RC_SUCCESS to a corresponding request. The current
       description for RC_SUCCESS is "operation succeeded".

* Section 4.3.3:

- [Q] Are the following sentences correct? They allow a pair of nodes
       to open two transactions in parallel. I think these transactions
       might cause inconsistency in their schedule generations.

draft> Only a single 6P Transaction between two neighbors, in a given
draft> direction, can take place at the same time.
draft> (snip)
draft> Nodes A and B MAY support having two transactions going on at
draft> the same time, one in each direction.

       Here is a simple example in which nodes update their schedule
       generation counters after receiving a MAC-level ACK for a 6P
       Response frame:

       Step-1: Node A Send Request  (GAB=0, GBA=0) : Queued
       Step-2: Node B Send Request  (GAB=0, GBA=0) : Queued

       Step-3: Node B Recv Request                 : Send MAC-ACK
       Step-4: Node B Send Response (GAB=0, GBA=0) : Queued
       Step-5: Node A Recv Request                 : Send MAC-ACK
       Step-6: Node A Send Response (GAB=0, GBA=0) : Queued

       Step-7: Node A Recv Response                : Send MAC-ACK
       Step-8: Node B Update GTX/GRX               : (GTX=0, GRX=1)
       Step-8: Node B Recv Response (GAB=0, GBA=0) : Detect Inconsistency

* Section 4.3.10

- [C] I'm not sure typical use cases of the LIST operation. When does
       a SF use STATUS and LIST...? I think these commands would be
       useful for the purpose of management or administration. But,
       it's not within the scope of SF, is it? I'd be nice that a
       typical use case of LIST is provided in the text.

* General / open:

simon> is there any option to install broadcast cells? (a bit tricky
simon> as this needs consensus over 2+ nodes, this probably takes a
simon> 2PC or 3PC, but can be needed)

+1.

- [C] The draft implies that a MAC address of the peer is set to the
       "macNodeAddress" attribute of a allocated cell. If this is the
       case, it'd be better to mention that in the text.

I have a couple of related questions in addition to what Simon asked:

- [Q] What if a node has a short address as well as an extended
       address?

- [Q] Is there any plan for 6P to support the following cells?
       - a cell whose macNodeAddress is a group MAC address or a 16-bit
         multicast address
       - a dedicated TX cell to multiple recipients
       - a RX cell shared with multiple senders

That's all! Thank you!!

Best,
Yatch

On 2016/11/22 20:40, Simon Duquennoy wrote:
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>