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

"Pascal Thubert (pthubert)" <> Wed, 09 March 2016 17:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3CDB412D7D2 for <>; Wed, 9 Mar 2016 09:28:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Status: No, score=-14.521 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_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TkJsd9ddKYQH for <>; Wed, 9 Mar 2016 09:28:24 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5555A12D7F2 for <>; Wed, 9 Mar 2016 09:27:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=35118; q=dns/txt; s=iport; t=1457544454; x=1458754054; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=LHV7BhQao0GjHDA+Y763rT9iIsqE01LH8A6EfjlogWc=; b=hb30G5o1fE20+GuddXI1iwDdESEZ/vltifKDuU7Wopy+4lvVxy1fZhtB a1cHHk3mZCrurPI9/hL1ykAJTz2a8SdLBWN+alLKlabiwlLLNgctleBnC fMwnHf3TP19SE49aitRdzSuHARB6KzmkwN5C/z5h0K/uWGXMsBodh7j1I I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.24,311,1454976000"; d="scan'208,217";a="245622058"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Mar 2016 17:27:22 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id u29HRLnX021941 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 9 Mar 2016 17:27:21 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 9 Mar 2016 11:27:21 -0600
Received: from ([]) by ([]) with mapi id 15.00.1104.009; Wed, 9 Mar 2016 11:27:21 -0600
From: "Pascal Thubert (pthubert)" <>
To: Qin Wang <>
Thread-Topic: [6tisch] 6P and Sf0 issue: Token to identify transactions in 6P
Thread-Index: AQHRehsGXjQKnV8qLUijcPjy30pd9p9RXDQg
Date: Wed, 9 Mar 2016 17:27:16 +0000
Deferred-Delivery: Wed, 9 Mar 2016 17:26:45 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_9d40e7f8ac2c486cb338deb6eeeb54f2XCHRCD001ciscocom_"
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, "Prof. Diego Dujovne" <>, Tengfei Chang <>, Tero Kivinen <>
Subject: Re: [6tisch] 6P and Sf0 issue: Token to identify transactions in 6P
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" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 09 Mar 2016 17:28:26 -0000

Never seen a stupid question from you, Qin : )

I agree with you actually.

By “As it goes, it also enables to avoid the serialization of requests but I agree that is a non goal today.” I meant that the child will probably serialize hos requests, iow wait for one completion before it asks for more. But with the token / seqnum we are open if one day we decide otherwise…

Take care,


From: Qin Wang []
Sent: mercredi 9 mars 2016 16:48
To: Pascal Thubert (pthubert) <>
Cc: Tero Kivinen <>fi>;; Prof. Diego Dujovne <>cl>; Tengfei Chang <>
Subject: Re: [6tisch] 6P and Sf0 issue: Token to identify transactions in 6P


I can see your point. Token is useful for Parent to distinguish Retry from new Request by the Child.

But, I have a stupid question: is it reasonable to allow the Child to ask more cells before it gets Response to what it already asked?


On Wednesday, March 9, 2016 2:13 AM, Pascal Thubert (pthubert) <<>> wrote:

Hello Qin:

Token 1 needs to be the same as token 2 when it is a retry. That's the whole point.

In your second case, say this is a child asking for a cell:

- If this is a time out because the response from the parent was lost, the parent should respond with the same cell as in the lost message.

- But if the child got the response and still needs more bandwidth, then the parent needs to allocate a second cell.

How does the parent know?

The main point of the sequence number is to be able to correlate the retry.

As it goes, it also enables to avoid the serialization of requests but I agree that is a non goal today.



Le 8 mars 2016 à 22:10, Qin Wang <<>> a écrit :
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?


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

Oh yes, Tero,

we agree on the bottom line and on your points.



> -----Original Message-----
> From: Tero Kivinen [<>]
> Sent: mardi 8 mars 2016 15:50
> To: Pascal Thubert (pthubert) <<>>
> Cc: Tengfei Chang <<>>;<>; Prof. Diego
> Dujovne <<>>
> 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.
> --

6tisch mailing list<>