Re: RE: net.inet.tcp.always_keepalive on as default ?

[Matthew Dillon]

:>> This wouldn't help the poor sod whose connection gets shot down every
:>> eight days while he's not there and doesn't know what hit him.
:> If the poor sod hasn't touched his xterm for 8 days, he's either dead
:> or he doesn't care if it goes away.
:
:Again, Matt, with all due respect, please do not post your operational
:habits as universals.  Somebody who keeps a session to a server around
:so they can see syslog messages if there's a problem may have an idle
:connection for weeks.
:
:In case you still doubt the existance of such a person, I give you a
:counterexample.  Having just spoken with nemo, I am quite certain that
:he is alive and well, and from my dealings with him have no doubt he
:would become somewhat miffed if I were to kill off several of his
:sessions.
:
:Cheers,
:joelh

Turning on keepalives would not change the effectiveness of leaving
these xterms open if syslog is being tailed.  If there is a network
problem, the connections will terminate from a data timeout due to the
syslog messages being transmitted over the connection long before it
would terminate from a keepalive timeout.

I'm not saying that a person fitting the profile doesn't exist, I'm saying
that there are so few of these people that the benefits outway the issues
by several orders of magnitude.

I can only repeat:  Turn them on and see if they effect you.  You will
almost certainly find that they do not effect you.  Ask your friend to
turn them on and see if they effect him.  If he's tailing syslog in those
windows they won't effect him.

-Matt

:detlev$ finger n...@[deleted]
:[[deleted]]
:Login: nemo Name: Joel N. Weber II
:Directory: /gb/nemo Shell: /usr/local/bin/bash
:On since Thu Jun 03 23:49 (EDT) on tty12 days 3 hours idle
:On since Wed May 19 14:43 (EDT) on tty227 minutes 34 seconds idle
:On since Sun May 30 22:24 (EDT) on tty32 days 1 hour idle
:On since Sun May 30 22:27 (EDT) on tty42 days 3 hours idle
:...



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

Re: net.inet.tcp.always_keepalive on as default ?

[Sheldon Hearn]

Hi folks,

This thread has degenerated into the kind of dick-waving that suggests
to the responsible list member that it's no longer worth participation.

If you have nothing to say, there are many of us who would be in your
debt if you'd be so kind as to say it.

Ciao,
Sheldon.


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

Re: RE: net.inet.tcp.always_keepalive on as default ?

[Brian Feldman]

On 8 Jun 1999, Joel Ray Holveck wrote:

> >> This wouldn't help the poor sod whose connection gets shot down every
> >> eight days while he's not there and doesn't know what hit him.
> > If the poor sod hasn't touched his xterm for 8 days, he's either dead
> > or he doesn't care if it goes away.
> 
> Again, Matt, with all due respect, please do not post your operational
> habits as universals.  Somebody who keeps a session to a server around
> so they can see syslog messages if there's a problem may have an idle
> connection for weeks.

If he sees syslog messages, that's not idle.

> 
> In case you still doubt the existance of such a person, I give you a
> counterexample.  Having just spoken with nemo, I am quite certain that
> he is alive and well, and from my dealings with him have no doubt he
> would become somewhat miffed if I were to kill off several of his
> sessions.
> 
> Cheers,
> joelh
> 
> detlev$ finger n...@[deleted]
> [[deleted]]
> Login: nemo Name: Joel N. Weber II
> Directory: /gb/nemo Shell: /usr/local/bin/bash
> On since Thu Jun 03 23:49 (EDT) on tty12 days 3 hours idle
> On since Wed May 19 14:43 (EDT) on tty227 minutes 34 seconds idle
> On since Sun May 30 22:24 (EDT) on tty32 days 1 hour idle
> On since Sun May 30 22:27 (EDT) on tty42 days 3 hours idle
> On since Mon May 31 00:15 (EDT) on tty52 days 1 hour idle
> On since Mon May 31 16:07 (EDT) on tty62 hours 40 minutes idle
> On since Fri Jun 04 20:58 (EDT) on tty73 days 1 hour idle
> On since Fri Jun 04 22:28 (EDT) on tty13   2 days 3 hours idle
> On since Sat Jun 05 17:05 (EDT) on tty14   2 days 1 hour idle
> On since Sat Jun 05 15:25 (EDT) on tty15   2 days 2 hours idle
> On since Sat Jun 05 21:59 (EDT) on tty16   2 days 3 hours idle
> On since Sat Jun 05 22:11 (EDT) on tty17   3 days 2 hours idle
> On since Sat Jun 05 00:26 (EDT) on tty18   2 days 12 hours idle
> On since Sun Jun 06 19:15 (EDT) on tty19   2 days 1 hour idle
> On since Wed May 19 15:57 (EDT) on ttyp0 from xanthine:0.0
>10 days 1 hour idle
> On since Wed May 19 15:58 (EDT) on ttyp1 from xanthine:0.0
>10 days 1 hour idle
> On since Wed May 19 16:11 (EDT) on ttyp2 from xanthine:0.0
>12 days 23 hours idle
> On since Wed May 19 16:45 (EDT) on ttyp3 from xanthine:0.0
>15 days 21 hours idle
> On since Wed May 19 17:29 (EDT) on ttyp4 from xanthine:0.0
>9 days 23 hours idle
> On since Wed May 19 17:43 (EDT) on ttyp5 from xanthine:0.0
>10 days 2 hours idle
> On since Wed May 19 17:44 (EDT) on ttyp6 from xanthine:0.0
>9 days 23 hours idle
> On since Wed May 19 18:09 (EDT) on ttyp7 from xanthine:0.0
>15 days 21 hours idle
> On since Thu May 20 20:20 (EDT) on ttyp8 from xanthine:0.0
>19 days idle
> On since Wed May 19 18:35 (EDT) on ttyp9 from xanthine:0.0
>16 days 22 hours idle
> On since Wed May 19 21:54 (EDT) on ttypa from xanthine:0.0
>20 days 2 hours idle
> On since Thu May 20 16:06 (EDT) on ttypb from xanthine:0.0
>16 days 2 hours idle
> On since Thu May 20 21:05 (EDT) on ttypc from xanthine:0.0
>9 days 10 hours idle
> On since Thu May 20 23:51 (EDT) on ttypd from xanthine:0.0
>18 days 20 hours idle
> Last login Mon Jun 07 19:22 (EDT) on ttypf from zygorthian-space
> New mail received Wed Jun 09 00:29 1999 (EDT)
>  Unread since Wed Jun 09 00:00 1999 (EDT)
> No Plan.
> 
> -- 
> Joel Ray Holveck - jo...@gnu.org
>Fourth law of programming:
>Anything that can go wrong wi
> sendmail: segmentation violation - core dumped
> 

 Brian Feldman_ __ ___   ___ ___ ___  
 gr...@unixhelp.org_ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!  _ __ | _ \._ \ |) |
 http://www.freebsd.org   _ |___)___/___/ 



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

Re: RE: net.inet.tcp.always_keepalive on as default ?

[Joel Ray Holveck]

>> This wouldn't help the poor sod whose connection gets shot down every
>> eight days while he's not there and doesn't know what hit him.
> If the poor sod hasn't touched his xterm for 8 days, he's either dead
> or he doesn't care if it goes away.

Again, Matt, with all due respect, please do not post your operational
habits as universals.  Somebody who keeps a session to a server around
so they can see syslog messages if there's a problem may have an idle
connection for weeks.

In case you still doubt the existance of such a person, I give you a
counterexample.  Having just spoken with nemo, I am quite certain that
he is alive and well, and from my dealings with him have no doubt he
would become somewhat miffed if I were to kill off several of his
sessions.

Cheers,
joelh

detlev$ finger n...@[deleted]
[[deleted]]
Login: nemo Name: Joel N. Weber II
Directory: /gb/nemo Shell: /usr/local/bin/bash
On since Thu Jun 03 23:49 (EDT) on tty12 days 3 hours idle
On since Wed May 19 14:43 (EDT) on tty227 minutes 34 seconds idle
On since Sun May 30 22:24 (EDT) on tty32 days 1 hour idle
On since Sun May 30 22:27 (EDT) on tty42 days 3 hours idle
On since Mon May 31 00:15 (EDT) on tty52 days 1 hour idle
On since Mon May 31 16:07 (EDT) on tty62 hours 40 minutes idle
On since Fri Jun 04 20:58 (EDT) on tty73 days 1 hour idle
On since Fri Jun 04 22:28 (EDT) on tty13   2 days 3 hours idle
On since Sat Jun 05 17:05 (EDT) on tty14   2 days 1 hour idle
On since Sat Jun 05 15:25 (EDT) on tty15   2 days 2 hours idle
On since Sat Jun 05 21:59 (EDT) on tty16   2 days 3 hours idle
On since Sat Jun 05 22:11 (EDT) on tty17   3 days 2 hours idle
On since Sat Jun 05 00:26 (EDT) on tty18   2 days 12 hours idle
On since Sun Jun 06 19:15 (EDT) on tty19   2 days 1 hour idle
On since Wed May 19 15:57 (EDT) on ttyp0 from xanthine:0.0
   10 days 1 hour idle
On since Wed May 19 15:58 (EDT) on ttyp1 from xanthine:0.0
   10 days 1 hour idle
On since Wed May 19 16:11 (EDT) on ttyp2 from xanthine:0.0
   12 days 23 hours idle
On since Wed May 19 16:45 (EDT) on ttyp3 from xanthine:0.0
   15 days 21 hours idle
On since Wed May 19 17:29 (EDT) on ttyp4 from xanthine:0.0
   9 days 23 hours idle
On since Wed May 19 17:43 (EDT) on ttyp5 from xanthine:0.0
   10 days 2 hours idle
On since Wed May 19 17:44 (EDT) on ttyp6 from xanthine:0.0
   9 days 23 hours idle
On since Wed May 19 18:09 (EDT) on ttyp7 from xanthine:0.0
   15 days 21 hours idle
On since Thu May 20 20:20 (EDT) on ttyp8 from xanthine:0.0
   19 days idle
On since Wed May 19 18:35 (EDT) on ttyp9 from xanthine:0.0
   16 days 22 hours idle
On since Wed May 19 21:54 (EDT) on ttypa from xanthine:0.0
   20 days 2 hours idle
On since Thu May 20 16:06 (EDT) on ttypb from xanthine:0.0
   16 days 2 hours idle
On since Thu May 20 21:05 (EDT) on ttypc from xanthine:0.0
   9 days 10 hours idle
On since Thu May 20 23:51 (EDT) on ttypd from xanthine:0.0
   18 days 20 hours idle
Last login Mon Jun 07 19:22 (EDT) on ttypf from zygorthian-space
New mail received Wed Jun 09 00:29 1999 (EDT)
 Unread since Wed Jun 09 00:00 1999 (EDT)
No Plan.

-- 
Joel Ray Holveck - jo...@gnu.org
   Fourth law of programming:
   Anything that can go wrong wi
sendmail: segmentation violation - core dumped


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

Re: RE: net.inet.tcp.always_keepalive on as default ?

[Vallo Kallaste]

On Tue, Jun 08, 1999 at 11:23:26AM -0700, Matthew Dillon 
 wrote:

> :We've lost our T1 to the world for up to twelve hours.
> 
> And at the time, which was more important:  Getting the T1 back up, or
> keeping all those idle xterm's around?  If it were my T1 that went down,
> I wouldn't give a damn whether the idle xterm's went away or not.

Sure :)
-- 

Vallo Kallaste
va...@matti.ee


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

Re: RE: net.inet.tcp.always_keepalive on as default ?

[Matthew Dillon]

:} you have other problems than worring about connections...
:
:We've lost our T1 to the world for up to twelve hours.

And at the time, which was more important:  Getting the T1 back up, or
keeping all those idle xterm's around?  If it were my T1 that went down,
I wouldn't give a damn whether the idle xterm's went away or not.

-Matt
Matthew Dillon 



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

Re: RE: net.inet.tcp.always_keepalive on as default ?

[Vallo Kallaste]

On Tue, Jun 08, 1999 at 06:07:23AM -0700, Don Lewis  
wrote:

> } yes, but are routers normally down for a couple hours??  if they are,
> } you have other problems than worring about connections...
> 
> We've lost our T1 to the world for up to twelve hours.

