IETF Logo Mail Archive

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

Yasuyuki Tanaka <yasuyuki9.tanaka@toshiba.co.jp> Tue, 29 November 2016 23:03 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 468F6129C9A for <6tisch@ietfa.amsl.com>; Tue, 29 Nov 2016 15:03:47 -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 WQgL16KnYbtY for <6tisch@ietfa.amsl.com>; Tue, 29 Nov 2016 15:03:45 -0800 (PST)
Received: from mo.tsb.2iij.net (mo1502.tsb.2iij.net [210.149.48.174]) (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 512C3124281 for <6tisch@ietf.org>; Tue, 29 Nov 2016 15:03:44 -0800 (PST)
Received: by mo.tsb.2iij.net (tsb-mo1502) id uATN3hRS023158; Wed, 30 Nov 2016 08:03:43 +0900
Received: from unknown [172.27.153.184] (EHLO tsb-mr1500.hop.2iij.net) by mas1504.tsb.2iij.net(mxl_mta-7.2.4-7) with ESMTP id f490e385.0.288915.00-680.529406.mas1504.tsb.2iij.net (envelope-from <yasuyuki9.tanaka@toshiba.co.jp>); Wed, 30 Nov 2016 08:03:43 +0900 (JST)
X-MXL-Hash: 583e094f1d4ac67f-1497ad08146c78e3cede81adedc2f6f4528c1ce8
Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by relay.tsb.2iij.net (tsb-mr1500) with ESMTP id uATN3hZB026752 for <6tisch@ietf.org>; Wed, 30 Nov 2016 08:03:43 +0900
Received: from tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp ([133.199.232.103]) by imx12.toshiba.co.jp with ESMTP id uATN3hG9026077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <6tisch@ietf.org>; Wed, 30 Nov 2016 08:03:43 +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 uATN3hfO000664 for <6tisch@ietf.org>; Wed, 30 Nov 2016 08:03:43 +0900
Received: from localhost ([127.0.0.1]) by tsbmgw-mgw01 (JAMES SMTP Server 2.3.1) with SMTP ID 318 for <6tisch@ietf.org>; Wed, 30 Nov 2016 08:03:43 +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 uATN3hD4000661 for <6tisch@ietf.org>; Wed, 30 Nov 2016 08:03:43 +0900
Received: (from root@localhost) by arc11.toshiba.co.jp id uATN3gVE006537 for 6tisch@ietf.org; Wed, 30 Nov 2016 08:03:42 +0900 (JST)
Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id JAA06536; Wed, 30 Nov 2016 08:03:42 +0900
Received: from mx2.toshiba.co.jp (mx2 [133.199.192.142]) by ovp11.toshiba.co.jp with ESMTP id uATN3gwt017645 for <6tisch@ietf.org>; Wed, 30 Nov 2016 08:03:42 +0900 (JST)
Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id uATN3gAI012511; Wed, 30 Nov 2016 08:03:42 +0900 (JST)
Received: from [133.196.17.228] (nm-pptp228.isl.rdc.toshiba.co.jp [133.196.17.228]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPSA id A5AA4FF28E; Wed, 30 Nov 2016 08:03:41 +0900 (JST)
To: 6tisch@ietf.org
References: <1739694970.195512.1479755120596.JavaMail.root@vilafranca.uoc.es> <CAC9+vPiG9ZqziO8ktpuwJrc4YcRQ7Wj1e+ZciNHmZvUE9JafPw@mail.gmail.com> <CADJ9OA-BZrQHEX9yeSoj3_8p-NOoqq0g8o=6hZ_JS-53b+vNYQ@mail.gmail.com> <e431f7a2-48bb-0605-5a90-bdb0cc134322@toshiba.co.jp> <1833275349.763606.1479942137593@mail.yahoo.com> <b19ebf9e-f175-f871-3653-5c89f7201a6c@toshiba.co.jp> <417706060.2950304.1480455632701@mail.yahoo.com>
From: Yasuyuki Tanaka <yasuyuki9.tanaka@toshiba.co.jp>
Message-ID: <c1dcec38-7d34-a753-0e33-6a6e6b7582ff@toshiba.co.jp>
Date: Wed, 30 Nov 2016 00:03:38 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0
MIME-Version: 1.0
In-Reply-To: <417706060.2950304.1480455632701@mail.yahoo.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-MAIL-FROM: <yasuyuki9.tanaka@toshiba.co.jp>
X-SOURCE-IP: [172.27.153.184]
X-Spam: exempt
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/NYFK3o8UP6zM3ZONIoGfuCHTKkw>
Subject: Re: [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: Tue, 29 Nov 2016 23:03:47 -0000

Hi Qin,

Hmm, in your example, node A can resolve the inconsistency without
using the generation counter by sending CLEAR to node B after the
timeout occurs. Node A could use STATUS or STATUS+LIST before sending
CLEAR in order to confirm inconsistency if the schedule generation
inconsistency detection was disabled...

Best,
Yatch


On 2016/11/29 22:40, Qin Wang wrote:
> Hi Yasuyuki,
>
> I'm not sure I fully understand you.
>
> Let's assume node A wants to ADD cells with nodeB in 2-step
> transaction. After nodeA sends ADD Request to nodeB, the Timeout of
> nodeA is set. nodeB receives the ADD Request, adds the cells to its
> schedule and sends Response back to nodeA at same
> time. Unfortunately, nodeA does not get the Response before Timeout,
> then the schedules on two sides become inconsistent. In this case,
> only generation counter in the following message exchange can tell
> the difference. right?
>
> Thanks
> Qin

v2.23.0 | Report a Bug | By Email