From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (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 1AEB43B29E for ; Tue, 6 Apr 2021 19:32:27 -0400 (EDT) Received: by mail-pf1-x42d.google.com with SMTP id l123so10060550pfl.8 for ; Tue, 06 Apr 2021 16:32:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=7lKYKXZ/LV3uAXvfhXv3tDWegZsKVC6GBflLEZF52wo=; b=cMBH/3VbMokRLQMsLf6AVeRjdrYGscVaRI63T/mcsv+7bTuQPyKVT0tzUptJbRND/b tt+sT+s1MuaVI5hTqdS+zokg+lz8oJt4GVk8DSfY9lnIPhBFclgiMXMu4Ly/tOSPuGHd wcGtpfrrKXR/8j0VSxmMkKanlZmy3c2F5VayHMNjel7MXzAd81j18YBD4Lzzeq8ZyeYL i7d9VJfLd2WC0b/A6OSElxv2Qa/kxw37wVz3ID7tYx4rffaUvvR4GtLm5TT62s3yhR64 e2CwcBsAfztQDKHcODixgQK3P+OD2i5YqgPdlToixwCLhbWAOvhka6UCljm2Zplw+6oh NUrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=7lKYKXZ/LV3uAXvfhXv3tDWegZsKVC6GBflLEZF52wo=; b=OeNGhfKGAEWJ+gO6FsG0x2q4RteX9NqVMZjyvLJvpgYvbiyP1NxvWlrzIzPdVlkJgh GFjMj5doMI5EI+9juBkQs4iiTeiKpWLd4c33H+qQQZcB6e1ahVrRDuCfwXE223lRZySr gQohABCgSQWwQkXrV8i6cn+YqlXrBxbWu4M5rt13VdMcYND7iawHQfuraAT5XdTrz3B7 3viTn7D4uBGcdLzW7kGi9Akjtxhs3RXIskx333UqeGEP6GA4nSR5h5S/acLgT75WX+Bq jvhImBV6pG+n/MPq2dGzQAc5R44p0UB0iTV+ILi6ZhVCZS+aC4qzySTJiGb+z2An6zFQ R2lA== X-Gm-Message-State: AOAM5332FRqZPDqL/734sZN3pw4RDq5lkHVal/WK88T6CmHxoz+GvZNe Q7Lkjzzp5ZKYO6muUpMf2XGuGt7wTBil1A== X-Google-Smtp-Source: ABdhPJzs0gp9I2CRhQsP1JwJ9N+9dbT7tJJwhUf94HSvl/AFYUqzn4zbvwRC0uqxT5/GwcCQVq/Yiw== X-Received: by 2002:a65:63ce:: with SMTP id n14mr536115pgv.279.1617751946048; Tue, 06 Apr 2021 16:32:26 -0700 (PDT) Received: from hermes.local (76-14-218-44.or.wavecable.com. [76.14.218.44]) by smtp.gmail.com with ESMTPSA id v123sm18969822pfb.80.2021.04.06.16.32.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 06 Apr 2021 16:32:25 -0700 (PDT) Date: Tue, 6 Apr 2021 16:32:17 -0700 From: Stephen Hemminger To: Erik Auerswald Cc: bloat@lists.bufferbloat.net Message-ID: <20210406163217.46eabd74@hermes.local> In-Reply-To: <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> <20210406215953.GA19648@unix-ag.uni-kl.de> MIME-Version: 1.0 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, 06 Apr 2021 23:32:27 -0000 On Tue, 6 Apr 2021 23:59:53 +0200 Erik Auerswald wrote: > Hi, >=20 > On Tue, Apr 06, 2021 at 10:02:21PM +0200, Bless, Roland (TM) wrote: > > On 06.04.21 at 20:50 Erik Auerswald wrote: =20 > > >On Tue, Apr 06, 2021 at 08:31:01AM +0200, Sebastian Moeller wrote: =20 > > >>>On Apr 6, 2021, at 02:47, Erik Auerswald wrote: > > >>>On Mon, Apr 05, 2021 at 11:49:00PM +0200, Sebastian Moeller wrote: = =20 > > >>>>>On Apr 5, 2021, at 14:46, Rich Brown wro= te: > > >>>>> > > >>>>>Dave T=C3=A4ht has put me up to revising the current Bufferbloat a= rticle > > >>>>>on Wikipedia (https://en.wikipedia.org/wiki/Bufferbloat) > > >>>>>[...] =20 > > >Yes, large unmanaged buffers are at the core of the bufferbloat proble= m. =20 > >=20 > > I disagree here: it is basically the combination > > of loss-based congestion control with unmanaged > > tail-drop buffers. =20 >=20 > That worked for decades, then stopped working as well as before. > What changed? >=20 > Yes, there are complex interactions with how packet switched networks > are used. Otherwise we would probably not find ourselves in the current > situation. >=20 > 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. >=20 > > There are at least two solutions > > to the bufferbloat problem > > 1) better congestion control algorithms > > 2) active queue management (+fq maybe) =20 >=20 > 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. >=20 > > [...] > > 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. =20 >=20 > 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? >=20 > FQ with AQM aims to allow the absorption of large traffic bursts (i.e., > use of large buffers) without affecting _other_ flows too much. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > [0] https://datatracker.ietf.org/doc/draft-irtf-iccrg-rledbat/ >=20 > Anyway, I think it is obvious that I am willing to sacrifice more > throughput for better latency than others. >=20 For Wikipedia it is important to make clear: * the symptoms =3D large latency * the cause =3D large buffers and aggressive protocols * the solutions =3D AQM, smaller buffers, pacing, better congestion contr= ol, etc. People can argue over best combination of solutions but the symptoms and causes should be defined, and non-contentious. It is too easy to go off in the weeds and have the solution of the day.