IETF Logo Mail Archive

[EME] TCP close semantics

Rémi Després <remi.despres@rd-iptech.com> Sat, 18 November 2006 11:15 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlOA7-0005ID-HK; Sat, 18 Nov 2006 06:15:07 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlOA5-0005I2-VM for eme@irtf.org; Sat, 18 Nov 2006 06:15:05 -0500
Received: from smtp20.orange.fr ([80.12.242.27] helo=smtp-msa-out20.orange.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlOA3-000104-W3 for eme@irtf.org; Sat, 18 Nov 2006 06:15:05 -0500
Received: from [127.0.0.1] (APuteaux-152-1-45-166.w82-120.abo.wanadoo.fr [82.120.219.166]) by mwinf2012.orange.fr (SMTP Server) with ESMTP id 5F2931C000A7; Sat, 18 Nov 2006 12:15:02 +0100 (CET)
X-ME-UUID: 20061118111502389.5F2931C000A7@mwinf2012.orange.fr
Message-ID: <455EEB37.1020504@rd-iptech.com>
Date: Sat, 18 Nov 2006 12:15:03 +0100
From: Rémi Després <remi.despres@rd-iptech.com>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: Joe Touch <touch@ISI.EDU>
References: <E6F7A586E0A3F94D921755964F6BE00662575C@EXCHANGE2.cs.cornell.edu> <455B48BD.5050201@isi.edu> <455B56C9.7080307@rd-iptech.com> <455B6358.4000703@isi.edu> <455C38AC.1090306@rd-iptech.com> <455CDFFF.8000500@isi.edu> <455D9BD5.7000900@wanadoo.fr> <1163775763.8736.114.camel@sioux.systems.cs.cornell.edu> <c70bc85d0611170827t36b9443fm2b5581721142b769@mail.gmail.com> <455DE7D1.6030805@isi.edu> <c70bc85d0611170940s26d906aak4241fe728be5590d@mail.gmail.com> <455DFF44.9060208@isi.edu>
In-Reply-To: <455DFF44.9060208@isi.edu>
X-Spam-Score: 0.5 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Cc: eme <eme@irtf.org>
Subject: [EME] TCP close semantics
X-BeenThere: eme@irtf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: end-middle-end research group <eme.irtf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/eme>, <mailto:eme-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/eme>
List-Post: <mailto:eme@irtf.org>
List-Help: <mailto:eme-request@irtf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/eme>, <mailto:eme-request@irtf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0599220866=="
Errors-To: eme-bounces@irtf.org

Joe Touch wrote :
> ...
> Doing that means keeping TCP semantics, which means that a FIN/ACK means
> what a FIN/ACK means - that the -endpoint- got the data, not that a
> middlebox somewhere else did.
>   
Sorry to insist that AFAIK this statement is inaccurate, at least if, as 
I understand it, the endpoint refers to the application that uses TCP.

YES, when an application receives a FIN, it _does mean_ that it has 
received all its incoming data have been received.
But NO, after an application has sent a FIN, reception of the ACK for 
that FIN by its TCP stack _doesn't mean_ that all its outgoing data have 
been received  by the far end application.
AFAIK _the application that sends a FIN is not even informed that the 
FIN has been acknowledged _ (no provision for this at its socket API 
with its TCP stack). .

It would be nice if some recognized TCP stack specialist would  help 
reaching a common understanding on this point.

RD

_______________________________________________
EME mailing list
EME@irtf.org
https://www1.ietf.org/mailman/listinfo/eme

v2.23.0 | Report a Bug | By Email