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

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

________________________________

From: Rémi Després [mailto:remi.despres@rd-iptech.com] 
Sent: Thursday, November 16, 2006 5:09 AM
To: Joe Touch
Cc: eme@irtf.org
Subject: [EME] Re: transport recovery at the APP layer ?

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