Re: RE: net.inet.tcp.always_keepalive on as default ?
: 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: RE: net.inet.tcp.always_keepalive on as default ?
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: net.inet.tcp.always_keepalive on as default ?
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: net.inet.tcp.always_keepalive on as default ?
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 http://www.mathematik.uni-ulm.de/~kuebart/kuebart.asc 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 ?
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: RE: net.inet.tcp.always_keepalive on as default ?
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: } On Sat, 5 Jun 1999 16:09:00 -0400 (EDT), Brian Feldman gr...@unixhelp.org 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: RE: net.inet.tcp.always_keepalive on as default ?
On Tue, Jun 08, 1999 at 06:07:23AM -0700, Don Lewis don.le...@tsc.tdk.com 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 ?
:} 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 dil...@backplane.com 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 ?
On Tue, Jun 08, 1999 at 11:23:26AM -0700, Matthew Dillon dil...@apollo.backplane.com 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 ?
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: net.inet.tcp.always_keepalive on as default ?
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 ?
: :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: RE: net.inet.tcp.always_keepalive on as default ?
: 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 dil...@backplane.com 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 ?
: : 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: net.inet.tcp.always_keepalive on as default ?
: 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 ?
:On Sat, 5 Jun 1999 20:13:56 -0400 (EDT), Brian Feldman gr...@unixhelp.org 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 ?
: : 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: net.inet.tcp.always_keepalive on as default ?
: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 dil...@backplane.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 ?
From: Matthew Dillon dil...@apollo.backplane.com 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 ?
: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 ?
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: RE: net.inet.tcp.always_keepalive on as default ?
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 m...@astro.caltech.edu * 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 ?
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: net.inet.tcp.always_keepalive on as default ?
Joel Ray Holveck jo...@gnu.org 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 ?
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 ?
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 ?
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 ?
=+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 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 ?
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: RE: net.inet.tcp.always_keepalive on as default ?
: 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 dil...@backplane.com 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 ?
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 ?
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 dil...@backplane.com 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 ?
On Sat, 5 Jun 1999 16:09:00 -0400 (EDT), Brian Feldman gr...@unixhelp.org 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 ?
On Sat, 5 Jun 1999, Garrett Wollman wrote: On Sat, 5 Jun 1999 16:09:00 -0400 (EDT), Brian Feldman gr...@unixhelp.org 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: net.inet.tcp.always_keepalive on as default ?
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 ?
Garrett Wollman scribbled this message on Jun 5: On Sat, 5 Jun 1999 16:09:00 -0400 (EDT), Brian Feldman gr...@unixhelp.org 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 ?
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 ?
On Sat, 5 Jun 1999 20:13:56 -0400 (EDT), Brian Feldman gr...@unixhelp.org 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 ?
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: net.inet.tcp.always_keepalive on as default ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
: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 dil...@backplane.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 ?
On Fri, 4 Jun 1999 09:17:16 -0700 (PDT), Matthew Dillon dil...@apollo.backplane.com 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 ?
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 ?
In message 199906041621.maa11...@khavrinen.lcs.mit.edu, Garrett Wollman writes: On Fri, 4 Jun 1999 09:17:16 -0700 (PDT), Matthew Dillon dil...@apollo.backplane.com 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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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. IRONY 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. /IRONY -- 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 ?
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 ?
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 ?
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 ?
Kevin J. Rowett krow...@rowett.org 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 ?
: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 dil...@backplane.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 ?
: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 dil...@backplane.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 ?
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 ?
: :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 dil...@backplane.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 ?
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 ?
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 ?
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 ?
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 ?
: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 dil...@backplane.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 ?
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 dil...@backplane.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 ?
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 ?
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 21 fi +if [ X$tcp_keepalive = XYES ]; then + echo -n ' TCP keepalive=YES' + sysctl -w net.inet.tcp.always_keepalive=1 /dev/null 21 +fi + if [ X$ipxgateway_enable = XYES ]; then echo -n ' IPX gateway=YES' sysctl -w net.ipx.ipx.ipxforwarding=1 /dev/null 21 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 ?
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 ?
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 ?
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 ?
k...@lyris.com 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 ?
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 ?
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 m...@astro.caltech.edu * 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 ?
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. Setting this will make all TCP connections send a probing ACK every couple of hours if no other activity were present on the connection, this enables the TCP stack to figure out if the other end has gone or is still there. The typical symptom that you need this is that netstat shows many connections which have been standing there for any amount of time up to your uptime, simply because your machine is waiting to receive something from the other end, and for all practical purposes, the other end doesn't exist anymore. I have no problem with this, though the traffic load created by the aggregate base of installed FreeBSD boxes over the global internet might even be measurable :-). The argument against is that this will increas trafic and keep dynamic lines up when they should otherwise have been allowed to fall down. The former argument doesn't hold water, since we're talking about a TCP segment per hour (or less) per connection. The second argument falls on the same reasoning in my book, I don't know of any on-demand lines with a timeout longer than 10 minutes anyway. Well, we run many at 1 to 3 hours, but then they have ``activity filters'' that could be tweaked to not consider these packets as real traffic so they would still timeout. I would rather save the connection table for things that are useful than save a few port/hours of connect time :-). This may have more drastic effects for others though. -- Rod Grimes - KD7CAX - (RWG25) rgri...@gndrsh.aac.dev.com Accurate Automation, Inc. Reliable computers for FreeBSD http://www.aai.dnsmgr.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 ?
Considering the number of hosts on the net today, which come and go with no warning and with dynamic IP assignments, I would propose that we disregard what the old farts felt about TCP keepalives, and enable the sysctl net.inet.tcp.always_keepalive as default. Seeing as the amount of traffic and congestion in the Internet, I propose we diregard what the 'old fart' PHK says and not increase the congestion with the use of keepalives. :) The 'old farts' did a good job of designing a system that happens to work better than all of the systems the 'young farts' were able to design. PHK's arguments are specious, since *any* traffic when the link is congested is more congestion. The argument against is that this will increas trafic and keep dynamic lines up when they should otherwise have been allowed to fall down. The former argument doesn't hold water, since we're talking about a TCP segment per hour (or less) per connection. That's still traffic, and congestion is congestion. On one systems that isn't a lot, but with alot of connections it can add up to a significant amount of bandwidth. The second argument falls on the same reasoning in my book, I don't know of any on-demand lines with a timeout longer than 10 minutes anyway. You don't know of any, but that doesn't mean they don't exist. Nate To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-current in the body of the message
Re: net.inet.tcp.always_keepalive on as default ?
From: Poul-Henning Kamp p...@freebsd.org Date: Tue, 01 Jun 1999 20:41:00 +0200 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. we should consult with hte tcp-impl mailing list and get their take on the matter before we decide what to do here. the address is tcp-i...@grc.nasa.gov. jmb 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 ?
I think it is fair to say that the nature of the internet has changed somewhat since the standards were made. Keepalives by default are not sent until after two hours, if they are acknowledged no more packets are sent. If not 10 more probes are sent 75 seconds apart before the connection is 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 telnet session is at least several hundred and an ftp session is going to be many, many more. Back in the day when people were arguing about the congestion it would create a 300baud modem was considered completely normal. Nowadays, when the average gaudy web page is 20k (read ~20 1k packets) it is safe to say that things have changed. -Kip On Tue, 1 Jun 1999, Nate Williams 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. Seeing as the amount of traffic and congestion in the Internet, I propose we diregard what the 'old fart' PHK says and not increase the congestion with the use of keepalives. :) The 'old farts' did a good job of designing a system that happens to work better than all of the systems the 'young farts' were able to design. PHK's arguments are specious, since *any* traffic when the link is congested is more congestion. The argument against is that this will increas trafic and keep dynamic lines up when they should otherwise have been allowed to fall down. The former argument doesn't hold water, since we're talking about a TCP segment per hour (or less) per connection. That's still traffic, and congestion is congestion. On one systems that isn't a lot, but with alot of connections it can add up to a significant amount of bandwidth. The second argument falls on the same reasoning in my book, I don't know of any on-demand lines with a timeout longer than 10 minutes anyway. You don't know of any, but that doesn't mean they don't exist. Nate To Unsubscribe: send mail to 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 ?
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 m...@astro.caltech.edu * 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 ?
... and keep dynamic lines up when they should otherwise have been allowed to fall down. [...] The second argument falls on the same reasoning in my book, I don't know of any on-demand lines with a timeout longer than 10 minutes anyway. But it will bring the line back *up*, to no useful purpose. Always think very hard before messing with TCP. And then don't. Matt Crawford 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 ?
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 ? -- 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 ?
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. for network outages in the middle it works though.. but I'd rather have a keepalive of 10 x 4 hour pings before failure.. (or something as long..) It's really a per-connection decision on what makes sense julian 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 m...@astro.caltech.edu * 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 ?
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 ? 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 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 ?
In message 19990601192912.68cc115...@hub.freebsd.org, Jonathan M. Bresler w rites: we should consult with hte tcp-impl mailing list and get their take on the matter before we decide what to do here. the address is tcp-i...@grc.nasa.gov. I already did, but it is such a hot issue that they don't get into it. A good summary of the traditionalist view can be found in: http://tcp-impl.grc.nasa.gov/tcp-impl/list/archive/1246.html I agree in principle, but not in practice. Having no keep-alives just doesn't work when WIN* boxes drop carrier and get another IP# when they come back, or when they just randomly crashes... 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. Of course if the application has particular hysteric requirements (ircd anyone) it can implement its own methods 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 ?
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. for network outages in the middle it works though.. but I'd rather have a keepalive of 10 x 4 hour pings before failure.. (or something as long..) I think PHK's one-week KEEPALIVE is acceptable to me. It lets me logon to freefall and have the link go bad overnight, yet still keep me on in the morning when I check it. Nate It's really a per-connection decision on what makes sense julian 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 m...@astro.caltech.edu * 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 ?
In message 199906012011.paa16...@gungnir.fnal.gov, Matt Crawford writes: ... and keep dynamic lines up when they should otherwise have been allowed to fall down. [...] The second argument falls on the same reasoning in my book, I don't know of any on-demand lines with a timeout longer than 10 minutes anyway. But it will bring the line back *up*, to no useful purpose. set your filters 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 ?
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
RE: net.inet.tcp.always_keepalive on as default ?
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 ?
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 m...@astro.caltech.edu * 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 ?
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 ?
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 ?
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 ?
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
