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:
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
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
