[e2e] tcp connection timeout

[David P. Reed]

Bob Braden may remember the following extended discussion's points from 
the original TCP days.

Actually, there is no reason why a TCP connection should EVER time out 
merely because no one sends a packet over it.   It's not the "keepalive" 
that's the problem, because keepalives were invented only to fix the 
problem of timing out, which need not have ever been a problem.

What is wrong with a connection that takes no resources whatsoever 
unless someone is trying to send data over it?   Sounds good to me... 
and the cost on each endpoint to maintain a potentially useful 
relationship is a few bytes of table space.  (microcents in todays' 
dollars).

The idea of timing out a connection came because OS folks confused TCP 
connections with "dialup modem calls" and thought that such connections 
ought to be treated like expensive hardware resources such as modems.  
(or perhaps they didn't think much at all - much of the reasoning by 
analogy in those days came from mindless mapping of network abstractions 
to things like TTY channels).

We successfully removed "out of band signalling" from TCP, for example, 
rather than embedding every operating system "interrupt character" in 
the protocol.   Why include operating system "hangup" functionality, 
when only timesharing systems really had such things, and Telnet was an 
application protocol that could do its own keepalives?

And as far as "NAT timeouts" - one of the many objections to NATs was 
that they depend on accidental and irrelevant properties of the 
end-to-end layer (like the idea that a connection can't be up forever 
without sending data).

NATs were invented to be pragmatic stopgaps until the endpoint address 
space could be enlarged (by IPv6, perhaps) - they are not well designed, 
and are full of serious edge cases.