Simon, Yatch, We are planning to discuss these points during the 6TISCH call in 45min. Thomas
On Wed, Nov 23, 2016 at 2:12 AM, Yasuyuki Tanaka < [email protected]> wrote: > 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 > -- _______________________________________ 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 [email protected] https://www.ietf.org/mailman/listinfo/6tisch
