From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 4BB9D3B29D for ; Mon, 26 Apr 2021 21:41:29 -0400 (EDT) Received: by mail-io1-xd36.google.com with SMTP id p8so5286963iol.11 for ; Mon, 26 Apr 2021 18:41:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=cJIRBHAcbSwxWYKjZsVP9OxJjKEIs9I3ktQszt/yQog=; b=nd7nTcbiR+d7S6IZy/w25+rUGC1oV7q4GFARgB6LV9YNkLcRnBkmfxjrqV9wAy09eL 2pc/04193GX9g67oeKMOyX4fGrZZ0p9swihhTvLrKKhoTMGjwq3BL2x2eXTairCBaz4A X07J4EUsrTJM5YtRCHzPlYDwnb3+WUcUsakFaLAThQgT52eZXPm1yKK0YAh4LzK7rUsW Lkw5JbOkE4X7Csu+pPzUvYRVH6axC1hBudJcaqAAPoHFRctERwDitkzSME70UR2BpTJa dkJC/jOvOOTRXIaUD3wdJknfLCZR+U+1X2rKqyQBnqB/TyB2Ce6zrW7efb5iW0xdCUbe 7hGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=cJIRBHAcbSwxWYKjZsVP9OxJjKEIs9I3ktQszt/yQog=; b=Af1Z4VmEdwUgeTkxMb3yKjN/wWaoV7tgHwWUNIk8ja0gNkIqu1BfjsNxT0H3Y+FAJY k3di8TZ93mnJHjbSMJilIQFDSdAxVEkXNZSZpXqSuBpB/YYRXRa63DVT3HTLQuGo7wjl XHWtbwQL27HmO/VPt2/j5yoI2gpNU8gAcr5Iq7tUM0gMBteV1ghq7t1/5UfSvrIoMnWl VhZHBYImd8E+1WyB8t1tMxaZMi07hem7R2K7Ja+1Y8wiSCMYxKcEkNO7AuewzmOC2lDm +yYY7izkO2XQUebi48h83NN/rIhIRKoiIeq1NXDQcSD2WJCUv0ZMCTmjzMADVptuWm+W Aisw== X-Gm-Message-State: AOAM531Fu+ANezU71heQ3PIyg9T7KjITQjsxHWRcp2kh11XPOViSBQGl PYhPxKKFcVOtKPhyTYm1rgaO2Vy6YFAdmMNs02yBuAeU X-Google-Smtp-Source: ABdhPJx76VndSGhDJbsQMwiGhhcVSju+POMOi7F0f7xBTmJj87GxugtLAPXXXDzmNSE7pSFOUjCcgLgzxf0rZXLl6V0= X-Received: by 2002:a02:5142:: with SMTP id s63mr18887585jaa.82.1619487688636; Mon, 26 Apr 2021 18:41:28 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: <1df72a64-715f-b79b-6cda-df6d8ecfc9d6@kit.edu> From: Dave Taht Date: Mon, 26 Apr 2021 18:41:14 -0700 Message-ID: To: "Bless, Roland (TM)" Cc: Erik Auerswald , bloat Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 01:41:29 -0000 roland do you have running code for lola on linux? I'm running some starlink tests... On Wed, Apr 7, 2021 at 4:06 AM Bless, Roland (TM) wr= ote: > > 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 > 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 > 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 > 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 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, > Roland > > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat --=20 "For a successful technology, reality must take precedence over public relations, for Mother Nature cannot be fooled" - Richard Feynman dave@taht.net CTO, TekLibre, LLC Tel: 1-831-435-0729