Well, we had lightning storm yesterday and lost our T1 connectivity for 
17 hours... not to mention other equipment :(( It wasn't our fault, the 
communication to telco suddenly disappeared..
-- 

Vallo Kallaste
va...@matti.ee


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

Re: RE: net.inet.tcp.always_keepalive on as default ?

[Don Lewis]

On Jun 5,  5:43pm, John-Mark Gurney wrote:
} Subject: Re: RE: net.inet.tcp.always_keepalive on as default ?
} Garrett Wollman scribbled this message on Jun 5:
} > < said:
} > 
} > > FWIW, I think only a fool would want a computer to NOT drop dead 
connections.
} > > Any "connection" that doesn't respond after 8 $^&! tries spaced FAR apart 
does
} > > NOT deserve to stay.
} > 
} > If they are spaced too far apart, it is possible for perfectly
} > legitimate connections to get shot down as a result of external
} > periodicities.  (Does somebody's router reset every day at 2:45?  If
} > so, better hope no keepalives are scheduled for then!)
} 
} yes, but are routers normally down for a couple hours??  if they are,
} you have other problems than worring about connections...

We've lost our T1 to the world for up to twelve hours.


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

Re: net.inet.tcp.always_keepalive on as default ?

[Dmitrij Tejblum]

"Louis A. Mamakos" wrote:
>
> Before documenting it, how about we fix it's name to be more accurate
> to newcomers: net.inet.tcp.always_makedead, etc.  There's no part of
> this (in many cases misguided) mechanism that keeps anything "alive."

I disagree. I use keepalive exactly to keep my connections (mostly ssh 
sessions) alive.

The sysadmin of our corporate LAN made our router drop all connections 
idle for 15 minutes or so. As I understand, the router send fake RST 
packets. The sysadmin believe that it increase security. I tried to 
convince him to not do it, I tried to kill him, but didn't succeed. So,
now I set net.inet.tcp.keepidle to a really low value, and it keeps my
connections alive!

Dima




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

Re: net.inet.tcp.always_keepalive on as default ?

[Joachim Kuebart]

Louis A. Mamakos wrote:
> Before documenting it, how about we fix it's name to be more accurate
> to newcomers: net.inet.tcp.always_makedead, etc.  There's no part of
> this (in many cases misguided) mechanism that keeps anything "alive."

I believe the rationale behind the nomenclature is to ``keep alive
[connections]'', as opposed to keeping ``dead'' connections (whatever they
are).

cu Jo

-
PGP Key is at 
What am I doing here? God, these people drinking milk!
But the clothes they wear look rather cool to me. Joachim Kuebart
I wear the same -- what am I doing here? Ulm, Germany
  --- Banana Fishbones


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

Re: net.inet.tcp.always_keepalive on as default ?

[Matthew Dillon]

:
:Before documenting it, how about we fix it's name to be more accurate
:to newcomers: net.inet.tcp.always_makedead, etc.  There's no part of
:this (in many cases misguided) mechanism that keeps anything "alive."
:
:louie

The technical term in thousands of pages of literature with millions of 
copies in print or on disk is "keepalive".

-Matt


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

Re: net.inet.tcp.always_keepalive on as default ?

[Louis A. Mamakos]

> There's also the the minor nit that there's no documentation.  RTSL
> may be OK for developers, but it's not really appropriate for end
> users.  This is aggravated by the timers being in 500ms units - phk
> tripped over this recently.

Before documenting it, how about we fix it's name to be more accurate
to newcomers: net.inet.tcp.always_makedead, etc.  There's no part of
this (in many cases misguided) mechanism that keeps anything "alive."

louie




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

Re: net.inet.tcp.always_keepalive on as default ?

[Peter Jeremy]

Joel Ray Holveck  wrote:
>I don't see why this is a point of discussion.  The keepalive timers
>are all configurable via sysctl.

Not quite all.  The variables tcp_keepcnt and tcp_maxpersistidle are
not accessible via sysctl (the latter is not directly related to the
current keepalives issue, but it shares the same default value -
TCPTV_KEEP_IDLE - as tcp_keepidle).

There's also the the minor nit that there's no documentation.  RTSL
may be OK for developers, but it's not really appropriate for end
users.  This is aggravated by the timers being in 500ms units - phk
tripped over this recently.

Peter


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

Re: net.inet.tcp.always_keepalive on as default ?

[Joel Ray Holveck]

>> But remember that the idea is the keepalive would keep trying for a
>> certain amount of time, and this would be finely configureable.
> Adjusting the keepalive's retry period after activation is also 
> irrelevant.  As they currently stand, keepalives operate in virtually
[snip]

I don't see why this is a point of discussion.  The keepalive timers
are all configurable via sysctl.  Is this mechanism being considered
as insufficient?

> Unless the entire purpose of the connection is to simply be connected,
> with no data flow ever, being able to finely tune keepalive values does
> not really help.  The existing rough tuning is as much as anyone will
> ever need to mess with.

With all due respect, Matt, the second biggest lesson my time with
computers has taught me is to never think that X will be enough for
all needs.  640k, 32 bit IP addresses, two-digit years, Ada, non
8-bit-clean text utilities, one-second granularity in the filesystem
timestamps, yada yada.

(Note that I have no objection to saying that we don't see a need to
implement it at present.  In this case, I sure don't see such a need,
but I'm willing to be given a counterexample.  We're not looking at
making it impossible-- or even difficult-- to implement other
keepalive timing strategies in the future, if the need arises, so I
would suggest that we not concern ourselves with this discussion until
the need arises.)

Happy hacking,
joelh

-- 
Joel Ray Holveck - jo...@gnu.org
   Fourth law of programming:
   Anything that can go wrong wi
sendmail: segmentation violation - core dumped


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

Re: RE: net.inet.tcp.always_keepalive on as default ?

[Matthew Hunt]

On Sat, Jun 05, 1999 at 11:26:28PM -0700, Matthew Dillon wrote:

> If the poor sod hasn't touched his xterm for 8 days, he's either dead
> or he doesn't care if it goes away.

Thanks for your concern.

Matt, poor sod.

-- 
Matthew Hunt  * UNIX is a lever for the
http://www.pobox.com/~mph/   * intellect. -J.R. Mashey


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

Re: net.inet.tcp.always_keepalive on as default ?

[sthaug]

> The "poor sod" in this situation deserves something untoward,
> IMNSHO. Protocols like ssh do send something periodically whereas
> telnet doesn't. Telnet is a well-known security problem. As others
> have pointed out, this is an endemic problem in applications
> generally speaking, where a long-term "idle" connection isn't
> treated as an exception or an an error.

Some of us use only ssh for remote login *and* specifically turn off
ssh keepalives, in order to keep login sessions up for weeks at at time.

Steinar Haug, Nethelp consulting, sth...@nethelp.no


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

Re: net.inet.tcp.always_keepalive on as default ?

[sthaug]

> :Huh?  I was just considering writing the patch for this.  What
> :application problems would this create?
> :
> :The worst thing I can see is that it would mean that changing the
> :timeout value on a running system wouldn't affect already opened
> :sockets.  Even that may be changable by an external utility if I can
> :think of a way to handle the locking in userland.
> :
> 
>I see no use whatsoever for being able to specify per-socket keepalive
>timeouts.

Well, if it was implemented with the TCP_KEEPALIVE option, it would be
one more part of the system that complied with the X/Open specifications.

Steinar Haug, Nethelp consulting, sth...@nethelp.no


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

Re: net.inet.tcp.always_keepalive on as default ?

[Tomoaki NISHIYAMA]

From: Matthew Dillon 
Subject: Re: net.inet.tcp.always_keepalive on as default ?
Date: Sat, 5 Jun 1999 23:20:20 -0700 (PDT)
Message-ID: <199906060620.xaa17...@apollo.backplane.com>

dillon> As far as dial-on-demand goes, that also makes no real difference.
dillon> There are very few two-way dial-on-demand systems.  Usually 
Two-way dial-on-demand systems may be few but actually exist.
In that case, a keep alive packet may cause an extra charge of 10 yen 
(about US$0.08), which can be significant if the amount of other traffic
is small.
Note that I am not necessarily against keep alive, if there is a
benefit over that charge.

Tomoaki Nishiyama
  e-mail:tomo...@biol.s.u-tokyo.ac.jp
 Department of Biological Sciences,
Graduate School of Science, The University of Tokyo


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

Re: net.inet.tcp.always_keepalive on as default ?

[Matthew Dillon]

:On Sat, Jun 05, 1999 at 07:37:57AM +0200, Poul-Henning Kamp wrote:
:> QED:  The following patch.
:[...]
:> +tcp_keepalive="YES" # Kill dead TCP connections (or NO).
:
:I still don't understand why you insist on making it YES by default. It
:works fine like it is for most of the people right now.
:So why shouldn't the few servers which have problems without it, enable
:it? Make it a knob in rc.conf but off by default.
:As I understand it, It suffices if the server requests the keepalives.
:So if every FreeBSD-box has it on by default, I simply can not choose to
:have no keepalifes anymore, even if I turn them off locally. So this
:change is going to hurt somebody, somewhere.
:
:CU,
:Sec

The problem is that certain classes of connections or network
instabilities can leave stale daemons.  FreeBSD boxes operating 
as servers in any real capacity for certain services will want
keepalives on.  The system defaults should result in stability.
For a significant percentage of machines, leaving keepalives off
results in a slow buildup of processes sitting on dead connections.
i.e. long term instability.  This is especially true of machines which 
people log into with telnet, NNTP, and a number of other servers.

When you leave a machine on 24 hours a day, these sorts of things
can become important.  The machine needs to be able to clean up after
itself.

-Matt
Matthew Dillon 



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

Re: net.inet.tcp.always_keepalive on as default ?

[Matthew Dillon]

:
:> 4.  It would be desirable to have per socket timeouts, but would
:> require application changes which are unlikely to happen.
:
:Huh?  I was just considering writing the patch for this.  What
:application problems would this create?
:
:The worst thing I can see is that it would mean that changing the
:timeout value on a running system wouldn't affect already opened
:sockets.  Even that may be changable by an external utility if I can
:think of a way to handle the locking in userland.
:
:Cheers,
:joelh

   I see no use whatsoever for being able to specify per-socket keepalive
   timeouts.

-Matt



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

Re: RE: net.inet.tcp.always_keepalive on as default ?

[Matthew Dillon]

:< 
said:
:
:>> If they are spaced too far apart, it is possible for perfectly
:>> legitimate connections to get shot down as a result of external
:>> periodicities.  (Does somebody's router reset every day at 2:45?  If
:>> so, better hope no keepalives are scheduled for then!)
:
:> But remember that the idea is the keepalive would keep trying for a certain
:> amount of time, and this would be finely configureable.
:
:This wouldn't help the poor sod whose connection gets shot down every
:eight days while he's not there and doesn't know what hit him.

If the poor sod hasn't touched his xterm for 8 days, he's either dead
or he doesn't care if it goes away.

-Matt


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

Re: net.inet.tcp.always_keepalive on as default ?

[Matthew Dillon]

:> wouldn't notice... nobody would notice.
:
:I would. I have several long-lived connections, with a few of them
:are sometimes unreachable for quote some time. I like that they survive,
:and would hate it, if some brain-dead default would ruin my perfectly
:set up connections.
:
:Even more, it would ruin dial-on-demand for a lot of people, i think.
:
:CU,
:Sec

Turn on keepalives and see if you actually notice.  I can virtually
guarentee that you will not notice.

As far as dial-on-demand goes, that also makes no real difference.
There are very few two-way dial-on-demand systems.  Usually 
dial-on-demand is outgoing only.  Incoming packets cannot activate them.
There are a few ISDN-based links and ISPs that implement it in both
directions both those are rapidly dying away.  This means that incoming
data on the undialed link will cause a disconnect, making holding such 
connections over an undialed link so unreliable that depending on the
effect is stupid.  If you have an active connection to somewhere,
the link needs to be up for that connection to remain reliable whether
keepalives are turned on or not.

-Matt


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

Re: RE: net.inet.tcp.always_keepalive on as default ?

[Matthew Dillon]

:> 
:> If they are spaced too far apart, it is possible for perfectly
:> legitimate connections to get shot down as a result of external
:> periodicities.  (Does somebody's router reset every day at 2:45?  If
:> so, better hope no keepalives are scheduled for then!)
:
:But remember that the idea is the keepalive would keep trying for a certain
:amount of time, and this would be finely configureable.
: Brian Feldman_ __ ___   ___ ___ ___  

Adjusting the keepalive's retry period after activation is also 
irrelevant.  As they currently stand, keepalives operate in virtually
the same fashion as sending a byte of data.  Extending the retry
period for a keepalive is no more a reliable solution then extending
( or shortening ) the initial timeout because you are only effecting one
small aspect of the TCP protocol.  You are not effecting timeouts 
associated with normal data transmitted ( from either side ) over TCP.

