From owner-freebsd-current  Tue Jun  1 11:51:34 1999
Delivered-To: freebsd-current@freebsd.org
Received: from ns.mt.sri.com (unknown [206.127.79.91])
	by hub.freebsd.org (Postfix) with ESMTP
	id DE9981565E; Tue,  1 Jun 1999 11:51:21 -0700 (PDT)
	(envelope-from nate@mt.sri.com)
Received: from mt.sri.com (rocky.mt.sri.com [206.127.76.100])
	by ns.mt.sri.com (8.8.8/8.8.8) with SMTP id MAA19417;
	Tue, 1 Jun 1999 12:51:17 -0600 (MDT)
	(envelope-from nate@rocky.mt.sri.com)
Received: by mt.sri.com (SMI-8.6/SMI-SVR4)
	id MAA14756; Tue, 1 Jun 1999 12:51:16 -0600
Date: Tue, 1 Jun 1999 12:51:16 -0600
Message-Id: <199906011851.MAA14756@mt.sri.com>
From: Nate Williams <nate@mt.sri.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Poul-Henning Kamp <phk@FreeBSD.ORG>
Cc: current@FreeBSD.ORG
Subject: Re: net.inet.tcp.always_keepalive on as default ?
In-Reply-To: <20883.928262460@critter.freebsd.dk>
References: <20883.928262460@critter.freebsd.dk>
X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> Considering the number of hosts on the net today, which come and
> go with no warning and with dynamic IP assignments, I would propose
> that we disregard what the "old farts" felt about TCP keepalives,
> and enable the sysctl net.inet.tcp.always_keepalive as default.

Seeing as the amount of traffic and congestion in the Internet, I
propose we diregard what the 'old fart' PHK says and not increase the
congestion with the use of keepalives. :)

The 'old farts' did a good job of designing a system that happens to
work better than all of the systems the 'young farts' were able to
design.

PHK's arguments are specious, since *any* traffic when the link is
congested is more congestion.

> The argument against is that this will increas trafic and keep
> dynamic lines up when they should otherwise have been allowed to
> fall down.
> 
> The former argument doesn't hold water, since we're talking about
> a TCP segment per hour (or less) per connection.

That's still traffic, and congestion is congestion.  On one systems that
isn't a lot, but with alot of connections it can add up to a significant
amount of bandwidth.

> The second argument falls on the same reasoning in my book, I don't
> know of any on-demand lines with a timeout longer than 10 minutes
> anyway.

You don't know of any, but that doesn't mean they don't exist.


Nate


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message