[e2e] tcp connection timeout

[David Borman]

On Mar 3, 2006, at 2:46 PM, Joe Touch wrote:

> Vadim Antonov wrote:
>> On Fri, 3 Mar 2006, Joe Touch wrote:
>>
>>
>> It does not matter whose decision it is as long as you have a way of
>> purging it for dead connections.  It was merely a counter-argument  
>> to the
>> assertion that dead connections are "cheap". There are numerous  
>> cases when
>> they are not.
>
> We HAVE a way for applications to purge resources for connections THEY
> think are dead - CLOSE or ABORT.

Well, of course.  But that isn't the issue, the issue is how do they  
decide that the connection is dead?  Keep-alives are one mechanism.

>
>> I think it is always a good idea to look at the whole picture,  
>> because
>> concentrating on one layer is bound to mislead.
>
> Indeed - I (and others) are suggesting TCP isn't the place to focus in
> this case.
>
> Joe

TCP doesn't provide a mechanism for the application to probe to see  
if the other side of the connection is still alive, other than by  
actually sending data and waiting for the connection to time out due  
to retransmissions, or read the connection for a response that never  
arrives.

Whatever the mechanism, there are 3 responses you can get: an ack  
(not just a TCP ACK), and you know the connection is still alive; a  
TCP RST and you know the connection has gone away, or nothing, and  
you have to decide how to deal with that.  It is dropping the  
connection in the third case that causes angst, when the lack of  
response is due to an outage in the network, not due to the other  
side having gone away.  But that has to be dealt with no matter how  
you do the test for connectivity, be it a keep-alive, or a Telnet AYT  
command, or whatever.  Once the application actually tries to send  
data, most TCPs will eventually time out the connection if no  
response is received, so an application level probe during an outage  
will probably result in the connection being dropped, just like lack  
of response to the keep-alives.

Keep-alives provide a specific test for liveliness, and if that works  
for the server application, then use it.  If it doesn't, then don't.   
RFC 1122 addressed the more egregious issues with keep-alives, by  
saying that they are off by default, you have to wait at least 2  
hours before sending them, and that lack of response from any single  
keep-alive is not enough of a reason to drop the connection.

			-David Borman