IETF Logo Mail Archive

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

Saikat Guha <saikat@cs.cornell.edu> Fri, 17 November 2006 15:03 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl5F8-00087j-Ht; Fri, 17 Nov 2006 10:03:02 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl5F6-00086e-Uo for eme@irtf.org; Fri, 17 Nov 2006 10:03:00 -0500
Received: from exchfenlb-2.cs.cornell.edu ([128.84.97.34] helo=exchfe2.cs.cornell.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl5F4-0007cT-Lz for eme@irtf.org; Fri, 17 Nov 2006 10:03:00 -0500
Received: from exchfe2.cs.cornell.edu ([128.84.97.28]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Nov 2006 10:02:53 -0500
Received: from [128.84.227.36] ([128.84.227.36]) by exchfe2.cs.cornell.edu over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Nov 2006 10:02:44 -0500
Subject: Re: [EME] Re: transport recovery at the APP layer ?
From: Saikat Guha <saikat@cs.cornell.edu>
To: Rémi Després <remi.despres@wanadoo.fr>
In-Reply-To: <455D9BD5.7000900@wanadoo.fr>
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> <455CDFFF.8000500@isi.edu> <455D9BD5.7000900@wanadoo.fr>
Date: Fri, 17 Nov 2006 10:02:43 -0500
Message-Id: <1163775763.8736.114.camel@sioux.systems.cs.cornell.edu>
Mime-Version: 1.0
X-Mailer: Evolution 2.9.2 (2.9.2-2.fc7)
X-OriginalArrivalTime: 17 Nov 2006 15:02:44.0261 (UTC) FILETIME=[6F839550:01C70A59]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69
Cc: eme <eme@irtf.org>
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="===============0532771139=="
Errors-To: eme-bounces@irtf.org

On Fri, 2006-11-17 at 12:24 +0100, Rémi Després wrote:
> Whether a connection close has to guarantee, or not, delivery to the 
> destination application of the last data sent to it, is IMU a 
> significant E2E aspect of TCP.

TCP can only provide guarantees about TCP, and not the application above
it. Regarding connection close, consider two options:

Option #1: 
- Remote TCP closes connection after queuing packets for the app.
  Perhaps even after the app copies it into a temporary buffer.
- Result: Local app does not learn whether or not the remote app
  successfully processed the data.

Option #2:
- Remote *app* sends DONE after processing the last byte of the message.
- Local app is assured that the remote app succeeded


So my question: 
- IF you could pick the semantics, which one would you rather have?
- If #2, then does having or not having #1 matter?

-- 
Saikat

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

v2.23.0 | Report a Bug | By Email