[6tisch] Handling Inconsistent Allocation in 6P

Yasuyuki Tanaka <yasuyuki9.tanaka@toshiba.co.jp> Mon, 21 November 2016 19:04 UTC

Return-Path: <yasuyuki9.tanaka@toshiba.co.jp>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01035129B3D for <6tisch@ietfa.amsl.com>; Mon, 21 Nov 2016 11:04:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9i_daJ0wigc for <6tisch@ietfa.amsl.com>; Mon, 21 Nov 2016 11:04:41 -0800 (PST)
Received: from mo.tsb.2iij.net (mo1501.tsb.2iij.net [210.149.48.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F40BC129B6E for <6tisch@ietf.org>; Mon, 21 Nov 2016 11:04:39 -0800 (PST)
Received: by mo.tsb.2iij.net (tsb-mo1501) id uALJ4c7Y003984; Tue, 22 Nov 2016 04:04:38 +0900
Received: from unknown [172.27.153.190] (EHLO tsb-mr1502.hop.2iij.net) by mas1508.tsb.2iij.net(mxl_mta-7.2.4-7) with ESMTP id 64543385.0.191798.00-596.353273.mas1508.tsb.2iij.net (envelope-from <yasuyuki9.tanaka@toshiba.co.jp>); Tue, 22 Nov 2016 04:04:38 +0900 (JST)
X-MXL-Hash: 58334546223ed8cd-40595f08f5b13356edf7fdbd1334f8d911347c55
Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by relay.tsb.2iij.net (tsb-mr1502) with ESMTP id uALJ4c7j020932 for <6tisch@ietf.org>; Tue, 22 Nov 2016 04:04:38 +0900
Received: from tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp ([133.199.232.103]) by imx12.toshiba.co.jp with ESMTP id uALJ4c72008417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <6tisch@ietf.org>; Tue, 22 Nov 2016 04:04:38 +0900 (JST)
Received: from tsbmgw-mgw01 (localhost [127.0.0.1]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id uALJ4O9f031121 for <6tisch@ietf.org>; Tue, 22 Nov 2016 04:04:24 +0900
Received: from localhost ([127.0.0.1]) by tsbmgw-mgw01 (JAMES SMTP Server 2.3.1) with SMTP ID 720 for <6tisch@ietf.org>; Tue, 22 Nov 2016 04:04:24 +0900 (JST)
Received: from arc11.toshiba.co.jp ([133.199.90.127]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id uALJ4J2i031073 for <6tisch@ietf.org>; Tue, 22 Nov 2016 04:04:19 +0900
Received: (from root@localhost) by arc11.toshiba.co.jp id uALJ4JrM002275 for 6tisch@ietf.org; Tue, 22 Nov 2016 04:04:19 +0900 (JST)
Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id EAA02274; Tue, 22 Nov 2016 04:04:18 +0900
Received: from mx2.toshiba.co.jp (mx2 [133.199.192.142]) by ovp11.toshiba.co.jp with ESMTP id uALJ4Iso014411 for <6tisch@ietf.org>; Tue, 22 Nov 2016 04:04:18 +0900 (JST)
Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id uALJ4IgS012306; Tue, 22 Nov 2016 04:04:18 +0900 (JST)
Received: from [133.196.17.226] (nm-pptp226.isl.rdc.toshiba.co.jp [133.196.17.226]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPSA id AE7BBFF416; Tue, 22 Nov 2016 04:04:17 +0900 (JST)
From: Yasuyuki Tanaka <yasuyuki9.tanaka@toshiba.co.jp>
To: 6tisch@ietf.org
Message-ID: <3e5dd77a-526c-e4fd-e1ef-84084056004b@toshiba.co.jp>
Date: Mon, 21 Nov 2016 20:04:14 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-2022-jp"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
X-MAIL-FROM: <yasuyuki9.tanaka@toshiba.co.jp>
X-SOURCE-IP: [172.27.153.190]
X-Spam: exempt
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/COHfulgI-yfakN1jQE0a9g7ZubE>
Subject: [6tisch] Handling Inconsistent Allocation in 6P
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Nov 2016 19:04:44 -0000

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