Unless the entire purpose of the connection is to simply be connected,
with no data flow ever, being able to finely tune keepalive values does
not really help.  The existing rough tuning is as much as anyone will
ever need to mess with.

-Matt



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

Re: RE: net.inet.tcp.always_keepalive on as default ?

[Matthew Dillon]

:> FWIW, I think only a fool would want a computer to NOT drop dead connections.
:> Any "connection" that doesn't respond after 8 $^&! tries spaced FAR apart 
does
:> NOT deserve to stay.
:
:If they are spaced too far apart, it is possible for perfectly
:legitimate connections to get shot down as a result of external
:periodicities.  (Does somebody's router reset every day at 2:45?  If
:so, better hope no keepalives are scheduled for then!)
:
:-GAWollman
:
:Garrett A. Wollman   | O Siem / We are all family / O Siem / We're all the same

Irrelevant.  If data is transmitted from either side at 'just the
wrong time', you have the same problem.  Keepalives do not make it
worse.

-Matt
Matthew Dillon 



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

Re: net.inet.tcp.always_keepalive on as default ?

[Joel Ray Holveck]

>> This wouldn't help the poor sod whose connection gets shot down every
>> eight days while he's not there and doesn't know what hit him.
> One thing that no one points out is that this "idle" connection
> is potentially a security threat. Even if the physical connection
> is iced and is reconnected later using the same IP and the TCP
> connection is restored because it was kept alive, this presents a
> whole new world of interesting exploits. It's non-trivial, but
> that doesn't stop people like Network Associates' Labs from
> publishing papers on the subject.

Keepalives are not particularly useful against connection hijacking,
as far as I can tell, except perhaps that a keepalive packet may
disclose the current TCP sequence number to the new assignee of a
dynamic IP.  (This, of course, presents an argument for the opposite
stance.)

As near as I can tell, you're saying that if a transient outage is
restored, then after it's restored, an idle connection may be used by
an intruder.  How does the transient outage affect this?

If the transient outage has the side effect of changing routing, then
an attacker (or somebody else) is moving cables around, or a dynamic
link with a dynamic IP is being changed.  In the former case, then the
long delay between keepalive packets should not make them a valid
protection.  (If it takes an attacker more than a week to move a
cable, then may I suggest your attacker needs to refine his
technique.)

In the latter case, then the attacker who now holds the destination IP
can respond to the keepalive packets masquerading as the legitimate
recipient as easily as they can do any other work involved in
hijacking your connection.

If the outage did not cause a reconfiguration, then the attacker
generally has no different access to your network than before, and no
more means to hijack an open connection than before.

I've got some whiskey in me right now, so I may be unclear on what
you're saying.  Am I missing something here?

Happy hacking,
joelh

-- 
Joel Ray Holveck - jo...@gnu.org
   Fourth law of programming:
   Anything that can go wrong wi
sendmail: segmentation violation - core dumped


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

Re: net.inet.tcp.always_keepalive on as default ?

[Joel Ray Holveck]

> 4.  It would be desirable to have per socket timeouts, but would
> require application changes which are unlikely to happen.

Huh?  I was just considering writing the patch for this.  What
application problems would this create?

The worst thing I can see is that it would mean that changing the
timeout value on a running system wouldn't affect already opened
sockets.  Even that may be changable by an external utility if I can
think of a way to handle the locking in userland.

Cheers,
joelh

-- 
Joel Ray Holveck - jo...@gnu.org
   Fourth law of programming:
   Anything that can go wrong wi
sendmail: segmentation violation - core dumped


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

Re: net.inet.tcp.always_keepalive on as default ?

[Joel Ray Holveck]

> The central issue of keepalives is that, for one machine, they don't create
> a significant load.  Multiplied by the number of machines on the Internet,
> it can become a problem.

Divided by the combined bandwidth of the networks these machines are
using, it ceases to be a problem.

joelh

-- 
Joel Ray Holveck - jo...@gnu.org
   Fourth law of programming:
   Anything that can go wrong wi
sendmail: segmentation violation - core dumped


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

Re: net.inet.tcp.always_keepalive on as default ?

[Joel Ray Holveck]

> I don't know what's worse; that Microsoft themselves can't keep
> Windows running for 50 days, or that they're incapable of manually
> bumping the counter to a value close to UINT_MAX and wait a few
> minutes for it to roll over.

What's worst is probably that the bug doesn't affect operation.
Nobody I've talked to has ever seen a Windows 95 machine stay up for
over a week or so, let alone a month.

joelh

-- 
Joel Ray Holveck - jo...@gnu.org
   Fourth law of programming:
   Anything that can go wrong wi
sendmail: segmentation violation - core dumped


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

Re: net.inet.tcp.always_keepalive on as default ?

[Scott Michel]

> This wouldn't help the poor sod whose connection gets shot down every
> eight days while he's not there and doesn't know what hit him.

One thing that no one points out is that this "idle" connection
is potentially a security threat. Even if the physical connection
is iced and is reconnected later using the same IP and the TCP
connection is restored because it was kept alive, this presents a
whole new world of interesting exploits. It's non-trivial, but
that doesn't stop people like Network Associates' Labs from
publishing papers on the subject.

It seems to me that the keepalive might improve the security
situation in the case in addition to doing something about
connections with unknown status.

The "poor sod" in this situation deserves something untoward,
IMNSHO. Protocols like ssh do send something periodically whereas
telnet doesn't. Telnet is a well-known security problem. As others
have pointed out, this is an endemic problem in applications
generally speaking, where a long-term "idle" connection isn't
treated as an exception or an an error.

Your point on randomization is well taken and is generally what's
taught in graduate Internet architecture related courses (ok, Lixia
Zhang will drill this into your head here at UCLA, YMMV elsewhere.)
Although a more conservative distibution would be [t-t/2, t + 2t]. :-)


-scooter



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

Re: RE: net.inet.tcp.always_keepalive on as default ?

[Garrett Wollman]

< 
said:

>> If they are spaced too far apart, it is possible for perfectly
>> legitimate connections to get shot down as a result of external
>> periodicities.  (Does somebody's router reset every day at 2:45?  If
>> so, better hope no keepalives are scheduled for then!)

> But remember that the idea is the keepalive would keep trying for a certain
> amount of time, and this would be finely configureable.

This wouldn't help the poor sod whose connection gets shot down every
eight days while he's not there and doesn't know what hit him.

A fundamental principle of protocol design is that synchronization
effects can arise totally unexpectedly, with dangerous consequences
for the stability of the Internet as a whole.  It is necessary to
introduce some amount of randomness in order to break up this
unintentional synchronization.  Modern (post-Van Jacobson) TCP is not
directly subject to this effect unless you do something stupid like
cause TCP to send a packet like clockwork every X units of time!
(TCP can still fall prey to self-synchronization in the applications
running on top of it, which is one of the reasons why routers are
strongly encouraged to implement a RED queueing discipline by
default.)

I would withdraw my objection if keepalives were fixed to use a
random distribution over [t - t/2, t + t/2].

-GAWollman

--
Garrett A. Wollman   | O Siem / We are all family / O Siem / We're all the same
woll...@lcs.mit.edu  | O Siem / The fires of freedom 
Opinions not those of| Dance in the burning flame
MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick


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

Re: net.inet.tcp.always_keepalive on as default ?

[Stefan `Sec` Zehl]

On Sat, Jun 05, 1999 at 07:37:57AM +0200, Poul-Henning Kamp wrote:
> QED:  The following patch.
[...]
> +tcp_keepalive="YES"  # Kill dead TCP connections (or NO).

I still don't understand why you insist on making it YES by default. It
works fine like it is for most of the people right now.
So why shouldn't the few servers which have problems without it, enable
it? Make it a knob in rc.conf but off by default.
As I understand it, It suffices if the server requests the keepalives.
So if every FreeBSD-box has it on by default, I simply can not choose to
have no keepalifes anymore, even if I turn them off locally. So this
change is going to hurt somebody, somewhere.


CU,
Sec
-- 
One of the main causes of the fall of the Roman Empire
was that, lacking zero, they had now way to indicate
successful termination of their C Programs.


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

Re: RE: net.inet.tcp.always_keepalive on as default ?

[John-Mark Gurney]

Garrett Wollman scribbled this message on Jun 5:
> < 
> said:
> 
> > FWIW, I think only a fool would want a computer to NOT drop dead 
> > connections.
> > Any "connection" that doesn't respond after 8 $^&! tries spaced FAR apart 
> > does
> > NOT deserve to stay.
> 
> If they are spaced too far apart, it is possible for perfectly
> legitimate connections to get shot down as a result of external
> periodicities.  (Does somebody's router reset every day at 2:45?  If
> so, better hope no keepalives are scheduled for then!)

yes, but are routers normally down for a couple hours??  if they are,
you have other problems than worring about connections...

-- 
  John-Mark Gurney  Voice: +1 541 684 8449
  Cu Networking   P.O. Box 5693, 97405

  "The soul contains in itself the event that shall presently befall it.
  The event is only the actualizing of its thought." -- Ralph Waldo Emerson


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

Re: net.inet.tcp.always_keepalive on as default ?

[Stefan `Sec` Zehl]

On Fri, Jun 04, 1999 at 10:21:05PM +0200, Matthew Dillon wrote:
> Around 0.02%, using the stats from one of BEST's busier servers.
> That's percent.
> 
> In otherwords, nobody would notice.  You wouldn't notice, the backbones
> wouldn't notice... nobody would notice.

I would. I have several long-lived connections, with a few of them
are sometimes unreachable for quote some time. I like that they survive,
and would hate it, if some brain-dead default would ruin my perfectly
set up connections.

Even more, it would ruin dial-on-demand for a lot of people, i think.

CU,
Sec
-- 
The Feynman problem solving Algorithm
1) Write down the problem
2) Think real hard
3) Write down the answer


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

Re: RE: net.inet.tcp.always_keepalive on as default ?

[Brian Feldman]

On Sat, 5 Jun 1999, Garrett Wollman wrote:

> < 
> said:
> 
> > FWIW, I think only a fool would want a computer to NOT drop dead 
> > connections.
> > Any "connection" that doesn't respond after 8 $^&! tries spaced FAR apart 
> > does
> > NOT deserve to stay.
> 
> If they are spaced too far apart, it is possible for perfectly
> legitimate connections to get shot down as a result of external
> periodicities.  (Does somebody's router reset every day at 2:45?  If
> so, better hope no keepalives are scheduled for then!)

But remember that the idea is the keepalive would keep trying for a certain
amount of time, and this would be finely configureable.

> 
> -GAWollman
> 
> --
> Garrett A. Wollman   | O Siem / We are all family / O Siem / We're all the 
> same
> woll...@lcs.mit.edu  | O Siem / The fires of freedom 
> Opinions not those of| Dance in the burning flame
> MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick
> 

 Brian Feldman_ __ ___   ___ ___ ___  
 gr...@unixhelp.org_ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!  _ __ | _ \._ \ |) |
 http://www.freebsd.org   _ |___)___/___/ 



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

Re: RE: net.inet.tcp.always_keepalive on as default ?

[Garrett Wollman]

< 
said:

> FWIW, I think only a fool would want a computer to NOT drop dead connections.
> Any "connection" that doesn't respond after 8 $^&! tries spaced FAR apart does
> NOT deserve to stay.

If they are spaced too far apart, it is possible for perfectly
legitimate connections to get shot down as a result of external
periodicities.  (Does somebody's router reset every day at 2:45?  If
so, better hope no keepalives are scheduled for then!)

-GAWollman

--
Garrett A. Wollman   | O Siem / We are all family / O Siem / We're all the same
woll...@lcs.mit.edu  | O Siem / The fires of freedom 
Opinions not those of| Dance in the burning flame
MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick


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

Re: RE: net.inet.tcp.always_keepalive on as default ?

[Julian Elischer]

I think part of the solution is a new class of keepalives..
With this new class, a keepalive is sent every N second (3600?)
but if no response is heard, no action is taken. The only action that is
taken is if a NAK is recieved in response.

Most IP addresses woudl be re-used within a few days, so even if someonen
hangs up, in most cases SOMETHING will respond with a NACK withinthe next
day or two.

julian


On Sat, 5 Jun 1999, Matthew Dillon wrote:

