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 872F33B29E for ; Tue, 6 Apr 2021 17:59:56 -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 136LxrI0154429 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 6 Apr 2021 23:59:53 +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 136Lxre0032493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 6 Apr 2021 23:59:53 +0200 Received: (from auerswal@localhost) by sushi.unix-ag.uni-kl.de (8.14.4/8.14.4/Submit) id 136LxrhC032492 for bloat@lists.bufferbloat.net; Tue, 6 Apr 2021 23:59:53 +0200 Date: Tue, 6 Apr 2021 23:59:53 +0200 From: Erik Auerswald To: bloat@lists.bufferbloat.net Message-ID: <20210406215953.GA19648@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> <20210406185015.GC18085@unix-ag.uni-kl.de> <7a79c484-7c9c-0e9a-a0f7-9a5dbd607c21@kit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7a79c484-7c9c-0e9a-a0f7-9a5dbd607c21@kit.edu> 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 21:59:56 -0000 Hi, On Tue, Apr 06, 2021 at 10:02:21PM +0200, Bless, Roland (TM) wrote: > On 06.04.21 at 20:50 Erik Auerswald wrote: > >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) > >>>>>[...] > >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. That worked for decades, then stopped working as well as before. What changed? Yes, there are complex interactions with how packet switched networks are used. Otherwise we would probably not find ourselves in the current situation. To me, the potential of having to wait minutes (yes, minutes!) for the result of a key stroke over an SSH session is not worth the potential throughput performance gain of buffers that cannot be called small. > There are at least two solutions > to the bufferbloat problem > 1) better congestion control algorithms > 2) active queue management (+fq maybe) Both approaches aim to not use all of the available buffer space, if there are unreasonably large buffers, i.e., they aim to not build a large standing queue. > [...] > 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. Could the better congestion control algorithms avoid the potential performance loss by not requiring large buffers for high throughput? Might small buffers incentivise to not send huge bursts of data and hope for the best? FQ with AQM aims to allow the absorption of large traffic bursts (i.e., use of large buffers) without affecting _other_ flows too much. I would consider the combination of FQ+AQM, better congestion control algorithms, and large buffers as an optimization, but using just large buffers without any of the other two approaches as a mistake currently called bufferbloat. As such I see large unmanaged buffers at the core of the bufferbloat problem. FQ+AQM for every large buffer may solve the bufferbloat problem by attacking the "unmanaged" part of the problem. Small buffers may solve it by attacking the "large" part of the problem. Small buffers may bring their own share of problems, but IMHO those are much less than those of bufferbloat. I do not see TCP congestion control improvements, even combining sender-side improvements with receiver-side methods as in rLEDBAT[0], as a solution to bufferbloat, but rather as a mitigation. [0] https://datatracker.ietf.org/doc/draft-irtf-iccrg-rledbat/ Anyway, I think it is obvious that I am willing to sacrifice more throughput for better latency than others. Thanks, Erik -- Simplicity is prerequisite for reliability. -- Edsger W. Dijkstra