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

[Joe Touch <[e-mail]>]

I'm with Paul on the integrity stuff; Craig Partridge had a nice Sigcomm
1995 paper showing how TCP checksums could miss errors in certain cases.

However, the TCP closing tells you a few things - it does tell you that,
**as far as TCP knew**, the data was delivered inorder and reliably (to
the extent that its checksum can detect errors) to the application above
TCP, which may not be what you intended.

Joe

Rémi Després wrote:
> 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

-- 
----------------------------------------
Joe Touch
Sr. Network Engineer, USAF TSAT Space Segment

_______________________________________________
EME mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/eme