> : There is no logical reason for a well-designed web server to enable
> :keepalives. Of course, they don't hurt anything.
> :
> :...
> :
> : Agreed. Telnetd is the exception, keepalives are great for it. For
> :everything else, almost, data timeouts make far more sense. And keepalives
> :will do nothing, but won't hurt anything.
> :
> : As I have said before, any application that does not implement data
> :timeouts for all states, and does not enable keepalives is BROKEN.
> 
> You are missing the point, big time.
> 
> There are hundreds of programmers writing hundreds of servers, most 
> written by third-parties.  New ones pop up every day.  Nobody
> is going to go through and make sure all of them turn on keepalives. 
> Nobody is going to go and try to contact all the authors involved to
> try to get them to implement their own timeouts.  There are, in fact,
> many servers where implementing a timeout is *inappropriate*.
> 
> ssh, rsh, and telnet for example.  nntp is an example of a server where
> the timeout depends on the use.  Some ISP's might want to implement a 
> timeout, others might not.  At BEST I decided to *not* have a timeout...
> people can stay connected and idle for hours if they want.
> 
> Your 'solution' is no solution at all.  You aren't thinking through the
> problem carefully enough.
> 
> The Keepalive capability exists for a reason.  The original reasons for
> not turning them on by default all those years ago no longer exist, and
> the only reasons people come up with now are extremely shallow and 
> uninformed.
> 
> I have yet to hear a single informed opinion against turning on
> keepalives.  
> 
> All I hear is mob-mentality stuff: people with opinions not backed by
> real facts, or people with opinions based on assumptions that are 
> incorrect.
> 
>   -Matt
>   Matthew Dillon 
>   
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-current" in the body of the message
> 



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

Re: RE: net.inet.tcp.always_keepalive on as default ?

[Brian Feldman]

FWIW, I think only a fool would want a computer to NOT drop dead connections.
Any "connection" that doesn't respond after 8 $^&! tries spaced FAR apart does
NOT deserve to stay.

 Brian Feldman_ __ ___   ___ ___ ___  
 gr...@unixhelp.org_ __ ___ | _ ) __|   \ 
 FreeBSD: The Power to Serve!  _ __ | _ \._ \ |) |
 http://www.freebsd.org   _ |___)___/___/ 



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

Re: RE: net.inet.tcp.always_keepalive on as default ?

[Matthew Dillon]

:   There is no logical reason for a well-designed web server to enable
:keepalives. Of course, they don't hurt anything.
:
:...
:
:   Agreed. Telnetd is the exception, keepalives are great for it. For
:everything else, almost, data timeouts make far more sense. And keepalives
:will do nothing, but won't hurt anything.
:
:   As I have said before, any application that does not implement data
:timeouts for all states, and does not enable keepalives is BROKEN.

You are missing the point, big time.

There are hundreds of programmers writing hundreds of servers, most 
written by third-parties.  New ones pop up every day.  Nobody
is going to go through and make sure all of them turn on keepalives. 
Nobody is going to go and try to contact all the authors involved to
try to get them to implement their own timeouts.  There are, in fact,
many servers where implementing a timeout is *inappropriate*.

ssh, rsh, and telnet for example.  nntp is an example of a server where
the timeout depends on the use.  Some ISP's might want to implement a 
timeout, others might not.  At BEST I decided to *not* have a timeout...
people can stay connected and idle for hours if they want.

Your 'solution' is no solution at all.  You aren't thinking through the
problem carefully enough.

The Keepalive capability exists for a reason.  The original reasons for
not turning them on by default all those years ago no longer exist, and
the only reasons people come up with now are extremely shallow and 
uninformed.

I have yet to hear a single informed opinion against turning on
keepalives.  

All I hear is mob-mentality stuff: people with opinions not backed by
real facts, or people with opinions based on assumptions that are 
incorrect.

-Matt
Matthew Dillon 



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

RE: net.inet.tcp.always_keepalive on as default ?

[David Schwartz]

> "David Schwartz" wrote:
> >
> > > Well, we've heard various opinions and I think we can conclude that:
> > >
> > > 2.  That server applications should have keepalives enabled.
> >
> > Well, I certainly don't agree with that. Many server
> applications (web
> > servers, mail servers, etcetera) already have data timeouts, which makes
> > keepalives redundant.
>
> Huh?  The keepalive option *is* a kind of data timeout..  It's a failsafe
> so that if nothing has been heard for a while then it explicitly does
> a check to see if the network connection is still valid.  Of
> course a server
> app is free to implement it's own data timeouts, but it shouldn't have
> to reinvent what the kernel can do very well already and is very difficult
> to do in userland.

It's trivial to do in userland, just wrap your read in a select. If the
select times out, bail. In many cases, the one-size-fits-all approach of
keepalives doesn't fit. Why should someone be allowed to stay connected to
my web server for _two_hours_ without sending one byte of data?

> There are several sorts of timeouts that server apps *may* want:
> - Some sort of upper bound on a session time, eg: a fingerd
> session may not
> last more than 1 hour, regardless of whether it's doing
> something.  Something
> like a http server might put an upper limit of something like 24
> hours - if it
> is too small and it will interfere with large downloads.

Most web servers implement two different time outs. One is a 'request'
timeout that typically is in the 2 to 5 minute range. Another is an output
timeout that limits how long a connection can go without receiving at least
a certain amount of data. Hard session limits are generally not useful --
after all, someone might put a 600Mb file up there and someone might want to
retrieve it over a 28.8Kbps connection.

Keepalives do not eliminate the need for _either_ timeout. Two hours is 
too
long to wait for a request. Since the TCP connection may work even though
the remote end's userland program is not receiving any data, the send
timeout is still needed as well.

There is no logical reason for a well-designed web server to enable
keepalives. Of course, they don't hurt anything.

> - Some sort of idle timeout, eg: a smtp server may want to time out
> after 10 minutes of not recieving a command.
> - A way of detecting a stalled or rebooted client.  This is what
> keepalive
> does.  It lets you detect a lost connection before some other
> longer timeout
> (eg: 24 hours) kicks in.

There are very few server applications where 24 hour timeouts make 
sense.
In the vast majortity of cases (again, telnetd excepted), timeouts are in
the 1-5 minute range.

Even web servers sending data use timeouts less than 10 minutes. The
timeout, though, is on the current block of data, not the whole file.

> > In my opinion, in the vast majority of cases, data timeouts are more
> > logical than keepalives. 'telnetd' being the most obvious exception.
>
> Telnetd is the worst example. Just because I have not typed something for
> two hours is no indication that the session should be closed.  Only the
> kernel can test the validity of the network link in this case.
> However, of
> I drop a link or reboot, then I do want it cleaned up in a timely fashion.

Agreed. Telnetd is the exception, keepalives are great for it. For
everything else, almost, data timeouts make far more sense. And keepalives
will do nothing, but won't hurt anything.

As I have said before, any application that does not implement data
timeouts for all states, and does not enable keepalives is BROKEN.

DS



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

Re: net.inet.tcp.always_keepalive on as default ?

[Mikhail Teterin]

Poul-Henning Kamp once stated:

=>=+tcp_keepalive="YES" # Kill dead TCP connections (or NO).
=>
=>Mmm, "probably dead TCP connections"?
=
=After 8 attempts at reaching other end:  "Dead TCP connections".

Perhaps "very  probably dead"? I'm  just trying to prevent  questions in
users' minds:  "why the heck  could anyone want to  set this to  NO"? If
there is a hint some of this connections _may_ really be alive... May be
a pointer  to a more detailed  explanation should go into  the rc.conf's
comment?

-mi


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

Re: net.inet.tcp.always_keepalive on as default ?

[Nick Hibma]

 > =+tcp_keepalive="YES"# Kill dead TCP connections (or NO).
 > 
 > Mmm, "probably dead TCP connections"?

'inactive or dead' ?




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

Re: net.inet.tcp.always_keepalive on as default ?

[Poul-Henning Kamp]

In message <199906051334.jaa12...@kot.ne.mediaone.net>, Mikhail Teterin writes:
>Poul-Henning Kamp once stated:
>
>=+tcp_keepalive="YES"  # Kill dead TCP connections (or NO).
>
>Mmm, "probably dead TCP connections"?

After 8 attempts at reaching other end:  "Dead TCP connections".

--
Poul-Henning Kamp FreeBSD coreteam member
p...@freebsd.org   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


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

Re: net.inet.tcp.always_keepalive on as default ?

[Mikhail Teterin]

Poul-Henning Kamp once stated:

=+tcp_keepalive="YES"   # Kill dead TCP connections (or NO).

Mmm, "probably dead TCP connections"?

-mi


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

Re: net.inet.tcp.always_keepalive on as default ?

[Peter Wemm]

"David Schwartz" wrote:
> 
> > Well, we've heard various opinions and I think we can conclude that:
> >
> > 2.  That server applications should have keepalives enabled.
> 
>   Well, I certainly don't agree with that. Many server applications (web
> servers, mail servers, etcetera) already have data timeouts, which makes
> keepalives redundant.

Huh?  The keepalive option *is* a kind of data timeout..  It's a failsafe
so that if nothing has been heard for a while then it explicitly does
a check to see if the network connection is still valid.  Of course a server
app is free to implement it's own data timeouts, but it shouldn't have
to reinvent what the kernel can do very well already and is very difficult
to do in userland.

There are several sorts of timeouts that server apps *may* want:
- Some sort of upper bound on a session time, eg: a fingerd session may not
last more than 1 hour, regardless of whether it's doing something.  Something
like a http server might put an upper limit of something like 24 hours - if it
is too small and it will interfere with large downloads.
- Some sort of idle timeout, eg: a smtp server may want to time out
after 10 minutes of not recieving a command.
- A way of detecting a stalled or rebooted client.  This is what keepalive 
does.  It lets you detect a lost connection before some other longer timeout
(eg: 24 hours) kicks in.

>   In my opinion, in the vast majority of cases, data timeouts are more
> logical than keepalives. 'telnetd' being the most obvious exception.

Telnetd is the worst example. Just because I have not typed something for
two hours is no indication that the session should be closed.  Only the
kernel can test the validity of the network link in this case.  However, of
I drop a link or reboot, then I do want it cleaned up in a timely fashion.

>   DS

Cheers,
-Peter



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

RE: net.inet.tcp.always_keepalive on as default ?

[David Schwartz]

> Well, we've heard various opinions and I think we can conclude that:
>
> 2.  That server applications should have keepalives enabled.

Well, I certainly don't agree with that. Many server applications (web
servers, mail servers, etcetera) already have data timeouts, which makes
keepalives redundant.

In my opinion, in the vast majority of cases, data timeouts are more
logical than keepalives. 'telnetd' being the most obvious exception.

DS



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

Re: net.inet.tcp.always_keepalive on as default ?

[Poul-Henning Kamp]

Well, we've heard various opinions and I think we can conclude that:

1.  Even with the current timeouts, there is no significant increase
in network trafic, even with the market share FreeBSD has.

2.  That server applications should have keepalives enabled.

3.  That the few people, for whom it could become a problem if it
is enabled by default, are prefectly capable of changing a
variable in /etc/rc.conf.

4.  It would be desirable to have per socket timeouts, but would
require application changes which are unlikely to happen.

5.  Changing the timeouts would potentially mean trouble for certain
applications.

QED:  The following patch.

If you don't like this, remember to change that variable in
/etc/rc.conf in the future.

Poul-Henning

Index: rc.network
===
RCS file: /home/ncvs/src/etc/rc.network,v
retrieving revision 1.44
diff -u -r1.44 rc.network
--- rc.network  1999/04/12 15:26:41 1.44
+++ rc.network  1999/06/05 05:25:51
@@ -180,6 +180,11 @@
sysctl -w net.inet.ip.accept_sourceroute=1 >/dev/null 2>&1
 fi
 
+if [ "X$tcp_keepalive" = X"YES" ]; then
+   echo -n ' TCP keepalive=YES'
+   sysctl -w net.inet.tcp.always_keepalive=1 >/dev/null 2>&1
+fi
+
 if [ "X$ipxgateway_enable" = X"YES" ]; then
echo -n ' IPX gateway=YES'
sysctl -w net.ipx.ipx.ipxforwarding=1 >/dev/null 2>&1
Index: defaults/rc.conf
===
RCS file: /home/ncvs/src/etc/defaults/rc.conf,v
retrieving revision 1.9
diff -u -r1.9 rc.conf
--- rc.conf 1999/05/16 09:19:44 1.9
+++ rc.conf 1999/06/05 05:26:26
@@ -41,6 +41,7 @@
 natd_flags=""   # Additional flags for natd.
 tcp_extensions="NO"# Set to Yes to turn on RFC1323 extensions.
 log_in_vain="NO"   # Disallow bad connection logging (or YES).
