Hi all, Thanks for an fruitful discussion today!
I wanted to follow up on Nicola's thoughts about adding a final 6P Confirmation to all transactions. There is a fundamental difference in having a 2-way vs 3-way transaction: * 2-way: at the end, the initiator A either (1) commits but does not know B's state or (2) knows both agreed to abort. * 3-way: at the end, the initiator A either (1) aborts but does not know B's state or (2) knows both agreed to commit. In the 2-way case, the initiator never has the guarantee of a successful commit. In the 3-way case, a SF could choose to re-attempt a transaction hoping to reach an agreement to commit. The SF can retry as many times as it sees fit, and CLEAR should it not reach an agreement. Details below: 2-way transaction: PoV of A: * Aborts if not getting Response: => Sends no ACK. Knows B also aborts. <<< agree to abort * Commits if getting Response: => Sends an ACK. Does not know B's final state. <<< !uncertainty! PoV of B: * Aborts if Response not ACKed: => Does not know A's final state. <<< !uncertainty! * Commits if Response ACKed: => Knows A also committed. <<< agree to commit 3-way transaction: PoV of A: * Aborts if Confirmation not ACKed: => Does not know B's final state. <<< !uncertainty! * Commits if Confirmation ACKed: => Knows B also committed. <<< agree to commit PoV of B: * Aborts if not getting Confirmation: => Sends no ACK. Knows A also aborts. <<< agree to abort * Commits if getting Confirmation: => Sends an ACK. Does not know A's final state. <<< !uncertainty! Thanks, Simon On Thu, Dec 15, 2016 at 5:03 PM, Tengfei Chang <[email protected]> wrote: > @Thomas, Thanks a lot for the meeting! > > @Yatch, I like your comments. Looking forwarding to discuss on it. Here are > two more comments(tiny) from my side : > > [slide-17] > > ppt>Section 4.3: do we wait for a link-layer ACK on the Response (or > Confirmation) before committing the transaction? > ppt> à reponse/confirmation. L2 ACK doesn’t carry any 6P meaning > > I agree L2 ACK doesn't carry any 6P meaning. But the node indeed commits the > transaction (adding cell in schedule) after the ACK is sent out/received. > > [slide-21] > > ppt> [Q] Are the following sentences correct? They allow a pair of nodes > ppt> to open two transactions in parallel. I think these transactions > ppy> 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. > > > ppt> Here is a simple example in which nodes update their schedule > > ppt> generation counters after receiving a MAC-level ACK for a 6P > > ppt> Response frame: > > ppt> Step-1: Node A Send Request (GAB=0, GBA=0) : Queued > > ppt> Step-2: Node B Send Request (GAB=0, GBA=0) : Queued > > ppt> Step-3: Node B Recv Request : Send MAC-ACK > > ppt> Step-4: Node B Send Response (GAB=0, GBA=0) : Queued > > ppt> Step-5: Node A Recv Request : Send MAC-ACK > > ppt> Step-6: Node A Send Response (GAB=0, GBA=0) : Queued > > ppt> Step-7: Node A Recv Response : Send MAC-ACK > > ppt> Step-8: Node B Update GTX/GRX : (GTX=0, GRX=1) > > ppt> Step-8: Node B Recv Response (GAB=0, GBA=0) : Detect Inconsistency > > > > This is a good point. So this is called because the GAB/GBA is prepended > early. > At the implementation view, this could be solved to add GAB/GBA at when the > queued packet has already being chosen to sent on a cell. This will look > like the ASN in EB. > > Tengfei > > On Wed, Dec 14, 2016 at 9:21 PM, Yasuyuki Tanaka > <[email protected]> wrote: >> >> Thank you, Thomas. >> >> Let me add comments on a couple of the ppt slides in advance, which >> could save time of the coming meeting, I hope...: >> >> The ppt sides Thomas provided: >> >> https://bitbucket.org/6tisch/meetings/raw/c9bd4d78fa452a0588abefc104d08520d32e0c26/161209_webex/slides_161209_webex.ppt >> >> ------------------------------------------------------------------------ >> >> (6P unclarities 2 [1/4], slide-19) >> >> ppt> Section 4.2.2: [Q] Why must the value of SeqNum increment *by >> ppt> exactly one* at each new 6P request to a certain neighbor? >> ppt> >> ppt> -> Why not? >> >> I think "MUST" is too strict. I thought an idea behind that >> requirement was to try to have different SeqNum to previous >> requests. If this was true, "incrementing by exactly one at each new >> 6P request" could be just an example of implementation. >> >> In addition, there is no validation defined in the draft to see if the >> SeqNum of a receiving request is off by one from the previous one. If >> it was a really "MUST" thing, some validation should be in place, >> shouldn't it? But, of course, such a validation is not practical at >> all since a request could be lost in the air. >> >> I may be wrong; just wanted to know the reason of the restriction, >> "MUST increment by exactly one at each new 6P request issued to the >> same neighbor." >> >> ------------------------------------------------------------------------ >> >> ppt> [C] I'd suggest listing only valid combinations of CellOption >> ppt> bits and mentioning others are invalid. >> ppt> -> isn’t that policy? >> >> Indeed, 6P doesn't care about the meanings of bits in CellOptions in >> its operation. However, the definitions in Figure 11 are RECOMMENDED >> by the draft. I cannot see any reason to have ineffective CellOptions >> values separately in the recommendation... >> >> draft> 4.2.6. 6P CellOptions >> draft> (snip) >> draft> Figure 11 contains the RECOMMENDED meaning of the 6P >> draft> CellOptions field for the 6P STATUS and 6P LIST requests. >> >> In this context, we may have to define a return code to respond to >> CellOptions invalid to a corresponding SF, something like >> RC_ERR_CELL_OPTIONS. Or, should RC_ERR (generic error) be returned? In >> any case, it'd be nice to have some text on checking CellOptions value >> in Section 4.3. >> >> ------------------------------------------------------------------------ >> >> (6P unclarities 2 [4/4], slide-22) >> >> ppt> [C] I'm not sure typical use cases of the LIST operation. When >> ppt> does a SF use STATUS and LIST...? I think these commands would be >> ppt> useful for the purpose of management or administration. But, it's >> ppt> not within the scope of SF, is it? I'd be nice that a typical use >> ppt> case of LIST is provided in the text. >> ppt> -> Recover after reset >> >> Such recovery doesn't work due to generation inconsistency. >> >> Let's say, there are two 6P nodes, Node A and Node B. Node A resets >> after having some Add or Delete operations with node B. Now, both of >> GTX and GRX on Node A are 0b00. At least GTX or GRX on Node B is >> either 0b01 or 0b10. >> >> Then, Node A sends a Status request to Node B for recovery. Node B >> responds with RC_ERR_GEN since GAB and GBA of the request are zero >> while node-B has non-zero GTX and/or non-zero GRX. The Status request >> fails. The same thing will happen to a List request. In the end, Node >> A cannot recover the cells. >> >> Here is an excerpt of Section 4.3.11.3 of draft-03: >> >> draft> Upon receiving a 6P message, a node MUST do the following >> draft> checks: >> draft> >> draft> o When node B receives a 6P Request of 6P confirmation from node A, >> draft> it verifies that GAB==GRX and GBA==GTX. >> draft> >> draft> (snip) >> draft> >> draft> If any of these comparisons is false, the node has detected a >> draft> schedule generation inconsistency. >> draft> >> draft> When a schedule generation inconsistency is detected: >> draft> >> draft> o If the code of the 6P Request is different from CMD_CLEAR, the >> draft> node MUST reply with error code RC_ERR_GEN. >> >> This is related to the topic in the thread of "Handling Inconsistent >> Allocation in 6P." >> >> ------------------------------------------------------------------------ >> >> ppt> - Is there any plan for 6P to support the following cells? >> ppt> >> ppt> - a cell whose macNodeAddress is a group MAC address or a >> ppt> 16-bit multicast address >> ppt> -> No. Use case? >> >> A use-case in my mind is allocating cells for IPv6 multicast. RFC 4944 >> defines the mapping rule between IPv6 multicast address and IEEE >> 802.15.4 16-bit multicast address. >> >> # I'm not sure the exact meaning of "mesh-enabled LoWPAN" in Section 9 >> # of RFC 4944, though... I think Section 9 could be applied to a >> # 6TiSCH network. >> >> I think this has some potential to enable to dynamically allocate >> cells dedicated to ff02::1a (all-RPL-node) or ff0X::fc >> (ALL_MPL_FORWARDERS), for example. >> >> Now, I understand this is out of scope of the draft at this point as >> well as allocating cells for broadcast. >> >> I'm a person interested in multicast, by the way ;-) >> >> ------------------------------------------------------------------------ >> >> ppt> - Is there any plan for 6P to support the following cells? >> ppt> (snip) >> ppt> - a dedicated TX cell to multiple recipients >> ppt> -> IEEE802.15.4e question, multiple cells? >> >> Tero told me that such a TX cell is possible as per the IEEE 802.15.4 >> specification. >> >> https://www.ietf.org/mail-archive/web/6tisch/current/msg04909.html >> >> mail> > Therefore, in theory, we may have a dedicated (non-shared) TX >> mail> > cell whose macNodeAddress is the broadcast address. >> mail> >> mail> Yes. I.e. you are the only one allowed to send to that link, but >> mail> there are multiple listeneres in there. So, as it does not have >> mail> shared bit on, there will not be other transmitters, but there >> mail> can be multiple listeners on it. >> >> ------------------------------------------------------------------------ >> >> ppt> - Is there any plan for 6P to support the following cells? >> ppt> (snip) >> ppt> - a RX cell shared with multiple senders >> ppt> -> supported >> >> OK, then another question comes up... how is a cell having multiple >> senders (or multiple recipients) allocated or deallocated? >> >> For example, one of senders may request to delete such a cell with a >> recipient. However, the recipient is not supposed to delete the cell >> by the request alone since there are other senders on the cell. >> >> If it's supported, some explanation would be needed, about how it >> works, although this kind of detail may be up to SF. >> >> This could be related to the topic about what value is set to >> "macNodeAddress" as a result of 6P Add transaction. >> >> ------------------------------------------------------------------------ >> >> That's it! Thanks. >> >> Best, >> Yatch >> >> _______________________________________________ >> 6tisch mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/6tisch > > > > > -- > Chang Tengfei, > Pre-Postdoctoral Research Engineer, Inria > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch > _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
