IETF Logo Mail Archive

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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Tue, 08 March 2016 07:52 UTC

Return-Path: <pthubert@cisco.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 C40C012D51D for <6tisch@ietfa.amsl.com>; Mon, 7 Mar 2016 23:52:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 1MtkxJO3GiB6 for <6tisch@ietfa.amsl.com>; Mon, 7 Mar 2016 23:52:15 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 585D012D50F for <6tisch@ietf.org>; Mon, 7 Mar 2016 23:52:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1780; q=dns/txt; s=iport; t=1457423535; x=1458633135; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2cjDTum2jxEik1X13VW7lI/+7d5InCTjZMnPRvf0Rfo=; b=BH5fyIAoPVR2SRUBljggHY18/dXxAjxTn0axkjQQUQgfPsUCTA9DPNFk 1zOTob9hiWtu0ggyBn/J8MKojwn/9ziIW/Cvb0ZNjU5JVttyov7yvPEFu snx+FfFyDrq8EDUdoZX78te4KANjZZAgC1zOf7Z1w3iMGv89U3IzJfKQX g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D3AQD9ft5W/4oNJK1SCoM6gT8GukIBDYFphg8CgTU4FAEBAQEBAQFkJ4RBAQEBBDo/DAQCAQgRBAEBHwkHIREUCQgCBA4FCIgHAxK5cw2ERAEBAQEBAQEBAQEBAQEBAQEBAQEBARWGF4Q9gj2BUwsBAYRXBZcqAYt4gW6PAYcNh0gBHgEBQoNkaohNNH4BAQE
X-IronPort-AV: E=Sophos;i="5.22,555,1449532800"; d="scan'208";a="78767047"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Mar 2016 07:30:05 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u287U589032140 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 8 Mar 2016 07:30:05 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 8 Mar 2016 01:30:05 -0600
Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.009; Tue, 8 Mar 2016 01:30:05 -0600
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Tero Kivinen <kivinen@iki.fi>
Thread-Topic: [6tisch] 6P and Sf0 issue: Token to identify transactions in 6P
Thread-Index: AQHRdharXjQKnV8qLUijcPjy30pd9p9JRqgvgAUbB4CAACA90A==
Date: Tue, 08 Mar 2016 07:30:04 +0000
Deferred-Delivery: Tue, 8 Mar 2016 07:30:00 +0000
Message-ID: <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>
In-Reply-To: <22237.33021.416706.121081@fireball.acr.fi>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.61.247.132]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/iruG5Zw5MuKdT441lP-IIOkX-xI>
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 07:52:16 -0000

Sure, Tero; 


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. 

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.

Cheers,

Pascal


> -----Original Message-----
> From: Tero Kivinen [mailto:kivinen@iki.fi]
> Sent: lundi 7 mars 2016 14:24
> To: Pascal Thubert (pthubert) <pthubert@cisco.com>
> Cc: Tengfei Chang <tengfei.chang@gmail.com>; 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 if the ack is sent and not received then the parent does not
> > allocate the cells and the child uses them...
> 
> And ACK only tells you that the frame was received, it does NOT mean that
> the frame was processed. I.e. the recipient end might send an ACK, and then
> send the frame to the upper layer, but if there is not enough buffer space
> available there, it might drop it before it actually reaches the upper layer.
> 
> So do not use ACK for anything else than indication that there is no need to
> retransmit this frame anymore as other end already received it (altough it
> might have dropped it after that, but retransmissions does not help with
> that).
> --
> kivinen@iki.fi

v2.23.0 | Report a Bug | By Email