Why Keep Alive "KeepAlive"?

Keepalive in TCP has always been controversial, since it blurs the difference between a dead connection and a moribund connection, or as Vadim Antonov puts it "the knowledge that connectivity is lost". Advocates, in contrast, believe that the effort reclaiming resources needn't be done and hence as David Reed puts it "there is no reason why a TCP connection should EVER time out merely because no one sends a packet over it." Antonov expresses a very narrow affirmation of the value of retained state which is not necessarily useful in the time required, while Reed expresses the reductionist philosophy that no effort should be expended without jusification even if the basis of the repudiation is inherently faulty. But is either truly getting to the heart of the issue? Is it truly important to cleave to the historical constraints of the past Internet philosophical design? Or should we consider the question in the context of what is relevent to the Internet today?

I don't ask these questions frivolously, but with a serious intent. While I am a student of history, and find the study of heritage very valuable in technical work (even patents require a love of reasoning over time), we should occasionally look at the world not as we would like it to be or how it was but how it is. Thus, I suspect the question should actually be "What is the point of having a long-lived TCP session with keepalive in the 21st century"? Is this not a security hole ripe for exploitation in an age of ubiquitous bandwidth and zombie machines? Is not the lack of security and credentials in the modern Internet the bane of both service providers and users? This is the heart of the issue.

The resource allocated to build a socket is minimal if well-designed in a processor / memory rich environment. Fears about OS resource allocation should not be considered as justification for putting keepalive in transport - that's a red herring, about as silly as libtelnet.

Just as in operating systems, the silly debate over a minor mechanism is awash in nostalgia (since the justifications on either side lack conviction) and is not a matter of forward-looking design. As long as design is a matter of redoing the past, keepalive will live on because no one need justify its existence. But good design does not demand the use of keepalive and its use bogs us down dealing with issues of security and operation of the Internet. That doesn't sound like a good design trade-off - does it to you?