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 B9B833B29D for ; Mon, 5 Apr 2021 20:47:38 -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 1360laE6069106 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 6 Apr 2021 02:47:36 +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 1360lZ8T029056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 6 Apr 2021 02:47:36 +0200 Received: (from auerswal@localhost) by sushi.unix-ag.uni-kl.de (8.14.4/8.14.4/Submit) id 1360lZgN029055 for bloat@lists.bufferbloat.net; Tue, 6 Apr 2021 02:47:35 +0200 Date: Tue, 6 Apr 2021 02:47:35 +0200 From: Erik Auerswald To: bloat@lists.bufferbloat.net Message-ID: <20210406004735.GA16266@unix-ag.uni-kl.de> References: <9A233C8C-5C48-4483-A087-AA5FE1011388@gmail.com> <320ECDF6-8B03-4995-944B-4726B866B2D3@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <320ECDF6-8B03-4995-944B-4726B866B2D3@gmx.de> 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 00:47:38 -0000 Hi, On Mon, Apr 05, 2021 at 11:49:00PM +0200, Sebastian Moeller wrote: > > all good questions, and interesting responses so far. I'll add some details below, I mostly concur with your responses. > > 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) > > [...] > [...] while too large buffers cause undesirable increase in latency > under load (but decent throughput), [...] With too large buffers, even throughput degrades when TCP considers a delayed segment lost (or DNS gives up because the answers arrive too late). I do think there is _too_ large for buffers, period. > The solution basically is large buffers with adaptive management that I would prefer the word "sufficient" instead of "large." > works hard to keep latency under load increase and throughput inside > an acceptable "corridor". I concur that there is quite some usable range of buffer capacity when considering the latency/throughput trade-off, and AQM seems like a good solution to managing that. My preference is to sacrifice throughput for better latency, but then I have been bitten by too much latency quite often, but never by too little throughput caused by small buffers. YMMV. > [...] > But e.g. for traditional TCPs the amount of expected buffer needs > increases with RTT of a flow Does it? Does the propagation delay provide automatic "buffering" in the network? Does the receiver need to advertise sufficient buffer capacity (receive window) to allow the sender to fill the pipe? Does the sender need to provide sufficient buffer capacity to retransmit lost segments? Where are buffers actually needed? I am not convinced that large buffers in the network are needed for high throughput of high RTT TCP flows. See, e.g., https://people.ucsc.edu/~warner/Bufs/buffer-requirements for some information and links to a few papers. > [...] Thanks, Erik -- The computing scientist’s main challenge is not to get confused by the complexities of his own making. -- Edsger W. Dijkstra