+tcp_keepalive="YES"# Kill dead TCP connections (or NO).
 network_interfaces="lo0"   # List of network interfaces (lo0 is loopback).
 ifconfig_lo0="inet 127.0.0.1"  # default loopback device configuration.
 #ifconfig_lo0_alias0="inet 127.0.0.254 netmask 0x" # Sample alias 
entry.

--
Poul-Henning Kamp FreeBSD coreteam member
p...@freebsd.org   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


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

Re: net.inet.tcp.always_keepalive on as default ?

[Poul-Henning Kamp]

In message <199906042217.paa22...@gndrsh.aac.dev.com>, "Rodney W. Grimes" 
writes:
>> In message <37580f03.88efb...@sitara.net>, "John R. LoVerso" writes:
>> 
>> >But, consider going back to the discusssions leading up to the Host 
>> >Requirements
>> >RFC (1122).  The particular problem was that the original timeout value for
>> >keepalives was tiny (a few minutes).  1122 dictated the corrections for 
>> >this. 
>> >Here are the important points from section 4.2.3.6:
>> 
>> But RFC 1122 pretty much entirely predates the "modern internet user".  While
>> I fully supported the policy back then, I no longer do.
>> 
>> I still think the right thing is:
>> 
>>  default to keepalives.
>>  set the timeout to a week.
>
>Then lets go off a write RFC and get RFC1123 off the books, it's way
>over due for an overhaul anyway.
>

I think it has been attempted, but gaining rough concensus on a document
which declares N implementations "junk" is hard to get.

--
Poul-Henning Kamp FreeBSD coreteam member
p...@freebsd.org   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


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

RE: net.inet.tcp.always_keepalive on as default ?

[David Schwartz]

You know, I was going to buy a pickup truck, but I was afraid my 
neighbors
would figure that if I bought a pickup truck, they should buy one too. And
maybe a pickup truck isn't the right vehicle for them -- perhaps they didn't
even know how to drive one safely. So I bought an Explorer instead.

DS

> :That's an excellent point!  People with less correct
> implementations of TCP
> :keepalives will use freeBSD's justification as their justification for
> :turning on TCP keepalives by default.
>
> Umm... that is about as twisted a reasoning as I could
> imagine.  I don't
> consider it a useful argument.  The sky might be falling too,
> better not
> go outside!
>
>   -Matt
>   Matthew Dillon
>   



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

Re: net.inet.tcp.always_keepalive on as default ?

[Matthew Dillon]

:At 01:08 PM 6/4/99 , Matthew Dillon wrote:
:>:had not been done, then the Internet would not have grown as it did today.
:>:
:>:The central issue of keepalives is that, for one machine, they don't create
:>:a significant load.  Multiplied by the number of machines on the Internet,
:>:it can become a problem.
:>
:> As I said.  People are arguing about keepalives without knowing how they
:> work.
:
:That's an excellent point!  People with less correct implementations of TCP
:keepalives will use freeBSD's justification as their justification for 
:turning on TCP keepalives by default.

Umm... that is about as twisted a reasoning as I could imagine.  I don't
consider it a useful argument.  The sky might be falling too, better not
go outside!

-Matt
Matthew Dillon 



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

Re: net.inet.tcp.always_keepalive on as default ?

[Peter Wemm]

Nate Williams wrote:
> > How about this then:
> > 
> > net.inet.tcp.always_keepidle: 86400 /* new variable */
> > net.inet.tcp.always_keepintvl: 64800/* new variable */
> > net.inet.tcp.keepidle: 14400
> > net.inet.tcp.keepintvl: 150
> > net.inet.tcp.always_keepalive: 1
> > 
> > This will have all sockets have keepalives, but if the program
> > specifically sets keepalives, it gets the shorter timeout.
> 
> That's essentially what I proposed a couple days ago.

I think the always_keepintvl values above are pretty over the top..  We
send a grand total of 8 keepalive packets every keepintvl slowtimeouts.
In the SO_KEEPALIVE case, after nothing has been received for 2 hours,
we send a keepalive packet every 75 seconds for a total of 8 times.  If
we still get nothing after 8 * 75 = 10 minutes, we drop the connection.

The example above is a bit far out because after 12 hours we'd probe and
retry every 540 minutes (9 hours) if there was no response for a total
of 8 times - 8 * 9 = 72 hours.  ie: it would take 3 days to clean a dead
connection based on a lousy sample of 8 packets over those 3 days.

I'd suggest always_keepidle = 86400 (12 hours) and always_keepinvl = 300
(20 minutes), and perhaps a new variable keepcnt and always_keepcnt
so that we can retry more than 8 times if you have lossy links.

IMHO, even the more aggressive existing keepalive values are so close to
trivially small amounts of traffic, I'd much rather use the 14400/150 values
for everything.  I'd be really *really* suprised if long idle tcp sessions
were statistically significant.  I know I have telnet sessions that can
have idle times of days, but compared to ftp/http/etc traffic it's a mere
drop in the ocean.  I can't think of any other common case of long idle
open tcp sessions other than telnet and co. 

> Nate
> 

Cheers,
-Peter



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

Re: net.inet.tcp.always_keepalive on as default ?

[Kevin J. Rowett]

At 01:08 PM 6/4/99 , Matthew Dillon wrote:
>:had not been done, then the Internet would not have grown as it did today.
>:
>:The central issue of keepalives is that, for one machine, they don't create
>:a significant load.  Multiplied by the number of machines on the Internet,
>:it can become a problem.
>
> As I said.  People are arguing about keepalives without knowing how they
> work.

That's an excellent point!  People with less correct implementations of TCP
keepalives will use freeBSD's justification as their justification for 
turning on TCP keepalives by default.

RFC1122 was written for a reason.  Before we repeal it, we should consider
why it was written in the first place.

BTW, I'm in favor of making keepalives on by default.  It will save me one
line in the boot up sequence.

KR



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

Re: net.inet.tcp.always_keepalive on as default ?

[Rodney W. Grimes]

> In message <37580f03.88efb...@sitara.net>, "John R. LoVerso" writes:
> 
> >But, consider going back to the discusssions leading up to the Host 
> >Requirements
> >RFC (1122).  The particular problem was that the original timeout value for
> >keepalives was tiny (a few minutes).  1122 dictated the corrections for 
> >this. 
> >Here are the important points from section 4.2.3.6:
> 
> But RFC 1122 pretty much entirely predates the "modern internet user".  While
> I fully supported the policy back then, I no longer do.
> 
> I still think the right thing is:
> 
>   default to keepalives.
>   set the timeout to a week.

Then lets go off a write RFC and get RFC1123 off the books, it's way
over due for an overhaul anyway.



-- 
Rod Grimes - KD7CAX - (RWG25)rgri...@gndrsh.dnsmgr.net


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

Re: net.inet.tcp.always_keepalive on as default ?

[Poul-Henning Kamp]

In message <199906042013.naa29...@implode.root.com>, David Greenman writes:
>>>   I don't support increasing the default timeout. That would cause problems
>>>for a lot of server systems that rely on the relatively short two hour 
>>>default.
>>>The best I think you could do would be to increase it to something like
>>>12-24 hours as a default, but even that might be problematical.
>>>   Actually, I think we should leave it alone. I don't mind if people add an
>>>rc.conf variable, however.
>>
>>First of all, our current default is not two hours, but to kill
>>after 4 hours idle followed by no response for 20min:
>>
>>  net.inet.tcp.keepidle: 14400
>>  net.inet.tcp.keepintvl: 150
>>
>>So anyone depending on two hours are screwed already.
>
>   I believe the above numbers are in slowtimo ticks (500ms), so if you do
>the math, you come up with 2 hours.

Oops, you're right.

--
Poul-Henning Kamp FreeBSD coreteam member
p...@freebsd.org   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


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

Re: net.inet.tcp.always_keepalive on as default ?

[Matthew Dillon]

:
:Around 0.02%, using the stats from one of BEST's busier servers.
:That's percent.

Oops, I wrong.  It's actually less then that... the network counters
overflowed.  More around 0.001%.  That's relative to outgoing traffic,
not relative to network capacity.  And, to be nice, I chose an 
administrative server instead of a web server.

Web servers have even *lower* keepalive bandwidth utilization.

-Matt
Matthew Dillon 



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

Re: net.inet.tcp.always_keepalive on as default ?

[David Greenman]

>>   I don't support increasing the default timeout. That would cause problems
>>for a lot of server systems that rely on the relatively short two hour 
>>default.
>>The best I think you could do would be to increase it to something like
>>12-24 hours as a default, but even that might be problematical.
>>   Actually, I think we should leave it alone. I don't mind if people add an
>>rc.conf variable, however.
>
>First of all, our current default is not two hours, but to kill
>after 4 hours idle followed by no response for 20min:
>
>   net.inet.tcp.keepidle: 14400
>   net.inet.tcp.keepintvl: 150
>
>So anyone depending on two hours are screwed already.

   I believe the above numbers are in slowtimo ticks (500ms), so if you do
the math, you come up with 2 hours.

-DG

David Greenman
Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org
Creator of high-performance Internet servers - http://www.terasolutions.com


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

Re: net.inet.tcp.always_keepalive on as default ?

[Matthew Dillon]

:had not been done, then the Internet would not have grown as it did today.
:
:The central issue of keepalives is that, for one machine, they don't create
:a significant load.  Multiplied by the number of machines on the Internet,
:it can become a problem.

As I said.  People are arguing about keepalives without knowing how they
work.

NO!  I will repeat that:  NO.  There is NO significant bandwidth.   Every
single machine on the entire internet could turn on keepalives and you
would not notice the difference.

Someone give me a sledgehammer!  No, make that two!

-Matt
Matthew Dillon 



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

Re: net.inet.tcp.always_keepalive on as default ?

[Matthew Dillon]

:Hint: If everybody turned on TCP keepalives, what percentage of the
:traffic on Internet backbones do you think would be keepalive
:packets?
:
:Jim Shankland
:NLynx Systems, Inc.

Around 0.02%, using the stats from one of BEST's busier servers.
That's percent.

In otherwords, nobody would notice.  You wouldn't notice, the backbones
wouldn't notice... nobody would notice.

-Matt
Matthew Dillon 



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

Re: net.inet.tcp.always_keepalive on as default ?

[Jim Shankland]

"Kevin J. Rowett"  writes:

> The central issue of keepalives is that, for one machine, they don't
> create a significant load.  Multiplied by the number of machines on
> the Internet, it can become a problem.

No offense, but that is the most ludicrous assertion I've heard since
Slobodan Milosevic claimed that all those bedraggled people streaming
across the Albanian border were actually actors being paid $5.50 per
day by NATO.

Hint: If everybody turned on TCP keepalives, what percentage of the
traffic on Internet backbones do you think would be keepalive
packets?

Jim Shankland
NLynx Systems, Inc.


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

Re: net.inet.tcp.always_keepalive on as default ?

[Garance A Drosihn]

At 11:24 AM -0700 6/4/99, David Greenman wrote:
> someone else wrote:
>>
>>  I still think the right thing is:
>>  default to keepalives.
>>  set the timeout to a week.
>
>   I don't support increasing the default timeout. That would cause
> problems for a lot of server systems that rely on the relatively
> short two hour default.  The best I think you could do would be to
> increase it to something like 12-24 hours as a default, but even
> that might be problematical.

This may be a stupid question, but I haven't shied away from asking
stupid questions before...

Do we have to consider this as an "on/off" switch?  Could we have
it an "on/off/extended" switch?  (or is the value stored as a bit
somewhere, so that it can only be on or off?).

What I'm thinking is that anything that explicitly asks for "on"
would get the current 2-hour timeout, but that the "extended"
setting would result in a 7-day timeout.  We'd then set the
system default to "extended" instead of either on or off.

Or would this break things in subtle ways?

---
Garance Alistair Drosehn   =   g...@eclipse.acs.rpi.edu
Senior Systems Programmer  or  dro...@rpi.edu
Rensselaer Polytechnic Institute


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

Re: net.inet.tcp.always_keepalive on as default ?

[Nate Williams]

> How about this then:
> 
>   net.inet.tcp.always_keepidle: 86400 /* new variable */
>   net.inet.tcp.always_keepintvl: 64800/* new variable */
>   net.inet.tcp.keepidle: 14400
>   net.inet.tcp.keepintvl: 150
>   net.inet.tcp.always_keepalive: 1
> 
> This will have all sockets have keepalives, but if the program
> specifically sets keepalives, it gets the shorter timeout.

That's essentially what I proposed a couple days ago.



