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

Qin Wang <qinwang6top@yahoo.com> Tue, 08 March 2016 21:10 UTC

Return-Path: <qinwang6top@yahoo.com>
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 2DA0712DAF1 for <6tisch@ietfa.amsl.com>; Tue, 8 Mar 2016 13:10:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level:
X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com
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 heJVJ65nDgli for <6tisch@ietfa.amsl.com>; Tue, 8 Mar 2016 13:10:07 -0800 (PST)
Received: from nm1-vm1.bullet.mail.bf1.yahoo.com (nm1-vm1.bullet.mail.bf1.yahoo.com [98.139.213.163]) (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 5614212DAF0 for <6tisch@ietf.org>; Tue, 8 Mar 2016 13:10:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1457471406; bh=7JQro0tyIVJGaeRpJ4oXs7P3guxAh6ebLv1W4KPSRIE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=WoX+aFK8U4XaZ1gLq8oCAiVg/LSkhWbb872wxBsFOSGXcSVRz6U/6/71m/dLC/Y9Ljjr7185XycRtsl45gql/0Zt/wVmIep/ExlhJretrcEenSurJlpuXQdivlYRVMS8JKcWTmgzh19MkmU2U/bGebylqjJWSpsRKaJXmJwT3sDQuy+cQHlOXPIoCyXa/kopVHElGtJK5elSbdJ9ibKugTAEA23NpV4G18XL20+pIeukSukjIFoA2Pc5qA/fY+IO7Qeyv5BEQf3TDEwTY0d7t/YYDKYEQLppEWFjXrHSQxu+gH7eL8Opgs55NrEzpltBbziSIIb5bzgC7hO0SNbHJw==
Received: from [98.139.215.143] by nm1.bullet.mail.bf1.yahoo.com with NNFMP; 08 Mar 2016 21:10:06 -0000
Received: from [98.139.212.240] by tm14.bullet.mail.bf1.yahoo.com with NNFMP; 08 Mar 2016 21:10:06 -0000
Received: from [127.0.0.1] by omp1049.mail.bf1.yahoo.com with NNFMP; 08 Mar 2016 21:10:06 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 319487.23284.bm@omp1049.mail.bf1.yahoo.com
X-YMail-OSG: DiICrfcVM1n4ehpLac0WAyYYE1Jb5Jzlamc_rSBfVan9ljVOkqtflt0KmkE1FMi qXTvyTPnKW6qS89qHdt8qP4LbOdHvGmFRFPw9CukukoWvS8zc5SSgyrX8PYP2sbfBAcj3howbGST PRY7F3_fx51QAH52p1ggHF6IwBMqr8j39uwfZdQapNfwZmTc66aMqdXzJs6v6e7cALbiWB1Cqpnc PaWDznnk.KMQlnWivzgPd_bP7sfOD1Jm6j67P_l4a1qdOjBTg.eMrrHtAZMHsgi2_rM7bmfics5Y .WKs2LVZ_gKBkQA7vrj3WgMRZP0t8G77vYQs.yDbsnYIV6YbpzQCKERF8yBHZZTw3.FrCuU9_prR sh38UbSb2XEpA0QdJ0quLH4Z9KZq78hvCq4YVHIsLUD_X_02UK47eZGiV_lv_r9OMB5cbuXp3EIZ BTbob1L1z6Ty9e2YAUAjK943fCzBuNlkK1s5hwbOSvpfe2ygh.ni2290u
Received: by 76.13.27.132; Tue, 08 Mar 2016 21:10:05 +0000
Date: Tue, 8 Mar 2016 21:08:52 +0000 (UTC)
From: Qin Wang <qinwang6top@yahoo.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, Tero Kivinen <kivinen@iki.fi>
Message-ID: <847953799.6165746.1457471332301.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <e5d44e727c8746fab93d6b8b5b3b9401@XCH-RCD-001.cisco.com>
References: <e5d44e727c8746fab93d6b8b5b3b9401@XCH-RCD-001.cisco.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_6165745_1493282097.1457471332291"
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/V7Oj5nxJwSNO6o_dE5_goejbqkc>
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
Reply-To: Qin Wang <qinwang6top@yahoo.com>
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 21:10:09 -0000

Hi all,
I'm not convinced that token is necessary yet. From the discussion in the last WG meeting, we have agreed that the Token is used in the 6P message exchange between neighbors. Based on the agreement, let's consider the two following scenarios.
(1) nodeA send ADD_Request(token=1) to nodeB, and not receive Response from nodeB before Timeout. Then, nodeA send ADD_Request(token=2) to nodeB, and receive Response(token=2) from nodeB. 
(2) nodeA send ADD_Request to nodeB, and not receive Response from nodeB before Timeout. Then nodeA send ADD_Request to nodeB again, and receive Response from nodeB.

The question is if it is possible for nodeA to receive Response(token=1) from nodeB later in (1). Since nodeA will send the second ADD_Request after Timeout, I don't think it could happen. If I'm correct, I think the two sequences function similarly. Thus, I wonder if it is necessary to have the Token
What do you think?
ThanksQin
 

    On Tuesday, March 8, 2016 10:10 AM, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
 

 Oh yes, Tero,

we agree on the bottom line and on your points.

Cheers,

Pascal

> -----Original Message-----
> From: Tero Kivinen [mailto:kivinen@iki.fi]
> Sent: mardi 8 mars 2016 15:50
> To: Pascal Thubert (pthubert) <pthubert@cisco.com>
> Cc: Tengfei Chang <tengfei.chang@gmail.com>om>; 6tisch@ietf.org; Prof. Diego
> Dujovne <diego.dujovne@mail.udp.cl>
> Subject: RE: [6tisch] 6P and Sf0 issue: Token to identify transactions in 6P
> 
> 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

_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch