Subject: [6tisch] Handling Inconsistent Allocation in 6P

From: Yasuyuki Tanaka <[email-masked]>
Date: Mon, 21 Nov 2016 20:04:14 +0100

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