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 8457C3B2A4 for ; Wed, 7 Apr 2021 07:06:26 -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 1lU60v-0001qk-Lx; Wed, 07 Apr 2021 13:06:25 +0200 Received: from [IPv6:::1] (localhost [127.0.0.1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 492E8420005; Wed, 7 Apr 2021 13:06:25 +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> <7a79c484-7c9c-0e9a-a0f7-9a5dbd607c21@kit.edu> <20210406215953.GA19648@unix-ag.uni-kl.de> From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT) Message-ID: <1df72a64-715f-b79b-6cda-df6d8ecfc9d6@kit.edu> Date: Wed, 7 Apr 2021 13:06:25 +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: <20210406215953.GA19648@unix-ag.uni-kl.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de) X-ATIS-Checksum: v3zoCAcc32ckk X-ATIS-Timestamp: iramx2.ira.uni-karlsruhe.de esmtpsa 1617793585.719793003 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: Wed, 07 Apr 2021 11:06:26 -0000 Hi Erik, see inline. On 06.04.21 at 23:59 Erik Auerswald wrote: > 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 wr= ote: >>>>>>> >>>>>>> Dave T=C3=A4ht 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 probl= em. >> 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? Larger buffers in many places and several orders of magnitude higher=20 link speeds as well as higher awareness for latency as an important QoS parameter. > Yes, there are complex interactions with how packet switched networks > are used. Otherwise we would probably not find ourselves in the curren= t > 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 potenti= al > 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? Yes, at least our TCP LoLa approach achieves high throughput without=20 loss and a configurable limited queuing delay. So in principle this is possible. > Might small buffers incentivise to not send huge bursts of data and hop= e > for the best? There are different causes of bursts. You might get a huge burst from=20 many flows that send only a single packet each, or you might get a huge burst from=20 a few connections that transmit lots of back-to-back packets. Therefore, it depends on the = location of the bottleneck and on the traffic arrival distribution. > 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. My counter example is that large unmanaged buffers would not necessarily lead to the bufferbloat problem if we had other congestion controls that = avoid creating large standing queues. However, in practice, I also see only AQM= s and better CCs in combination, because we have to live with legacy CCs for some time. > 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/ As already said: the TCP LoLa concept shows that it is possible to solve the bufferbloat problem by a different congestion control approa= ch. However, the coexistence of LoLa with loss-based CCs will always be a problem unless you separate both CC types by separate queues. Currently, LoLa is rather an academic study showing what is possible in theory, but it is far from being usable in the wild Internet, as it would require much more work to cope with all the peculiarities out there. Regards, =C2=A0Roland