Talk to you then! Simon
On Fri, Dec 9, 2016 at 3:15 PM, Thomas Watteyne <[email protected]> wrote: > 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 > _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
