[EME] Re: transport recovery at the APP layer ?

Rémi Després <remi.despres@rd-iptech.com> Thu, 16 November 2006 10:08 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkeAq-0001up-Ud; Thu, 16 Nov 2006 05:08:48 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkeAp-0001qB-1z for eme@irtf.org; Thu, 16 Nov 2006 05:08:47 -0500
Received: from smtp9.orange.fr ([193.252.22.22] helo=smtp-msa-out09.orange.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkeAn-0000Gc-Iy for eme@irtf.org; Thu, 16 Nov 2006 05:08:47 -0500
Received: from [127.0.0.1] (APuteaux-152-1-60-44.w82-120.abo.wanadoo.fr [82.120.170.44]) by mwinf0907.orange.fr (SMTP Server) with ESMTP id 8611D1C00163; Thu, 16 Nov 2006 11:08:41 +0100 (CET)
X-ME-UUID: 20061116100841549.8611D1C00163@mwinf0907.orange.fr
Message-ID: <455C38AC.1090306@rd-iptech.com>
Date: Thu, 16 Nov 2006 11:08:44 +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> <4559FC5C.1090803@rd-iptech.com> <455A14AA.6010007@isi.edu> <455B3DDC.2060903@rd-iptech.com> <455B4094.1080400@isi.edu> <455B472A.9000303@wanadoo.fr> <455B48BD.5050201@isi.edu> <455B56C9.7080307@rd-iptech.com> <455B6358.4000703@isi.edu>
In-Reply-To: <455B6358.4000703@isi.edu>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: a8a20a483a84f747e56475e290ee868e
Cc: eme@irtf.org
Subject: [EME] Re: transport recovery at the APP layer ?
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="===============0391633946=="
Errors-To: eme-bounces@irtf.org

Joe Touch wrote:
> Rémi Després wrote:
>   
>> ... A transport layer acknowledgement (TCP ACK) doesn't mean that the
>> destination application has seen the data.
>>     
> It never did. But receiving an ACK to a FIN does.
>   
However regrettable it may be :'( , it's no true in all cases either.
 If a FIN is received by a TCP stack, it MUST be acked within 0.5 s to 
conform to RFC1122  -  4.2.3.2.
 It MAY be acked long before that. .
 If the application hasn't absorbed all buffered data before the ACK is 
sent, remaining data MAY never be received by the app.

 Since changing all TCP stacks would not be realistic, this fact of life 
has to be faced.
>> I guess what is meant by "E2E" should be clarified: transport stack 
>> to transport stack, or app to app?
>>  TCP provides only the former.
>>  What TCP does guarantee is that all received data have been sent, in
>> the same order and with no intermediate omission.
>>     
> when the connection closes, the app HAS received the data.
>   
 See above.

> ... if the TCP
> connection closes it knows that the other application has received the
> data. That's no longer true in spliced connections.
>   
It's NEVER true (see above).
Making clearer in IETF what the apps can expect from the TCP transport 
service would IMO be useful.

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