From owner-freebsd-current@FreeBSD.ORG Fri Jan 9 07:30:50 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 2449A16A4CE; Fri, 9 Jan 2004 07:30:50 -0800 (PST) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9667143D1F; Fri, 9 Jan 2004 07:30:24 -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) i09FUFN1036846 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 9 Jan 2004 16:30:21 +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 i09FU74H026509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Jan 2004 16:30:07 +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 i09FU7BE001264; Fri, 9 Jan 2004 16:30:07 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.10/8.12.10/Submit) id i09FU64N001263; Fri, 9 Jan 2004 16:30:06 +0100 (CET) (envelope-from ticso) Date: Fri, 9 Jan 2004 16:30:06 +0100 From: Bernd Walter To: Andre Oppermann Message-ID: <20040109153005.GQ51502@cicely12.cicely.de> References: <20040109085522.GB4246@tybalt.nev.psi.de> <3FFE8232.730F70B8@freebsd.org> <20040109132453.GD2031@tybalt.nev.psi.de> <3FFEB979.3C705A85@freebsd.org> <20040109150625.GP51502@cicely12.cicely.de> <3FFEC4E2.96DF5ED@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FFEC4E2.96DF5ED@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: ticso@cicely.de 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:30:50 -0000 On Fri, Jan 09, 2004 at 04:12:34PM +0100, Andre Oppermann wrote: > Bernd Walter wrote: > > > > 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. > > If the microcontroller doesn't have enough RAM to do delayed ACKs > I highly doubt that it is capable to generate 1,000 packet per > second. I'm personally running controllers at 16MIPS with only 1k RAM doing TCP over slip and I also run controllers with 4k RAM over Ethernet with the same IP Stack because I need most of the 4k for other things. 1,000 packets/s is not impossible for simplified IP systems. > The detection logic only applies to TCP packets containing payload, > not to ACKs or anything else. OK - thats sound great - also I've read that MTU 300 is not a problem by itself as the trigger value is smaller. But what I do in one application is modbus protocol, which has a packet payload of something around 10 to 256 bytes - small sizes are more common. The protocol has his ancours is half duplex serial lines and waits for response on each command so packet aggregation is impossible. It defines interleaving over TCP, but implementation isn't a requirement. See www.modbus.org for details. For the same reasons I could easily imagine RPC over TCP to create small packets. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de