From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 07:06:44 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E61A916A4CE; Fri, 9 Jan 2004 07:06:43 -0800 (PST) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 539C843D54; Fri, 9 Jan 2004 07:06:40 -0800 (PST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) (authenticated bits=0) i09F6ZN1036603 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 9 Jan 2004 16:06:37 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id i09F6Q4H026333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Jan 2004 16:06:27 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.10/8.12.10) with ESMTP id i09F6QBE001213; Fri, 9 Jan 2004 16:06:26 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.10/8.12.10/Submit) id i09F6QlA001212; Fri, 9 Jan 2004 16:06:26 +0100 (CET) (envelope-from ticso) Date: Fri, 9 Jan 2004 16:06:26 +0100 From: Bernd Walter To: Andre Oppermann Message-ID: <20040109150625.GP51502@cicely12.cicely.de> References: <20040109085522.GB4246@tybalt.nev.psi.de> <3FFE8232.730F70B8@freebsd.org> <20040109132453.GD2031@tybalt.nev.psi.de> <3FFEB979.3C705A85@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FFEB979.3C705A85@freebsd.org> X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.4i X-Spam-Status: No, hits=-4.9 required=3.0 tests=BAYES_00 autolearn=ham version=2.61 X-Spam-Report: * -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on cicely5.cicely.de cc: Thorsten Greiner cc: current@freebsd.org Subject: Re: the TCP MSS resource exhaustion commit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2004 15:06:44 -0000 On Fri, Jan 09, 2004 at 03:23:53PM +0100, Andre Oppermann wrote: > Thorsten Greiner wrote: > > > > * Andre Oppermann [2004-01-09 11:34]: > > > You can simply increase net.inet.tcp.minmssoverload to any > > > higher value. I suggest 2,000 as next step. If set it to > > > 0 the check will be disabled entirely. > > > > Setting net.inet.tcp.minmssoverload to 4000 fixed my problem(s). > > Ok, that's an important information. > > > > This makes we wonder why the Oracle database server is sending > > > so many small packets. Is your JBoss application doing connection > > > pooling (eg. multiplexing multiple SQL sessions over one tcp > > > session)? > > > > It performs connection pooling on the application layer, i.e. it > > opens several connections and pools them to avoid reopening them. As > > far as I understand each Oracle connection is associated with a TCP > > connection - there is no pooling on the TCP level. > > Ok. Might it be that Oracle is setting the TCP_NODELAY option on > its sending socket? I guess it is difficult to find that out... > > > While I have read your commit message thoroughly I am not sure I > > have understood the consequences of the new mechanism. Will the > > exchange of many small packets trigger a connection drop? > > Yes. Once you receive more than 1,000 tcp packets per second whose > average size is below the net.inet.tcp.minmss value, then it will > assume a malicious DoS attack. It appears that the default value > of 1,000 is too low. What about ACKs from a simple TCP device such as a microcontroller? Or slip connects with MTU of 300? Many smaller controllers don't have enough RAM to do delayed acks or run at MTU 1500. Even a hand full public webservers are running on such systems! I'm a bit worried about having such a feature enabled by default to break TCP communication with specialised hardware. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de