Re: [6tisch] 6P and Sf0 issue: Token to identify transactions in 6P

Tero Kivinen <kivinen@iki.fi> Tue, 08 March 2016 14:50 UTC

Return-Path: <kivinen@iki.fi>
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 DD42E12D671 for <6tisch@ietfa.amsl.com>; Tue, 8 Mar 2016 06:50:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level:
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HlWT3eXPeKvQ for <6tisch@ietfa.amsl.com>; Tue, 8 Mar 2016 06:50:20 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4A9412D587 for <6tisch@ietf.org>; Tue, 8 Mar 2016 06:50:12 -0800 (PST)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id u28Eo0hH005465 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 8 Mar 2016 16:50:00 +0200 (EET)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u28EnxLW009214; Tue, 8 Mar 2016 16:49:59 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <22238.59031.234546.67779@fireball.acr.fi>
Date: Tue, 8 Mar 2016 16:49:59 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: "Pascal Thubert \(pthubert\)" <pthubert@cisco.com>
In-Reply-To: <13ebede894884c94a524356e99e18a18@XCH-RCD-001.cisco.com>
References: <CAH7SZV-2kwi7UwVCKJJL6P3sb4j-osFG5OtEj22h_RRdPKHsZA@mail.gmail.com> <CAAdgstSdMJvOhMQvFZFbMhAfAu193hcmim1b=O3REkr4RZbyUg@mail.gmail.com> <9b2cc3dcdabe42e7967b0f9e1c6d28ee@XCH-RCD-001.cisco.com> <CAAdgstRNx4oKCWoQTcVDFM=KPeZ69fH6=yx5=OyX1R62aEcS3A@mail.gmail.com> <EAC3A097-E588-454C-B532-6F028B016D33@cisco.com> <22237.33021.416706.121081@fireball.acr.fi> <13ebede894884c94a524356e99e18a18@XCH-RCD-001.cisco.com>
X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd)
X-Edit-Time: 3 min
X-Total-Time: 2 min
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/UCe-NMcWfL30CBgyJSY29rfO-Vk>
Cc: "6tisch@ietf.org" <6tisch@ietf.org>, "Prof. Diego Dujovne" <diego.dujovne@mail.udp.cl>, Tengfei Chang <tengfei.chang@gmail.com>
Subject: Re: [6tisch] 6P and Sf0 issue: Token to identify transactions 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, 08 Mar 2016 14:50:22 -0000

Pascal Thubert (pthubert) writes:
> But this is another discussion entirely. It is about the transaction
> that associates new timeslots to a bundle and why we need a
> correlator, or transaction ID. I was explaining that if the parent
> wait for the ack to allocate a slot that was negotiated, and there
> is no flow after that, then if the ack is lost the child thinks the
> slot is allocated and the parent does not. The child may start using
> it wrongly.  

Which is why you should not use ACK for anything like that, but
instead use application level messages for that kind of things. 

> The point behind this is that if the transaction does not complete,
> it must be retried from scratch with the same sequence, or it must
> time out and roll back.

Receiving or not receiving ACK should not cause transaction to
complete or not to complete, there must be some kind of application
level message to indicate that it was successful if that information
is needed in the peers.
-- 
kivinen@iki.fi