Subject: Re: keepalive per socket settings patch
To: Darren Reed <darrenr@netbsd.org>
From: Christos Zoulas <christos@zoulas.com>
List: tech-net
Date: 06/20/2007 01:10:22
On Jun 19, 10:01pm, darrenr@netbsd.org (Darren Reed) wrote:
-- Subject: Re: keepalive per socket settings patch

| Christos Zoulas wrote:
| > Hi,
| >
| > This is pretty straight forward... The question is do we let setsockopt
| > specify arbitrary values, or do we cap them to the global settings like
| > I do now? Comments? If there are no disagreements I will commit this after
| > I write the documentation. If there are, speak now and I won't bother
| > with the docs.
| >   
| 
| The most common criticism I've discussed with people about the
| keep alive packets is the problem that you're addressing: different
| applications want different keep alive values.
| 
| I don't think there should be an upper bound, as this reduces the
| amount of extra traffic/work generated in a given period.
| 
| With IPFilter, the largest TCP idle timeout default is 5 days,
| aimed at the ssh/telnet/etc window that you look at "every now
| and then".  I don't know if that is a good suggestion for where
| to start with an upper limit or not.
| 
| The bigger problem is the lower bound....
| Is it too much to allow an application to specify it as being 500ms?
| And what if apache does this for all n000 connections?
| Should that just be a configuration error or ...?

All good questions. The idea for the upper limit being the sysctl
value seemed reasonable at the time. After I implemented it, I
looked at linux and it does almost the same (for some of them it
defines max = tcp_keepfoo / PR_SLOWHZ). Can large values be used
as a DOS attack? What impact do small values have on the system?
The other thing that we can do, and I have not done yet, is to
define 0 as infinity (i.e. no timeout). Linux disallows 0; we accept
it and timeout immediately.

christos