From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailgw1.uni-kl.de (mailgw1.uni-kl.de [IPv6:2001:638:208:120::220]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id D29B53B29E for ; Tue, 6 Apr 2021 14:50:17 -0400 (EDT) Received: from sushi.unix-ag.uni-kl.de (sushi.unix-ag.uni-kl.de [IPv6:2001:638:208:ef34:0:ff:fe00:65]) by mailgw1.uni-kl.de (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id 136IoFYL069319 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 6 Apr 2021 20:50:15 +0200 Received: from sushi.unix-ag.uni-kl.de (ip6-localhost [IPv6:::1]) by sushi.unix-ag.uni-kl.de (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id 136IoFdZ000349 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 6 Apr 2021 20:50:15 +0200 Received: (from auerswal@localhost) by sushi.unix-ag.uni-kl.de (8.14.4/8.14.4/Submit) id 136IoFRq000348 for bloat@lists.bufferbloat.net; Tue, 6 Apr 2021 20:50:15 +0200 Date: Tue, 6 Apr 2021 20:50:15 +0200 From: Erik Auerswald To: bloat@lists.bufferbloat.net Message-ID: <20210406185015.GC18085@unix-ag.uni-kl.de> References: <9A233C8C-5C48-4483-A087-AA5FE1011388@gmail.com> <320ECDF6-8B03-4995-944B-4726B866B2D3@gmx.de> <20210406004735.GA16266@unix-ag.uni-kl.de> <31F4A461-F3D6-42FF-B6A5-33F4824F97BC@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <31F4A461-F3D6-42FF-B6A5-33F4824F97BC@gmx.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, hits=-1, tests=ALL_TRUSTED=-1 X-Spam-Score: (-1) X-Spam-Flag: NO Subject: Re: [Bloat] Questions for Bufferbloat Wikipedia article X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2021 18:50:18 -0000 Hi, On Tue, Apr 06, 2021 at 08:31:01AM +0200, Sebastian Moeller wrote: > > On Apr 6, 2021, at 02:47, Erik Auerswald wrote: > > On Mon, Apr 05, 2021 at 11:49:00PM +0200, Sebastian Moeller wrote: > >>> On Apr 5, 2021, at 14:46, Rich Brown wrote: > >>> > >>> Dave Täht has put me up to revising the current Bufferbloat article > >>> on Wikipedia (https://en.wikipedia.org/wiki/Bufferbloat) > >>> [...] > >> [...] while too large buffers cause undesirable increase in latency > >> under load (but decent throughput), [...] > > > > With too large buffers, even throughput degrades when TCP considers > > a delayed segment lost (or DNS gives up because the answers arrive > > too late). I do think there is _too_ large for buffers, period. > > Fair enough, timeouts could be changed though if required ;) but I fully > concur that laergeish buffers require management to become useful ;) Yes, large unmanaged buffers are at the core of the bufferbloat problem. One can make buffers small again, or manage them appropriately. The latter promises better results, the former is much simpler. Thanks, Erik -- Am I secure? I don't know. Does that mean I should just disable all security functionality and have an open root shell bound to a well known port? No. Obviously. -- Matthew Garret