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

Xavi Vilajosana Guillen <xvilajosana@uoc.edu> Mon, 21 November 2016 20:57 UTC

Return-Path: <xvilajosana@uoc.edu>
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 36F60129BC2 for <6tisch@ietfa.amsl.com>; Mon, 21 Nov 2016 12:57:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uoc.edu
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 FGnoJC14rOpq for <6tisch@ietfa.amsl.com>; Mon, 21 Nov 2016 12:57:00 -0800 (PST)
Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 D73AB129BB4 for <6tisch@ietf.org>; Mon, 21 Nov 2016 12:56:59 -0800 (PST)
Received: by mail-it0-x232.google.com with SMTP id j191so1971677ita.1 for <6tisch@ietf.org>; Mon, 21 Nov 2016 12:56:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoc.edu; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=H3mk626Oe9+8UHtKqIyszUqSm756YrY41Zmk3ddMGGM=; b=SpYNbWJ35ZvH1loUMrEoCozDqzWht2m+ztZajg+NeHqLfRSbwT59xZ8lCBVyrnfmml Wm/7pTZJf2/7uoJ4cMqoqEl/FDCzJqQc/x65e9DnDWj6VOoJpUph6RQfGp5wQpYiGkUR a3oCVrFp/6ANG41Cs0UZ63iFmmi+qyn3aZ8Sk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=H3mk626Oe9+8UHtKqIyszUqSm756YrY41Zmk3ddMGGM=; b=FxhMo3zEKwvin3gUQbJDRKkAs5UrdcXxsFmAkRhUhf+fChBQ5OS80+zvCIrx0JryM3 UIzFZuwMsreIoq89oChJoOKVa84bMUhgfBorHS9idf28WGej3Re+ZK7DkAnzEBidoZjf NL7Lfp+M1+Cb/mRHClBuWpBb/EBRHNVzD0hekAYiVwdQi60muPEJGgaQh28vIqES27oB tZwzMFvj+4PKUtKISdccvklaWdvUVwSh9npWN1064irKhwxy0fnDXmVuhynzVRuICpM0 bhdy5Wn8EGbMcIK44+KsjiG8yjGuGI/44xiyJvT5KsFvDmRlYnnXhCes5Ive7adRa3Fa jibA==
X-Gm-Message-State: AKaTC02DfCzgKFcmpfGnICCuKsW5eqOUj9/RL1DBJflNbccynLt3g6gmsgcXgmq49B5a4re02onCmbcZANQf9/48
X-Received: by 10.36.148.84 with SMTP id j81mr11806556ite.35.1479761818892; Mon, 21 Nov 2016 12:56:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.144.137 with HTTP; Mon, 21 Nov 2016 12:56:58 -0800 (PST)
In-Reply-To: <1739694970.195512.1479755120596.JavaMail.root@vilafranca.uoc.es>
References: <1739694970.195512.1479755120596.JavaMail.root@vilafranca.uoc.es>
From: Xavi Vilajosana Guillen <xvilajosana@uoc.edu>
Date: Mon, 21 Nov 2016 21:56:58 +0100
Message-ID: <CAC9+vPiG9ZqziO8ktpuwJrc4YcRQ7Wj1e+ZciNHmZvUE9JafPw@mail.gmail.com>
To: Yasuyuki Tanaka <yasuyuki9.tanaka@toshiba.co.jp>
Content-Type: multipart/alternative; boundary="94eb2c0ef0e291580c0541d5e5e1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/NUabzeOwp7ieeTZ0LNUnYECgp38>
Cc: tisch <6tisch@ietf.org>
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: Mon, 21 Nov 2016 20:57:02 -0000

Hi Yatch,
my 2 cents inline


> 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.
>
> We decided at the IETF meeting last week to reduce the number of
generation counters from 2 to 1 (2bits field) as now 6P commands can add
different types of cells so we need to account for transactions now. I
state that here to outline that the proposed mechanism is very simple. At
every transaction we increment a generation counter. It cannot happen that
the two sides of the transaction have inconsistent counters. If this
happens, then the schedules are reset. I agree that this is detected after
the error has occurred.


> 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.
>

it adds complexity and more messages over the air, which are costly and can
also fail (e.g external interference). What happens if we loose the 6P
NACK? How the NACK sender know that the NACK has been received?

>
> What others think...?
>

I like to answer with another question. What causes less overhead, 2 bits
per each 6P command or 1 or 2 extra packets per transaction (assuming only
write/state modification transactions). For me the former is way simpler.

regards,
X



>
> Best,
> Yatch
>
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>



-- 
Dr. Xavier Vilajosana Guillén­
Research Professor
Wireless Networks Research Group
Internet Interdisciplinary Institute (IN3)
Universitat Oberta de Catalunya­

+34 646 633 681| xvilajosana@uoc.edu­ | Skype­: xvilajosana
http://xvilajosana.org
http://wine.rdi.uoc.edu/

Parc Mediterrani de la Tecnologia
Av. Carl Friedrich Gauss, 5. Edifici B3
08860 Castelldefels (Barcelona)



­