IETF Logo Mail Archive

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

Tero Kivinen <kivinen@iki.fi> Mon, 07 March 2016 13:24 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1094C1B40CB for <6tisch@ietfa.amsl.com>; Mon, 7 Mar 2016 05:24:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.778
X-Spam-Level:
X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_NEUTRAL=0.779] autolearn=no
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 VWe5L1Vw4HHo for <6tisch@ietfa.amsl.com>; Mon, 7 Mar 2016 05:24:26 -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 109681B40C9 for <6tisch@ietf.org>; Mon, 7 Mar 2016 05:24:25 -0800 (PST)
Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.14.8) with ESMTPS id u27DOEFB000742 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 7 Mar 2016 15:24:14 +0200 (EET)
Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u27DODM0020807; Mon, 7 Mar 2016 15:24:13 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <22237.33021.416706.121081@fireball.acr.fi>
Date: Mon, 07 Mar 2016 15:24:13 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
In-Reply-To: <EAC3A097-E588-454C-B532-6F028B016D33@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>
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/cwByZUqlXX8kMa4mh-_PhsQ7zO0>
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.15
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, 07 Mar 2016 13:24:28 -0000

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.28.0 | Report a Bug | By Email | System Status