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

TCP has a crappy checksum and you never know when an implementation might
have some screwy bug.  

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...

PF

________________________________

From: Rémi Després [mailto:remi.despres@wanadoo.fr] 
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. 

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. 
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: 

	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!  

	PF

________________________________

	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.

	 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