[e2e] tcp connection timeout
David P. Reed
dpreed at reed.com
Wed Mar 1 17:45:48 PST 2006
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'
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.
More information about the end2end-interest