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

This discussion is IMO indeed relevant here (answer to Yangwoo).
The reason is that  part of the subject at hand is what middleboxes 
should do.
This does depend on the E2E functions of protocols on which these 
middleboxes have an action.
Among these protocols, TCP has a prominent position, in particular in 
NAT boxes..
Whether a connection close has to guarantee, or not, delivery to the 
destination application of the last data sent to it, is IMU a 
significant E2E aspect of TCP.
IMU, requirements on NATs do depend significantly on the answer.

I do agree (answer to Paul Francis) that the TCP checksum provides no 
more than what its simple design permits, and harder protections (e.g. 
that of SCTP) would be more appropriate for various applications.
One way to deal with this could be to add at the transport API some 
indication of which level of data integrity guarantee is required..

Concerning what the TCP based transport service does, comments below.

Joe Touch wrote :
> An ACK is generated - but if there is outstanding data, it will not ACK
> the seq num of the FIN.
>   
This is not IMU what the TCP spec says..

> 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.
>   
True. A host that receives a close knows that he has received all data 
sent to it before the close.
But if a host sends a close, its local transport stack receiving a 
transport layer acknowledgment for the close tells only that a transport 
stack, somewhere on the way to the application, has seen the close.
This is true even if there is no middlebox between the hosts.
Consequently, a NAT or even a TCP relay, doesn't change the nature of 
what applications may expect of the transport layer.

NOTE: In practice, for Request-Response protocols, e.g. . HTTP, a simple 
precaution at the application layer is sufficient to provide the 
desirable guarantee.
The first end to close its transmit direction (active close) must be the 
one that receives the last response of the dialog.
Before doing its active close, this "last receiver"  must be sure, at 
the application layer, that the received response is for its complete 
request..
Then the other end, the "last transmitter" receiving  a close sends a 
close for the other direction (passive close).
This way, the active closer knows that all data it has sent have been 
received (it received an application anwer for all of them).
It also knows also that it received all data sent to it since it 
received the passive close.

RD

_______________________________________________
EME mailing list
EME@irtf.org
https://www1.ietf.org/mailman/listinfo/eme