[EME] Re: transport recovery at the APP layer ?
Joe Touch <touch@ISI.EDU> Thu, 16 November 2006 22:03 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkpKH-0006AM-Ts; Thu, 16 Nov 2006 17:03:17 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkpKH-0006AH-5O for eme@irtf.org; Thu, 16 Nov 2006 17:03:17 -0500
Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkpKF-0007LA-Pn for eme@irtf.org; Thu, 16 Nov 2006 17:03:17 -0500
Received: from [127.0.0.1] (88.sub-75-215-225.myvzw.com [75.215.225.88]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id kAGM2vNS025388; Thu, 16 Nov 2006 14:03:03 -0800 (PST)
Message-ID: <455CDFFF.8000500@isi.edu>
Date: Thu, 16 Nov 2006 14:02:39 -0800
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: Rémi Després <remi.despres@rd-iptech.com>
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> <455C38AC.1090306@rd-iptech.com>
In-Reply-To: <455C38AC.1090306@rd-iptech.com>
X-Enigmail-Version: 0.94.0.0
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
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="===============1914219097=="
Errors-To: eme-bounces@irtf.org
Rémi Després wrote: > 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. An ACK is generated - but if there is outstanding data, it will not ACK the seq num of the FIN. The ACK _of the FIN_ means that all subsequent data has been received correctly (as determined by the TCP checksum, which is not strong) by the TCP at the other end. As per below, there are other steps I should have noted to ensure that the app has _read_ the data. As you and Paul observe, that may be semantically insufficient - even if the app reads the data, if you want to know if the app acted on it (e.g., a bank transaction), knowing that the item was delivered or even received by the app is insufficient. > 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. When your side registers a CLOSED state, it means that the other side has issued a CLOSE, which means the app has received all the data. It may not have acted on it (which would require the app to ACK), but the app has it. >> ... 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). I've tried to show how this is ensured above. Please indicate where that is incorrect. I admit I'm not absolutely sure of the mechanistic details, but a successful close means the application has _read_ the data you sent (which again may be insufficient).
_______________________________________________ EME mailing list EME@irtf.org https://www1.ietf.org/mailman/listinfo/eme
- [EME] The virtual circuit trap mentioned in the E… Rémi Després
- Re: [Fwd: [EME] The virtual circuit trap mentione… Rémi Després
- RE: [EME] The virtual circuit trap mentioned in t… Paul Francis
- Re: [EME] The virtual circuit trap mentioned in t… Rémi Després
- Re: [EME] The virtual circuit trap mentioned in t… Joe Touch
- Re: [EME] The virtual circuit trap mentioned in t… Scott W Brim
- Re: [EME] The virtual circuit trap mentioned in t… Rémi Després
- RE: [EME] The virtual circuit trap mentioned in t… Paul Francis
- Re: [EME] The virtual circuit trap mentioned in t… Rémi Després
- Re: [EME] The virtual circuit trap mentioned in t… Rémi Després
- Re: [EME] The virtual circuit trap mentioned in t… Rémi Després
- Re: [EME] The virtual circuit trap mentioned in t… Joe Touch
- [EME] transport recovery at the APP layer ? Rémi Després
- [EME] Re: transport recovery at the APP layer ? Joe Touch
- RE: [EME] Re: transport recovery at the APP layer… Henry Sinnreich
- Re: [EME] Re: transport recovery at the APP layer… Joe Touch
- [EME] Re: transport recovery at the APP layer ? Rémi Després
- RE: [EME] Re: transport recovery at the APP layer… Paul Francis
- Re: [EME] Re: transport recovery at the APP layer… Rémi Després
- RE: [EME] Re: transport recovery at the APP layer… Paul Francis
- [EME] Re: transport recovery at the APP layer ? Joe Touch
- Re: [EME] Re: transport recovery at the APP layer… Joe Touch
- Re: [EME] Re: transport recovery at the APP layer… Yangwoo Ko
- [EME] Re: transport recovery at the APP layer ? Rémi Després
- Re: [EME] Re: transport recovery at the APP layer… Saikat Guha
- Re: [EME] Re: transport recovery at the APP layer… Joe Touch
- Re: [EME] Re: transport recovery at the APP layer… Mark Baker
- Re: [EME] Re: transport recovery at the APP layer… Joe Touch
- Re: [EME] Re: transport recovery at the APP layer… Mark Baker
- Re: [EME] Re: transport recovery at the APP layer… Joe Touch
- Re: [EME] Re: transport recovery at the APP layer… Mark Baker
- Re: [EME] Re: transport recovery at the APP layer… Saikat Guha
- Re: [EME] Re: transport recovery at the APP layer… Joe Touch
- [EME] Relationship betwen Rémi Després
- [EME] TCP close semantics Rémi Després
- [EME] Re: TCP close semantics Joe Touch
- [EME] Re: TCP close semantics Rémi Després
- Re: [EME] Relationship betwen Lars Eggert