[e2e] tcp connection timeout

[David P. Reed]

I was describing a historical perspective.  TCP is what it is, and no 
one (not me) is suggesting it should be changed.  Ideally it should be 
thrown away someday, because it continues to acquire barnicles.  
However, some comments regarding my points, below:

Vadim Antonov wrote:
> On Wed, 1 Mar 2006, David P. Reed wrote:
>
>   
>> Actually, there is no reason why a TCP connection should EVER time out 
>> merely because no one sends a packet over it.
>>     
>
> The knowledge that connectivity is lost (i.e. that there's no *ability* to
> send information before the need arises) is valuable.
This cannot be well-defined.   This is Jim Gettys' point above.   
"Connectivity" is NOT lost.   The end-to-end probability of packet 
delivery just varies.   Depends on the application's point of 
viewwhether connectivity is lost.   Does the refrigerator light remain 
on when the door is closed?  Why do you care?  And more importantly, can 
you describe precisely when you would care?  This is a classic example 
of the "end to end argument" - you can't define this function 
"connectivity being lost" at the network layer, because connectivity 
isn't lost, only packets are lost.
> A preemptive action
> can then be taken to either alert user, or to switch to an alternative.  
> Just an example (with somewhat militarized slant): it does make a lot of
> difference if you know that you don't know your enemy's position, or if
> you falsely think that you know where they are, and meanwhile they moved
> and you simply didn't hear about it because some wire is cut.
>   
You never know your enemies' position unless you are God.  You only know 
*where they were* not where they are now.  You can waste all your time 
sending radar pulses every microsecond, and you still won't know where 
they are, and you'll never know where they will be when you decide to 
act.  At best, your information can be narrowed based on how much energy 
you put into that.   Better at some point to fire the missile based on 
your best guess and see if it hits.
> There's also an issue of dead end-point detection and releasing the
> resources allocated to such dead point (which may never come back). There
> is no way to discriminate between dead end-point and an end-point which
> merely keeps quiet other than using connection loss detection.
>
> So, in practice, all useful applications end up with some kind of timeouts
> (and keepalives!) - embedded in zillion protocols, mostly designed
> improperly, or left to the user's manual invervention.  It makes
> absolutely no sense - in a good design shared functions must be located at
> the level below, so there's no replication of functionality.
>
> What is needed is an API which lets applications to specify maximal
> duration of loss of connectivity which is acceptable to them.  This part
> is broken-as-designed in all BSD-ish stacks, so few people use it.
>   
It's so easy to do this at the application level, and you can do it 
exactly as you wish - so why implement a slightly general and 
always-wrong model in the lower layer, especially since most users don't 
even need it, and some, like Jim Gettys end up having to patch around 
its false alarms!
> Keepalives, arguably, is the crudest method for detection of loss of
> connectivity, and they load the network with extra traffic and do not
> provide for the fast detection of the loss.  But, because of their
> crudity, they always work.
>   
They NEVER work.  (except if you define working as doing something, even 
if it is not what you want it to do).
> A good idea would be to fix standard socket API and demand that all TCP
> stacks allow useful minimal keepalive times (down to seconds), rather than
> have application-level protocol designers to implement workarounds at the
> application level.
>   
There you go - you think that you can demand that protocol engineers 
know more than application designers about "usefulness".

That's why my cellphone says "call is lost" 20 times a day, requiring me 
to redial over and over, instead of keeping the call alive until I press 
hangup.  Some network engineer decided that a momentary outage should 
be  treated as a permanent one. Foo.
> And, yes, provide the TCP stack with a way to probe the application to
> check if it is alive and not deadlocked (that being another reason to do
> app-level keepalives).
>   
Oh yeah.  Put TCP in charge of the application.   Sure.   And put the 
fox in charge of the chicken coop.

The purpose of the network is to support applications, not the 
applications to support the network's needs.   Perhaps this is because 
network protocol designers want to feel powerful?  And I suppose the 
purpose of applications and users are to pay for Bill Gates's house (or 
Linus's mortgage?)