From owner-freebsd-net@FreeBSD.ORG Mon Aug 15 12:19:39 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0CDE0106566C; Mon, 15 Aug 2011 12:19:39 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 60DF78FC14; Mon, 15 Aug 2011 12:19:38 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Qsw8m-000L4e-Ix; Mon, 15 Aug 2011 16:19:36 +0400 Date: Mon, 15 Aug 2011 16:19:36 +0400 From: Slawa Olhovchenkov To: Arnaud Lacombe Message-ID: <20110815121936.GY94016@zxy.spb.ru> References: <4E37C0F2.4080004@freebsd.org> <2B063B6D95AA4C27B004C50D96393F91@multiplay.co.uk> <4E3AA66A.6060605@freebsd.org> <20110805065743.GC94016@zxy.spb.ru> <4E4330B5.5030100@freebsd.org> <20110811123102.GQ94016@zxy.spb.ru> <4E43DA31.7000605@freebsd.org> <20110811135454.GR94016@zxy.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: Lawrence Stewart , Andre Oppermann , Steven Hartland , freebsd-net@freebsd.org Subject: Re: tcp failing to recover from a packet loss under 8.2-RELEASE? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Aug 2011 12:19:39 -0000 On Fri, Aug 12, 2011 at 11:32:36AM -0400, Arnaud Lacombe wrote: > Hi, > > On Thu, Aug 11, 2011 at 9:54 AM, Slawa Olhovchenkov wrote: > > On Thu, Aug 11, 2011 at 11:33:37PM +1000, Lawrence Stewart wrote: > > > >> >>> Autotunig w/o limits is bad idea. This is way to DoS. > >> >> > >> >> Depends how it is implemented. With appropriate backpressure mechanisms > >> >> put in place, it could be perfectly safe. I envisage reassembly segments > >> >> being at the bottom of the heap in terms of importance, so if a machine > >> >> were to come under memory pressure, they would be the first thing to be > >> >> reclaimed. TCP would continue to operate if they got pulled out from > >> >> under the connection as the protocol doesn't consider segments held in > >> >> reassembly to have been delivered, so would recover via retransmission. > >> > > >> > Yes, TCP would continue to operate. But attacker don't allow to put > >> > system under memory pressure. > >> > >> Without a concrete patch to discuss, let's just agree to disagree for > >> the time being. FreeBSD does a fairly good job autoscaling and reacting > >> to pressure with the VM subsystem for example. I don't see why we > >> can't > > > > Yes, and VM system allow to set different memory limits for proccess (and now for jails). > > > >> become good at doing it with the netstack. Manual tuning sucks and can > >> be just as dangerous if you tune things up to get performance, which > >> opens you up to the same problems. > > > > Autoscaling with limits is good. > > Automatic computation of limits (from available resources) also is > > good (currently limits frequently to small for modern installation, > > but don't remember about embeded systems). > > > > All the useless limitation BSD puts all over the place wrt. memory > management is a huge pain to deal with. nmbcluster, zone limitation > and friend are just useless. Just try to use NetGraph with a > consequent number of nodes and a high enough pps and the stuff with > will start dropping packet all over the place, even if the box has > Gigs of free memory. This problem can be solved by tuning next values in /boot/loader.conf? # netgraph queue sizes tuning, see vmstat -z|egrep 'ITEM|NetGraph' net.graph.maxdata=65536 net.graph.maxalloc=65536 > > > - Arnaud