Nate


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

Re: net.inet.tcp.always_keepalive on as default ?

[Poul-Henning Kamp]

In message <199906041824.laa29...@implode.root.com>, David Greenman writes:
>>In message <37580f03.88efb...@sitara.net>, "John R. LoVerso" writes:
>>
>>>But, consider going back to the discusssions leading up to the Host 
>>>Requirements
>>>RFC (1122).  The particular problem was that the original timeout value for
>>>keepalives was tiny (a few minutes).  1122 dictated the corrections for 
>>>this. 
>>>Here are the important points from section 4.2.3.6:
>>
>>But RFC 1122 pretty much entirely predates the "modern internet user".  While
>>I fully supported the policy back then, I no longer do.
>>
>>I still think the right thing is:
>>
>>  default to keepalives.
>>  set the timeout to a week.
>
>   I don't support increasing the default timeout. That would cause problems
>for a lot of server systems that rely on the relatively short two hour default.
>The best I think you could do would be to increase it to something like
>12-24 hours as a default, but even that might be problematical.
>   Actually, I think we should leave it alone. I don't mind if people add an
>rc.conf variable, however.

First of all, our current default is not two hours, but to kill
after 4 hours idle followed by no response for 20min:

net.inet.tcp.keepidle: 14400
net.inet.tcp.keepintvl: 150

So anyone depending on two hours are screwed already.

How about this then:

net.inet.tcp.always_keepidle: 86400 /* new variable */
net.inet.tcp.always_keepintvl: 64800/* new variable */
net.inet.tcp.keepidle: 14400
net.inet.tcp.keepintvl: 150
net.inet.tcp.always_keepalive: 1

This will have all sockets have keepalives, but if the program
specifically sets keepalives, it gets the shorter timeout.

--
Poul-Henning Kamp FreeBSD coreteam member
p...@freebsd.org   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


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

Re: net.inet.tcp.always_keepalive on as default ?

[Poul-Henning Kamp]

In message <4.2.0.56.19990604111235.00ae3...@rowett.org>, "Kevin J. Rowett" 
writes:

>The central issue of keepalives is that, for one machine, they don't create
>a significant load.  Multiplied by the number of machines on the Internet,
>it can become a problem.

Reality home-work assignment to Kevin:

If we send a total of 8 keep alive packets per week, for TCP
connections that last that long.  How many FreeBSD hackers
with long lived telnet/ssh sessions does it take to generate
as much trafic as one users IRC session ?

>If freeBSD makes it a default, then other will adopt as well.  Some less
>experienced and clueful implementors won't do as good a job with the
>overall TCP implementation, and we might see keepalives being sent
>every TCP timeout, for every connection, as a way to deal with a protocol
>error. :-)

... And the users, realizing this, will flock to FreeBSD and abandon all
other inferior products.



There we have it!

The way to kill windows NT is to make tcp keepalives the default
in FreeBSD, obviously, since NT is so bloddy unstable, Mickysoft
will have to use much shorter timeouts and people will notice that
NT soaks up all their bandwidth whereas FreeBSD doesn't.

Great!

And I guess we can corner Linux the same way, they have to reboot
for every security fix, so they have to have shorter timeouts as
well.



--
Poul-Henning Kamp FreeBSD coreteam member
p...@freebsd.org   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


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

Re: net.inet.tcp.always_keepalive on as default ?

[David Greenman]

>In message <37580f03.88efb...@sitara.net>, "John R. LoVerso" writes:
>
>>But, consider going back to the discusssions leading up to the Host 
>>Requirements
>>RFC (1122).  The particular problem was that the original timeout value for
>>keepalives was tiny (a few minutes).  1122 dictated the corrections for this. 
>>Here are the important points from section 4.2.3.6:
>
>But RFC 1122 pretty much entirely predates the "modern internet user".  While
>I fully supported the policy back then, I no longer do.
>
>I still think the right thing is:
>
>   default to keepalives.
>   set the timeout to a week.

   I don't support increasing the default timeout. That would cause problems
for a lot of server systems that rely on the relatively short two hour default.
The best I think you could do would be to increase it to something like
12-24 hours as a default, but even that might be problematical.
   Actually, I think we should leave it alone. I don't mind if people add an
rc.conf variable, however.

-DG

David Greenman
Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org
Creator of high-performance Internet servers - http://www.terasolutions.com


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

Re: net.inet.tcp.always_keepalive on as default ?

[Kurt D. Zeilenga]

At 07:56 PM 6/4/99 +0200, Poul-Henning Kamp wrote:
>I still think the right thing is:
>
>   default to keepalives.
>   set the timeout to a week.

OpenLDAP slapd, like may other daemons, relies on timeouts being a
reasonably short (a few hours) to deal with dead streams.  Dead
streams occur for a wide variety of reasons and erver applications
need an effective mechanisms to deal with them.  Changing the
timeout to a week would render the SO_KEEPALIVE mechanism
ineffective.

Personally, I advocate using sysctl (in rc files) to set the
default to on and leaving the kernel alone.

Kurt
  


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

Re: net.inet.tcp.always_keepalive on as default ?

[Kevin J. Rowett]

At 10:03 AM 6/4/99 , Matthew Dillon wrote:
> I think people just like to argue sometimes.  The reality is different.
>
> For all you people complaining:  Just turn them on and I guarentee
> you will not even notice the difference, except you will stop getting
> ( even the occassional ) stale internet server process.  That is what
> keepalives were designed to deal with.  Keepalives are not supposed to
> be a network watchdog, they are simply supposed to be a catch-all. 

This seems to be rather end-user, and short sighted.  TCP and the underlying
Internet has survived, and been able to scale (among other things), because
of the work of many to balance end-user performance and overall network
performance.

All the TCP congestion avoidance algorithms and work done go towards
managing a shared medium without a central point of control.  If this work
had not been done, then the Internet would not have grown as it did today.

The central issue of keepalives is that, for one machine, they don't create
a significant load.  Multiplied by the number of machines on the Internet,
it can become a problem.

If freeBSD makes it a default, then other will adopt as well.  Some less
experienced and clueful implementors won't do as good a job with the
overall TCP implementation, and we might see keepalives being sent
every TCP timeout, for every connection, as a way to deal with a protocol
error. :-)

KR



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

Re: net.inet.tcp.always_keepalive on as default ?

[Poul-Henning Kamp]

In message <37580f03.88efb...@sitara.net>, "John R. LoVerso" writes:

>But, consider going back to the discusssions leading up to the Host 
>Requirements
>RFC (1122).  The particular problem was that the original timeout value for
>keepalives was tiny (a few minutes).  1122 dictated the corrections for this. 
>Here are the important points from section 4.2.3.6:

But RFC 1122 pretty much entirely predates the "modern internet user".  While
I fully supported the policy back then, I no longer do.

I still think the right thing is:

default to keepalives.
set the timeout to a week.

--
Poul-Henning Kamp FreeBSD coreteam member
p...@freebsd.org   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


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

Re: net.inet.tcp.always_keepalive on as default ?

[John R. LoVerso]

> "32bit is enought for everthing"

Just mention the horrible header offset field.  Lots of good TCP nits.


Anyway, can't this argument be settled by separating the mechanism and policy. 
Adding a simple rc.conf tweak to enable them should be enough.


But, consider going back to the discusssions leading up to the Host Requirements
RFC (1122).  The particular problem was that the original timeout value for
keepalives was tiny (a few minutes).  1122 dictated the corrections for this. 
Here are the important points from section 4.2.3.6:

1. keepalives MUST default to off
2. the minimum timeout MUST be no less than two minutes
3. keep-alives SHOULD only be invoked in server applications

This mostly says that always_keepalive should continue to default to off (but,
perhaps, a easy hook in rc.conf should exist to turn them on).

John


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

Re: net.inet.tcp.always_keepalive on as default ?

[Matthew Dillon]

I think people just like to argue sometimes.  The reality is different.

For all you people complaining:  Just turn them on and I guarentee
you will not even notice the difference, except you will stop getting
( even the occassional ) stale internet server process.  That is what
keepalives were designed to deal with.  Keepalives are not supposed to
be a network watchdog, they are simply supposed to be a catch-all. 
So having per-socket adjustment is kind of silly.

-Matt



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

Re: net.inet.tcp.always_keepalive on as default ?

[Poul-Henning Kamp]

In message <199906041621.maa11...@khavrinen.lcs.mit.edu>, Garrett Wollman 
writes:
>< said:
>
>> Pierre, let me make the suggestion to you that you try turning them
>> on.  I'll bet you dollars to donoughts that you will not notice
>> the difference.
>
>Except when you happen to run into one of the inventors of TCP and he
>tells you what an dolt you appear to be...

Just tell him, (and make sure he can hear the quotes):

"32bit is enought for everthing"

--
Poul-Henning Kamp FreeBSD coreteam member
p...@freebsd.org   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


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

Re: net.inet.tcp.always_keepalive on as default ?

[David Malone]

> In message <19990604170654.a8...@salmon.maths.tcd.ie>, David Malone writes:
> 
> >It might be nice to have two keepalive timeouts like Nate suggested.
> >You'd have a short one, which applies if the application turns on
> >keepalive or you have alwayskeepalive on. Then you'd have a long
> >one, which applies to all connections regardless. Then:
> 
> Then you might as well implement per socket adjustable keepalives.

While this is probably a good idea anyway, you still have the
problem of setting these timeouts within applications for which you
don't have source and for which the current default isn't useful.
I guess this is the reason we have alwayskeepalive - if all
applications set keepalive when they needed it we wouldn't have
it at all.

If you had per socket adjustable keepalives you'd also have to
provide a tool which could set the keepalive timeout on a running
process to get the sort of effect provided by alwayskeepalive.
Having two timeouts would just be a compromise between these?

David.


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

Re: net.inet.tcp.always_keepalive on as default ?

[Garrett Wollman]

< said:

> Pierre, let me make the suggestion to you that you try turning them
> on.  I'll bet you dollars to donoughts that you will not notice
> the difference.

Except when you happen to run into one of the inventors of TCP and he
tells you what an dolt you appear to be...

-GAWollman



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

Re: net.inet.tcp.always_keepalive on as default ?

[Matthew Dillon]

:On Tue, Jun 01, 1999 at 03:02:47PM -0700, Matthew Dillon wrote:
:> I think keepalive's could easily be turned on by default.  At BEST, one
:> of the first things I did 5 years ago was to turn them on permanently 
:> on all of our machines.
:
:I'd like to disagree on the "by default" part, on the following
:..

Pierre, let me make the suggestion to you that you try turning them
on.  I'll bet you dollars to donoughts that you will not notice
the difference.

-Matt
Matthew Dillon 



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

Re: net.inet.tcp.always_keepalive on as default ?

[Poul-Henning Kamp]

In message <19990604170654.a8...@salmon.maths.tcd.ie>, David Malone writes:

>It might be nice to have two keepalive timeouts like Nate suggested.
>You'd have a short one, which applies if the application turns on
>keepalive or you have alwayskeepalive on. Then you'd have a long
>one, which applies to all connections regardless. Then:

Then you might as well implement per socket adjustable keepalives.

--
Poul-Henning Kamp FreeBSD coreteam member
p...@freebsd.org   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


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

Re: net.inet.tcp.always_keepalive on as default ?

[David Malone]

On Fri, Jun 04, 1999 at 03:32:02PM +0200, Pierre Beyssac wrote:

> I don't see what this fuss is all about. If for _some_ big servers
> there are many dead connections around after a while (*), why don't
> THEY use a sysctl at boot-time to change the default state, rather
> than impose on the rest of us a change that might not be as innocuous
> as it looks?

It might be nice to have two keepalive timeouts like Nate suggested.
You'd have a short one, which applies if the application turns on
keepalive or you have alwayskeepalive on. Then you'd have a long
one, which applies to all connections regardless. Then:

1) To get the traditional behavior you set the long one
to infinity and turn alwayskeepalive off.
2) To get the sort of behavior that phk is advocating,
without upsetting the rest of us you leave alwayskeepalive
off and then set the long one to 1 week.
3) For those of us with alwayskeepalive on, we'd get the
traditional value of a few hours.

Would this be a useful or a silly addition?

David.


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

Re: net.inet.tcp.always_keepalive on as default ?

[Sheldon Hearn]

Hi guys,

Since this isn't something everyone agrees on, how about adding a knob
to the boot time config files? This would make the keep-alive issue more
visible, and encourage folks to think about what they want.

Ciao,
Sheldon.


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

Re: net.inet.tcp.always_keepalive on as default ?

