Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkjyu-0000vl-Np; Thu, 16 Nov 2006 11:20:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkjyt-0000vf-Qt for eme@irtf.org; Thu, 16 Nov 2006 11:20:51 -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 1Gkjys-0001BZ-Cp for eme@irtf.org; Thu, 16 Nov 2006 11:20:51 -0500 Received: from EXCHANGE2.cs.cornell.edu ([128.84.96.44]) by exchfe2.cs.cornell.edu with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 11:20:50 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [EME] Re: transport recovery at the APP layer ? X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 16 Nov 2006 11:20:48 -0500 Message-ID: In-Reply-To: <455C7FB5.80206@wanadoo.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [EME] Re: transport recovery at the APP layer ? Thread-Index: AccJmpabpYRCsCncSw+Z9NHJRd67zAAAE/ZA From: "Paul Francis" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-OriginalArrivalTime: 16 Nov 2006 16:20:50.0174 (UTC) FILETIME=[2E1F69E0:01C7099B] X-Spam-Score: 0.1 (/) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 Cc: eme@irtf.org, Joe Touch X-BeenThere: eme@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: end-middle-end research group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0071983842==" Errors-To: eme-bounces@irtf.org This is a multi-part message in MIME format. --===============0071983842== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7099B.2DBC0551" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7099B.2DBC0551 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable TCP has a crappy checksum and you never know when an implementation = might have some screwy bug. =20 =20 If I'm transmitting some random HTML page, sure I'll rely on TCP to = preserve bytes for me. If I'm transmitting a financial transaction, no way in = hell am I going to rely on TCP... =20 PF ________________________________ From: R=E9mi Despr=E9s [mailto:remi.despres@wanadoo.fr]=20 Sent: Thursday, November 16, 2006 10:12 AM To: Paul Francis Cc: Joe Touch; eme@irtf.org Subject: Re: [EME] Re: transport recovery at the APP layer ? Not relying on sequence preservation by TCP would be IMO going too far. Credible mechanisms are present in TCP to ensure it. On the other hand, TCP hasn't credible mechanisms guarantee delivery to = the destination application for data that are acknowledged by the = destination TCP stack, even at the end of a connection.=20 The E2E guarantee that TCP provides, application-to-application, is data integrity, with neither permutation nor duplication nor deletion, from = the first data transmitted to the last data received.=20 Aat the end of a connection, the destination application can know, from = the transport layer, that it has received all transmitted data , but the = source application cannot be sure, from the transport layer, that all the last = data it has sent have been received. RD Paul Francis wrote:=20 I have long held the view that the application should assume very little from TCP. If the app needs an ack of some sort, then the app = should provide it. If the app really really cares about in-order bytes, it = should do its own checksums. To do anything else is to ignore the end-to-end principle. If nothing else, writing apps this way saves you from having = to understand the minute details of TCP implementations! =20 =20 PF ________________________________ R=E9mi Despr=E9s wrote: =09 =09 Joe Touch wrote:=20 R=E9mi Despr=E9s wrote: =20 ... A transport layer acknowledgement (TCP ACK) doesn't mean that the destination application has seen the data. =20 It never did. But receiving an ACK to a FIN does. =20 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. =09 Since changing all TCP stacks would not be realistic, this fact of life has to be faced. =09 I guess what is meant by "E2E" should be clarified: transport stack to transport stack, or app to app? =09 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. =20 when the connection closes, the app HAS received the data. =20 See above.=20 =09 =09 ... if the TCP connection closes it knows that the other application has received the data. That's no longer true in spliced connections. =20 It's NEVER true (see above). Making clearer in IETF what the apps can expect from the TCP transport service would IMO be useful. =09 RD =09 ------_=_NextPart_001_01C7099B.2DBC0551 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
TCP has a crappy checksum and you never know = when an=20 implementation might have some screwy bug. 
 
If I'm transmitting some random HTML page, sure = I'll rely=20 on TCP to preserve bytes for me.  If I'm transmitting a financial=20 transaction, no way in hell am I going to rely on = TCP...
 
PF

From: R=E9mi Despr=E9s=20 [mailto:remi.despres@wanadoo.fr]
Sent: Thursday, November 16, = 2006=20 10:12 AM
To: Paul Francis
Cc: Joe Touch;=20 eme@irtf.org
Subject: Re: [EME] Re: transport recovery at the = APP=20 layer ?

Not relying on sequence preservation by TCP would be IMO = going too=20 far.
Credible mechanisms are present in TCP to ensure it.
On the = other=20 hand, TCP hasn't credible mechanisms guarantee delivery to the = destination=20 application for data that are acknowledged by the destination TCP stack, = even at=20 the end of a connection.

The E2E guarantee that TCP = provides,=20 application-to-application, is data integrity, with = neither=20 permutation nor duplication nor deletion,  from the first data=20 transmitted to the last data  received.
Aat = the end=20 of a connection, the destination application can know, from the = transport layer,=20 that it has received all transmitted data , but the source application = cannot be=20 sure, from the transport layer, that all the last data it has sent have = been=20 received.

RD

Paul Francis wrote:=20
I have long held the view that the = application should=20 assume very little from TCP.  If the app needs an ack of some = sort, then=20 the app should provide it.  If the app really really cares about = in-order=20 bytes, it should do its own checksums.   To do anything=20 else is to ignore the end-to-end principle.  If nothing else, = writing=20 apps this way saves you from having to understand the minute details = of TCP=20 implementations! 
 
PF

R=E9mi Despr=E9s = wrote:

Joe=20 Touch wrote:=20 
R=E9mi Despr=E9s 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=20 either.
 If a FIN is received by a TCP stack, it MUST be acked = within=20 0.5 s to conform to RFC1122  -  4.2.3.2.
 It MAY be = acked=20 long before that. .
 If the application hasn't absorbed all = buffered=20 data before the ACK is sent, remaining data MAY never be received by = the=20 app.

 Since changing all TCP stacks would not be = realistic, this=20 fact of life has to be faced.
I guess what is meant by "E2E" should be=20 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=20 what the apps can expect from the TCP transport service would IMO be=20 useful.

RD
------_=_NextPart_001_01C7099B.2DBC0551-- --===============0071983842== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ EME mailing list EME@irtf.org https://www1.ietf.org/mailman/listinfo/eme --===============0071983842==--