Hi all, I'd like to bring up Nicola's idea, 6P ACK, which came out on the thread of "SF Timeout calculation (Ticket #53)":
https://www.ietf.org/mail-archive/web/6tisch/current/msg04866.html
A 6P ack would make the 6P negotiation reliable. B can 'half' open the RX side after receiving the mac layer ack from A. A will open the TX side after sending the mac layer ack, it the 6P response was in time. It will send the 6P ack possibly in the newly created dedicated cell, so decongesting the shared cell of 'minimal'. If B receives the 6P ack, it will be sure that the RX side is open completely without possible impairment with the node A schedule knowledge. Instead, if the 6P response was out of time, A will not send any 6P ack, will not open the TX side. B will not receive any 6P ack within a timeout (that can be the same length as that starting on the A side after the reception of the mac layer ack to the request packet) and when that expires will delete the RX cells that were 'half' opened. With this, it is not possible to get suspicious cells allocations on the RX side. There's still the possibility that a TX side is open with the RX side not open. But for that, 6P or SF will manage a relocation. Think about the 6P packet as the third part of a 3-way-handshake.
I've been thinking about how to handle inconsistencies. I know the current draft has an inconsistency detection mechanism with generation management; just wondering if there is another way or a supplemental mechanism to deal with such a situation. I thought that the 2-phase commit (2PC) protocol could be useful here. Then, I found the nice idea by Nicola in the ML archive. In terms of the 2PC protocol, 6P ACK is Commit. 6P NACK (mentioned in another email by Nicola) is Abort or Rollback. # We may need another type of message to acknowledge Commit or Abort. An advantage of this approach is that 6P can resolve an inconsistency when it occurs at the least cost, by cancelling the concerned operation alone. An apparent disadvantage is adding further complexity to 6P. What others think...? Best, Yatch _______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