[Pierre Beyssac]

On Tue, Jun 01, 1999 at 03:02:47PM -0700, Matthew Dillon wrote:
> I think keepalive's could easily be turned on by default.  At BEST, one
> of the first things I did 5 years ago was to turn them on permanently 
> on all of our machines.

I'd like to disagree on the "by default" part, on the following
assumptions:

1.  If you turn on keepalive by default, you will
have to increase the keepalive timeout value
well over the current 2 hours (at least that's what
most people suggest to alleviate the concerns
about having keepalives on)
2.  Changing this default value of 2 hours will affect
ALL applications. Many of them (and their users)
are more or less expecting a 2 hours value. For
example that's the case for Telnet: probably you
don't want to wait for ONE WEEK before a connection
dies if you are currently using keepalives!

I don't see what this fuss is all about. If for _some_ big servers
there are many dead connections around after a while (*), why don't
THEY use a sysctl at boot-time to change the default state, rather
than impose on the rest of us a change that might not be as innocuous
as it looks?

(*) In theory, for a FTP server, most such connections will be
when the user does a PUT, not a GET. In a GET, the server has
data to push and will timeout anyway. In the case of the control
connection, there's a application timeout in most ftpds who
close the connection after some configurable amount of time.

> This used to be a HUGE argument in the days where networks were less 
> reliable and dialup lines were scarse.  It is not an argument now, 
> however.

Go explain that to my cable provider :-). Keeping a long-lived
connection through them is a real challenge; keepalives on would
make my life even more difficult.

> Whatever we do, we should not start messing around with the internals
> of the kernel trying to 'fix' a non-problem.  Keepalives work just dandy
> as they are currently implemented, we do not have to mess with it beyond
> possibly changing the default in rc.conf.

"possibly", but *only* as a last resort if there are good reasons
for it, IMHO. But I haven't seen any such reason yet.

I also think that having at least a kernel-wide (or better, having
it configurable on a per-socket basis), dynamically configurable
keepalive would be a good thing.
-- 
Pierre Beyssac  p...@enst.fr


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

Re: net.inet.tcp.always_keepalive on as default ?

[Nik Clayton]

On Wed, Jun 02, 1999 at 07:19:11PM +1200, Joe Abley wrote:
> I would take issue with that. All of the regional registries require
> extremely good justification for allocating static IP addresses to
> transient network connections.

Demon (a big ISP in .uk) allocate static IP addresses for *.demon.co.uk).
They have a number of class B's, and I believe that RIPE (European IP
registry) are quite happy with Demon's very efficient use of this space.

> Other times the reason is "so the customer can carry on downloading
> after the line dropped" to which the answer is "maintain your access
> servers properly and this won't happen".

Noise on the line, house mates inadvertently picking up the 'phone, plain
bad luck. . .

> Anyway, this is off-topic. Back to your scheduled programming.

Agreed, Reply-to: points back to me.

N
-- 
 [intentional self-reference] can be easily accommodated using a blessed,
 non-self-referential dummy head-node whose own object destructor severs
 the links.
-- Tom Christiansen in <37514...@cs.colorado.edu>


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

Re: net.inet.tcp.always_keepalive on as default ?

[Matthew Hunt]

