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