From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [IPv6:2a00:1398:2::10:81]) (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 DB6CF3B29E for ; Tue, 6 Apr 2021 16:02:22 -0400 (EDT) Received: from [2a00:1398:2:4006:6404:f39e:1278:5a52] (helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtpsa port 25 iface 2a00:1398:2::10:8 id 1lTru2-00059v-4O; Tue, 06 Apr 2021 22:02:22 +0200 Received: from [IPv6:::1] (localhost [127.0.0.1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id F0DA0420093; Tue, 6 Apr 2021 22:02:21 +0200 (CEST) To: Erik Auerswald , bloat@lists.bufferbloat.net 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> <20210406185015.GC18085@unix-ag.uni-kl.de> From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT) Message-ID: <7a79c484-7c9c-0e9a-a0f7-9a5dbd607c21@kit.edu> Date: Tue, 6 Apr 2021 22:02:21 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <20210406185015.GC18085@unix-ag.uni-kl.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Checksum: v3zoCAcc32ckk X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de esmtpsa 1617739342.168615775 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 20:02:23 -0000 Hi, On 06.04.21 at 20:50 Erik Auerswald wrote: > 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. I disagree here: it is basically the combination of loss-based congestion control with unmanaged tail-drop buffers. There are at least two solutions to the bufferbloat problem 1) better congestion control algorithms 2) active queue management (+fq maybe) You can achieve high throughput and low delay with a corresponding congestion control (e.g., see this study of how to achieve a common limit on queuing delay for multiple flows: https://ieeexplore.ieee.org/document/8109356) even in large buffers. > One can make buffers small again, or manage them appropriately. > The latter promises better results, the former is much simpler. Small buffers definitely limit the queuing delay as well as jitter. However, how much performance is potentially lost due to the small buffer depends a lot on the arrival distribution. Regards, Roland