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 EDFB53B29D for ; Tue, 27 Apr 2021 03:25:02 -0400 (EDT) Received: from i72vorta.tm.uni-karlsruhe.de ([141.3.71.26] helo=i72vorta.tm.kit.edu) by iramx2.ira.uni-karlsruhe.de with esmtpsa port 25 iface 141.3.10.8 id 1lbI5c-0002mB-Po; Tue, 27 Apr 2021 09:25:00 +0200 Received: from [IPv6:::1] (localhost [127.0.0.1]) by i72vorta.tm.kit.edu (Postfix) with ESMTPS id 82C864200FD; Tue, 27 Apr 2021 09:25:00 +0200 (CEST) To: Dave Taht Cc: Erik Auerswald , bloat 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> <1df72a64-715f-b79b-6cda-df6d8ecfc9d6@kit.edu> From: "Bless, Roland (TM)" Organization: Institute of Telematics, Karlsruhe Institute of Technology (KIT) Message-ID: <73886b5d-a5b6-2b33-dc55-85d06bc558dd@kit.edu> Date: Tue, 27 Apr 2021 09:25:00 +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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-DE 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 1619508300.875360166 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, 27 Apr 2021 07:25:03 -0000 Hi Dave, On 27.04.21 at 03:41 Dave Taht wrote: > roland do you have running code for lola on linux? I'm running some > starlink tests... I think the latest code is here and unfortunately it hasn't been updated for a while: https://git.scc.kit.edu/TCP-LoLa/TCP-LoLa_for_Linux However, in case that there are loss-based congestion controls present at the bottleneck in addition to LoLa flows, LoLa will not get any reasonable bandwidth, because we did not yet build in a more aggressive mode for these cases in order to not sacrifice LoLa's low delay goal. So you can give it a try, but it has not been engineered for real world usage so far, so some default parameters may not fit to your use case. Regards, Roland > On Wed, Apr 7, 2021 at 4:06 AM Bless, Roland (TM) wrote: >> >> 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 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? >> Larger buffers in many places and several orders of magnitude higher >> 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 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? >> Yes, at least our TCP LoLa approach achieves high throughput without >> 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 hope >>> for the best? >> There are different causes of bursts. You might get a huge burst from >> many flows >> that send only a single packet each, or you might get a huge burst from >> 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 AQMs >> 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 approach. >> 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, >> Roland >> >> >> _______________________________________________ >> Bloat mailing list >> Bloat@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/bloat > > >