[e2e] tcp connection timeout

[Joe Touch]

Vadim Antonov wrote:
> On Wed, 1 Mar 2006, Joe Touch wrote:
> 
>> Vadim Antonov wrote:
>>> On Wed, 1 Mar 2006, David P. Reed wrote:
>>>
>>> The knowledge that connectivity is lost (i.e. that there's no *ability* to
>>> send information before the need arises) is valuable.
>> Perhaps, but that's not what TCP provides. TCP sends data reliably. If
>> you aren't sending anything, there's nothing to complain about.
> 
> There is no such thing as just sending data reliably. All retransmission 
> protocols do is trade off maximal latency for probability of delivery.

Sure - the checksum is just a statistical statement (it could be right
but the data could be wrong). And the ACK could have been munged in
transit in a way that preserves the checksum.

The point is that TCP is about saying something (even if not 100%) about
data transfer - it is NOT about saying something about the connection.
That's for things like PPP.

>> As to "releasing resources", TCP preserves only the resources that
>> affect sending data reliably. There's no utility to that end in cleaning
>> up old connections; they're reset only when a new connection collides,
>> which is in keeping with the concept that state needs to be adjusted
>> only when it affects the reliable transmission of data.
> 
> Oh, I see. Did you ever consider that there are application servers which
> have to carry, say, 20 megabytes of in-core state per a client connection?  
> I did see such beauties.  Rete algorithm eats memory like hell, if you 
> have enough facts to use.
> 
> Cleaning up stale or dead connections is something any half-respectable
> app server does.

A half-respectable app server wouldn't allocate 20MB to the receive
buffers of a connection unnecessarily. Run with smaller receive windows
- which is fine unless your sustained rate is over 1.6 Gbps on a land line.

The other problem, though, is that you're assuming that once TCP goes
away, both sides should just 'cleanup'. If the connection has no
outstanding data, it's possible that some ACK'd data has been received
but not delivered to the application - 20MB worth.

It's not TCP's job to decide to give up on that. It's the app's. The app
can issue a close if it doesn't want to stick around after an idle
period. But it should - to tell the other end that the data has been
received. That's the point of the (statistical) notion of reliable transfer.

Joe