On Wed, Jun 02, 1999 at 10:58:41PM +0200, Andre Oppermann wrote:
> Matthew Hunt wrote:
> > On Tue, Jun 01, 1999 at 01:59:48PM -0700, David Schwartz wrote:
> > 
> > >   I think he was suggesting that the apps close the connection if they
> > > receive no data from some amount of time. (Isn't this common sense?)
> > 
> > No, I frequently keep telnet/ssh connections idle for long periods,
> > and have no particular desire for them to close on me.
> 
> They don't close on you because keepalive would succeed. It would
> only drop your connection after the keepalive times out when you become
> unreachable by IP.

That's how keepalives work.  My understanding is that David Schwartz's
comment referred to application idle timeouts, not keepalives.

-- 
Matthew Hunt  * Stay close to the Vorlon.
http://www.pobox.com/~mph/   *


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

Re: net.inet.tcp.always_keepalive on as default ?

[Andre Oppermann]

Matthew Hunt wrote:
> 
> On Tue, Jun 01, 1999 at 01:59:48PM -0700, David Schwartz wrote:
> 
> >   I think he was suggesting that the apps close the connection if they
> > receive no data from some amount of time. (Isn't this common sense?)
> 
> No, I frequently keep telnet/ssh connections idle for long periods,
> and have no particular desire for them to close on me.

They don't close on you because keepalive would succeed. It would
only drop your connection after the keepalive times out when you become
unreachable by IP.

-- 
Andre Oppermann

CEO / Geschaeftsfuehrer
Internet Business Solutions Ltd. (AG)
Hardstrasse 235, 8005 Zurich, Switzerland
Fon +41 1 277 75 75 / Fax +41 1 277 75 77
http://www.pipeline.chi...@pipeline.ch


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

Re: net.inet.tcp.always_keepalive on as default ?

[Dag-Erling Smorgrav]

 writes:
> Is it that long? I honestly don't think I have ever seen one stay up for a
> week. Are you sure you did not mean 48 hours? I don't speak in jest.

49.7 days until an internal millisecond counter rolls around and
crashes the machine.

Microsoft have a patch out, but according to their web site, it's
untested.

I don't know what's worse; that Microsoft themselves can't keep
Windows running for 50 days, or that they're incapable of manually
bumping the counter to a value close to UINT_MAX and wait a few
minutes for it to roll over.

DES
-- 
Dag-Erling Smorgrav - d...@flood.ping.uio.no


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

Re: net.inet.tcp.always_keepalive on as default ?

[Joe Abley]

On Tue, Jun 01, 1999 at 02:16:55PM -0600, Nate Williams wrote:
> > this is less and less of a problem because
> > if you lose your link on PPP
> > you are liable to get a differetn IP address on your redial.
> 
> Not true.  Only if you're using a dynamic IP address setup.  Most
> business connections have a static connection, so they'll end up with
> the same IP address everytime.

I would take issue with that. All of the regional registries require
extremely good justification for allocating static IP addresses to
transient network connections.

This might be something that older, established providers are able to
do (since they were delegated way too many addresses in the good ol' days)
but it isn't an option for (m)any ISPs younger than three or four years.

When it comes down to it, there is very little justification for a static
address. The one I most commonly hear is "so we can do SMTP mail delivery
to the customer", but even that doesn't mandate use of static addressing --
we support SMTP mail delivery (we call it "mailbagging" for some reason)
to dynamically-addressed dial-up clients, and it works just fine.

Other times the reason is "so the customer can carry on downloading
after the line dropped" to which the answer is "maintain your access
servers properly and this won't happen".

Anyway, this is off-topic. Back to your scheduled programming.


Joe


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

Re: net.inet.tcp.always_keepalive on as default ?

[Ollivier Robert]

According to Matthew Hunt:
> I'm thinking of long-lived connections like telnet and ssh; if you're

FWIW ssh has been using keelalives for a long time by default...

   KeepAlive
  Specifies  whether the system should send keepalive
  messages to the other  side.   If  they  are  sent,
  death  of  the  connection  or  crash of one of the
  machines will be properly noticed.   However,  this
  means  that  connections  will  die if the route is
  down temporarily, and some people find it annoying.

  The  default is "yes" (to send keepalives), and the
  client will notice if the network goes down or  the
  remote  host  dies.   This is important in scripts,
  and many users want it too.

  To disable keepalives, the value should be  set  to
  "no"  in  both the server and the client configura-
  tion files.

-- 
Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr
FreeBSD keltia.freenix.fr 4.0-CURRENT #71: Sun May  9 20:16:32 CEST 1999



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

Re: net.inet.tcp.always_keepalive on as default ?

[Peter Jeremy]

Poul-Henning Kamp  wrote:
>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.

I think this sounds reasonable, but in this case, all the relevant
knobs need to be documented.  There's currently no documententation
strings for any of net.inet.tcp.keepidle, net.inet.tcp.keepintvl or
net.inet.tcp.keepinit.  It's also not immediately obvious that
these counters are all in 500msec intervals

I believe we should also add sysctl knobs for tcp_keepcnt and
tcp_maxpersistidle (the latter because it shares the same default
value - TCPTV_KEEP_IDLE - with tcp_keepidle).

And, whilst studying the code, I notice that the comments in
netinet/tcp_timer.h state:

 * an ack segment in response from the peer.  If, despite the TCPT_KEEP
 * initiated segments we cannot elicit a response from a peer in TCPT_MAXIDLE
 * amount of time probing, then we drop the connection.

But there's no variable or macro `TCPT_MAXIDLE'.  The connection is
dropped after tcp_maxidle = tcp_keepcnt [fixed at TCPTV_KEEPCNT=8] *
tcp_keepintvl [initially TCPTV_KEEPINTVL=75s, adjust via
net.inet.tcp.keepintvl].  Does one of the committers feel like fixing
this, or should I just send-pr it?

Matthew Hunt  wrote:
>I'm thinking of long-lived connections like telnet and ssh; if you're
>doing work over such a connection, it would be nice if the connection
>endured an outage while you're away sleeping, like it does without
>keepalives.

I'm not sure this point is valid.  An increasing percentage of such
connections will be using dynamic IP addresses - so you can't be sure
that you'll get the same address back.  And this presupposes that
neither system tries to send anything across the link whilst it's
dead.

Nate Williams  wrote:
>Off == 1 week KEEPALIVE
>ON  == traditiona 1 hour KEEPALIVe.
   ^^ 2 hours actually.

I think that definitely violates POLA.  If I have keepalives off (for
whatever reason), I expect there to be _no_ keepalives - not just less
frequent keepalives.  We'd need to make net.inet.tcp.always_keepalive a
3-way switch: on, off and 'i_dont_want_an...@%$!#@_keepalives' :-)

Poul-Henning Kamp  wrote:
>My intent was an "implementation" which would set:
>
>   net.inet.tcp.keepidle: 86400
12-hour keepalives.  That's different to previous suggestions :-).

>   net.inet.tcp.keepintvl: 64800
I don't see any real need to extend the default keepintvl.  I suspect
a slow burst (currently every 75 secs) is probably better than this
chinese water-torture approach.

Peter


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

Re: net.inet.tcp.always_keepalive on as default ?

[Matthew Dillon]

:...

Sheesh, talk about a topic to generate noise!

I think keepalive's could easily be turned on by default.  At BEST, one
of the first things I did 5 years ago was to turn them on permanently 
on all of our machines.

The reason is simple:  Without keepalives you can end up with stale
connections that hang forever due to users hanging up their modems without
disconnecting telnet, pop, and other assorted sessions.

Turning on keepalives will produce NO DISCERNABLE INCREASE IN NETWORK
TRAFFIC.  Period.  Anybody who says they do doesn't understand how 
keepalives work.  You could have a thousand active connections and
it still wouldn't show a discernable increase.

Daemons do not usually bother to turn on per-connection keepalives.  I
do not consider this a bug in the daemon, but instead simply a "the default
nature of this daemon is to use the default keepalive state assigned to
the system as a whole".  Simple.  Not a bug.  We should NOT go around
trying to 'fix' all of our daemons.

The only argument against turning on keepalives by default is that 
occassionally someone will expect their telnet to hang around after the
network inbetween them and the remote site has been down for hours.

This used to be a HUGE argument in the days where networks were less 
reliable and dialup lines were scarse.  It is not an argument now, 
however.

Whatever we do, we should not start messing around with the internals
of the kernel trying to 'fix' a non-problem.  Keepalives work just dandy
as they are currently implemented, we do not have to mess with it beyond
possibly changing the default in rc.conf.

-Matt
Matthew Dillon 



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

Re: net.inet.tcp.always_keepalive on as default ?

[sthaug]

> > maybe we should fix our SERVER apps..
> > e.g. telnetd, sshd, etc. to have 1 week timeouts
> 
> IIRC, it is not possible to specify how long the keepalive interval
> should be, using the socket interface.  Do you suggest we add a new
> interface not present in other Unix implementations, or that we make
> SO_KEEPALIVE always have a one-week timeout, surprising the other
> applications that expect it to be faster?

There *is* a well defined interface for this, namely the TCP_KEEPALIVE
socket option. This is a *per connection* keepalive timer, and is
implemented by for instance Solaris 2.6. See

  http://www.unix-systems.org/single_unix_specification_v2/xns/xti.h.html

Also mentioned in Stevens vol. 2 as far as I can remember.

If the FreeBSD kernel implemented TCP_KEEPALIVE, it would be rather
simple to set this on an application basis. (No, unfortunately, I'm
not offering to implement it.)

Steinar Haug, Nethelp consulting, sth...@nethelp.no


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

Re: net.inet.tcp.always_keepalive on as default ?

[Sudish Joseph]

Poul-Henning Kamp writes:
> Mind you, this is only a problem because FreeBSD is to bloddy
> stable:  I logged into a customers server a few days a go, it had
> been up for over a year, and had accumulated tons of ftpds from

If this customer is using wu-ftpd, it's very possible that you saw
daemons blocked inside of accept() for PASV data connections.  We used
to see the same behavior here wrt. ftpds hanging around and it was
almost always the case that the socket was in the LISTEN state.

The code (ftpd.c:dataconn()) was changed to time out the data
connection establishment using select() before calling accept().  If
the client doesn't connect within 15 minutes, we log the event and the
daemon exits.  A diff against our code wouldn't be helpful, since
we've added our own ugly warts to it (but I'll do so if you want it).

If this is indeed the same problem you're seeing, tcp keepalives won't
help.  I haven't looked at the FreeBSD ftpd code to see if the accept
is timed out somehow to prevent this (possibly inadvertent) DOS attack.

-- 
Sudish Joseph  MindSpring Enterprises


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

RE: net.inet.tcp.always_keepalive on as default ?

[kip]

This does make sense. I do some work on a mail server and I don't use
keepalives because 2 hours is _too_much_ time to be wasting a descriptor. 
I periodically check how long a connection has been open and if it exceeds
a certain amount I close the connection.

-Kip 

On Tue, 1 Jun 1999, David Schwartz wrote:

> 
>   I think he was suggesting that the apps close the connection if they
> receive no data from some amount of time. (Isn't this common sense?)
> 
>   DS
> 
> > On Tue, Jun 01, 1999 at 01:30:31PM -0700, Julian Elischer wrote:
> >
> > > maybe we should fix our SERVER apps..
> > > e.g. telnetd, sshd, etc. to have 1 week timeouts
> >
> > IIRC, it is not possible to specify how long the keepalive interval
> > should be, using the socket interface.  Do you suggest we add a new
> > interface not present in other Unix implementations, or that we make
> > SO_KEEPALIVE always have a one-week timeout, surprising the other
> > applications that expect it to be faster?
> >
> > Both of these seem remarkably unappealing to me.
> >
> > Matt
> >
> > --
> > Matthew Hunt  * Inertia is a property
> > http://www.pobox.com/~mph/   * of matter.
> >
> >
> > To Unsubscribe: send mail to majord...@freebsd.org
> > with "unsubscribe freebsd-current" in the body of the message
> >
> 
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-current" in the body of the message
> 
> 




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

RE: net.inet.tcp.always_keepalive on as default ?

[David Schwartz]

Yes, exactly, everybody wants something different. That's why you don't
want to enforce a new policy in the kernel. Let each app choose the policy
that makes the most sense for it, either with or without command line
options or whatnot.

But an application that is not happy with the default TCP timeout 
semantics
and doesn't enforce something else is broken.

DS

> On Tue, Jun 01, 1999 at 01:59:48PM -0700, David Schwartz wrote:
>
> > I think he was suggesting that the apps close the connection if they
> > receive no data from some amount of time. (Isn't this common sense?)
>
> No, I frequently keep telnet/ssh connections idle for long periods,
> and have no particular desire for them to close on me.
>
> --
> Matthew Hunt  * Stay close to the Vorlon.
> http://www.pobox.com/~mph/   *
>



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

Re: net.inet.tcp.always_keepalive on as default ?

[Matthew Hunt]

On Tue, Jun 01, 1999 at 01:59:48PM -0700, David Schwartz wrote:

>   I think he was suggesting that the apps close the connection if they
> receive no data from some amount of time. (Isn't this common sense?)

No, I frequently keep telnet/ssh connections idle for long periods,
and have no particular desire for them to close on me.

-- 
Matthew Hunt  * Stay close to the Vorlon.
http://www.pobox.com/~mph/   *


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

RE: net.inet.tcp.always_keepalive on as default ?

[David Schwartz]

I think he was suggesting that the apps close the connection if they
receive no data from some amount of time. (Isn't this common sense?)

DS

> On Tue, Jun 01, 1999 at 01:30:31PM -0700, Julian Elischer wrote:
>
> > maybe we should fix our SERVER apps..
> > e.g. telnetd, sshd, etc. to have 1 week timeouts
>
> IIRC, it is not possible to specify how long the keepalive interval
> should be, using the socket interface.  Do you suggest we add a new
> interface not present in other Unix implementations, or that we make
> SO_KEEPALIVE always have a one-week timeout, surprising the other
> applications that expect it to be faster?
>
> Both of these seem remarkably unappealing to me.
>
> Matt
>
> --
> Matthew Hunt  * Inertia is a property
> http://www.pobox.com/~mph/   * of matter.
>
>
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-current" in the body of the message
>



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

Re: net.inet.tcp.always_keepalive on as default ?

[Matthew Hunt]

On Tue, Jun 01, 1999 at 01:30:31PM -0700, Julian Elischer wrote:

> maybe we should fix our SERVER apps..
> e.g. telnetd, sshd, etc. to have 1 week timeouts

IIRC, it is not possible to specify how long the keepalive interval
should be, using the socket interface.  Do you suggest we add a new
interface not present in other Unix implementations, or that we make
SO_KEEPALIVE always have a one-week timeout, surprising the other
applications that expect it to be faster?

Both of these seem remarkably unappealing to me.

Matt

-- 
Matthew Hunt  * Inertia is a property
http://www.pobox.com/~mph/   * of matter.


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

RE: net.inet.tcp.always_keepalive on as default ?

[Julian Elischer]

maybe we should fix our SERVER apps..
e.g. telnetd, sshd, etc. to have 1 week timeouts


On Tue, 1 Jun 1999, David Schwartz wrote:

> 
>   Why not just fix the application programs that really want timeouts but
> don't implement them?
> 
>   DS
> 
> > Mind you, this is only a problem because FreeBSD is to bloddy
> > stable:  I logged into a customers server a few days a go, it had
> > been up for over a year, and had accumulated tons of ftpds from
> > WIN* machines which had gotten a vulcan nerve pinch or a different
> > IP#.  (I'm sure windows NT servers doesn't have this problem at
> > all)
> >
> > It doesn't have to be 2h timeout.  I would be happy with a default
> > of 24h, even one week would be OK with me.
> >
> > But infinity is too long for my taste.
> >
> > Can people live with a one week TCP keepalive as default ?
> 
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-current" in the body of the message
> 



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

Re: net.inet.tcp.always_keepalive on as default ?

[kip]

Is it that long? I honestly don't think I have ever seen one stay up for a
week. Are you sure you did not mean 48 hours? I don't speak in jest.

-Kip 


On Tue, 1 Jun 1999, Julian Elischer wrote:

> how about a keepalive of 48 days.. the maximum a W95 machine can stay
> alive... :-)
> 
> 
> 
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-current" in the body of the message
> 
> 




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

Re: net.inet.tcp.always_keepalive on as default ?

[Poul-Henning Kamp]

In message <19990601212045.a13...@bell.maths.tcd.ie>, David Malone writes:
>On Tue, Jun 01, 1999 at 02:15:05PM -0600, Nate Williams wrote:
>> > Can people live with a one week TCP keepalive as default ?
>> 
>> Compromise.  I like it.  One week is certainly adequate for me.  If I
>> leave a link 'active' for longer than that w/out activity, I deserve to
>> lose the link
>
>Surely that violates POLA? That upsets people who have keepalive
>turned on already and find 1 week is way too long. For instance,
>we use keepalive to get rid of stuck netscapes, and we'd probably
>run out of swap or mbufs if it went up to a week. We just managed
>by putting this in rc.local:
>
>sysctl -w net.inet.tcp.always_keepalive=1

My intent was an "implementation" which would set:

net.inet.tcp.keepidle: 86400
net.inet.tcp.keepintvl: 64800
net.inet.tcp.always_keepalive: 1

Leaving people to set whatever they want for a local policy.

All I'm talking about is what our default should be...

--
Poul-Henning Kamp FreeBSD coreteam member
p...@freebsd.org   "Real hackers run -current on their laptop."
FreeBSD -- It will take a long time before progress goes too far!


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

Re: net.inet.tcp.always_keepalive on as default ?

[Nate Williams]

> > > Can people live with a one week TCP keepalive as default ?
> > 
> > Compromise.  I like it.  One week is certainly adequate for me.  If I
> > leave a link 'active' for longer than that w/out activity, I deserve to
> > lose the link
> 
> Surely that violates POLA? That upsets people who have keepalive
> turned on already and find 1 week is way too long. For instance,
> we use keepalive to get rid of stuck netscapes, and we'd probably
> run out of swap or mbufs if it went up to a week. We just managed
> by putting this in rc.local:
> 
> sysctl -w net.inet.tcp.always_keepalive=1

As I understand it, it would always on, and 'one-week' would be the
default.  Old (traditional) programs that turned it on would be given
the 'traditional' timeout of 1 hour.

Or something like that.

Off == 1 week KEEPALIVE
ON  == traditiona 1 hour KEEPALIVe.


Nate


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

Re: net.inet.tcp.always_keepalive on as default ?

[Julian Elischer]

how about a keepalive of 48 days.. the maximum a W95 machine can stay
alive... :-)





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

Re: net.inet.tcp.always_keepalive on as default ?

[David Malone]

On Tue, Jun 01, 1999 at 02:15:05PM -0600, Nate Williams wrote:
> > Can people live with a one week TCP keepalive as default ?
> 
> Compromise.  I like it.  One week is certainly adequate for me.  If I
> leave a link 'active' for longer than that w/out activity, I deserve to
> lose the link

Surely that violates POLA? That upsets people who have keepalive
turned on already and find 1 week is way too long. For instance,
we use keepalive to get rid of stuck netscapes, and we'd probably
run out of swap or mbufs if it went up to a week. We just managed
by putting this in rc.local:

sysctl -w net.inet.tcp.always_keepalive=1

Make it a rc.conf knob if anything.

David.


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

Re: net.inet.tcp.always_keepalive on as default ?

[kip]

That is a much more genuine concern than bandwidth. Applications should
decide for themselves whether or not to use keepalives.

-Kip
On Tue, 1 Jun 1999, Matthew Hunt wrote:

> On Tue, Jun 01, 1999 at 12:40:34PM -0700, k...@lyris.com wrote:
> 
> > declared dead. I think it somewhat silly to say that this is consuming a
> > lot of bandwidth. The average mail message (4k) is 4 packets, the average
> 
> The other issue is that you don't necessarily want the TCP connection
> to close just because you lose connectivity for a few hours.  If we
> send keepalives by default, might that not surprise users who don't
> expect it?
> 
> I'm thinking of long-lived connections like telnet and ssh; if you're
> doing work over such a connection, it would be nice if the connection
> endured an outage while you're away sleeping, like it does without
> keepalives.
> 
> -- 
> Matthew Hunt  * UNIX is a lever for the
> http://www.pobox.com/~mph/   * intellect. -J.R. Mashey
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-current" in the body of the message
> 
> 




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

RE: net.inet.tcp.always_keepalive on as default ?

[David Schwartz]

> Saying that it should be an application function is bogus in my
> book, since the problem is valid for all TCP users, and there are
> clearly not any reason to duplicate the code in telnetd, ftpd,
> talkd, &c &c.

But the problem is that every application uses TCP a little bit
differently, and so the type of timeout logic that is appropriate for one
application is not the same as the timeout that's appropriate for another.
What type of timeout you want in a TCP connection really depends upon what
you are going to do with it, and that the kernel cannot know.

If an application does not timeout a TCP connection in a sane way, it is
broken. It should be fixed. 'Fixing' it in the kernel simply allows the
application to remain broken.

DS



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

RE: net.inet.tcp.always_keepalive on as default ?

[David Schwartz]

Why not just fix the application programs that really want timeouts but
don't implement them?

DS

> Mind you, this is only a problem because FreeBSD is to bloddy
> stable:  I logged into a customers server a few days a go, it had
> been up for over a year, and had accumulated tons of ftpds from
> WIN* machines which had gotten a vulcan nerve pinch or a different
> IP#.  (I'm sure windows NT servers doesn't have this problem at
> all)
>
> It doesn't have to be 2h timeout.  I would be happy with a default
> of 24h, even one week would be OK with me.
>
> But infinity is too long for my taste.
>
> Can people live with a one week TCP keepalive as default ?



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