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

[Yangwoo Ko <[e-mail]>]

Please pardon my very rude interrupt.

Are these on-topic? It is really interesting to re-consider
what successful delivery in transport layer means and how
much we can be assured by just looking at packets. But, I
think that this is useful only when this RG (implicitly or
explicitly) decides to make middleboxes do the right things
by watching these packets.

Regards

Joe Touch wrote:
> 
> 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.
> 
> An ACK is generated - but if there is outstanding data, it will not ACK
> the seq num of the FIN.
> 
> The ACK _of the FIN_ means that all subsequent data has been received
> correctly (as determined by the TCP checksum, which is not strong) by
> the TCP at the other end.
> 
> As per below, there are other steps I should have noted to ensure that
> the app has _read_ the data. As you and Paul observe, that may be
> semantically insufficient - even if the app reads the data, if you want
> to know if the app acted on it (e.g., a bank transaction), knowing that
> the item was delivered or even received by the app is insufficient.
> 
>>  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.
> 
> When your side registers a CLOSED state, it means that the other side
> has issued a CLOSE, which means the app has received all the data. It
> may not have acted on it (which would require the app to ACK), but the
> app has it.
> 
>>> ... 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).
> 
> I've tried to show how this is ensured above. Please indicate where that
> is incorrect. I admit I'm not absolutely sure of the mechanistic
> details, but a successful close means the application has _read_ the
> data you sent (which again may be insufficient).
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> EME mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/eme


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