From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.lang.hm (unknown [66.167.227.145]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id B35BA3B2A4 for ; Wed, 9 Mar 2022 13:06:18 -0500 (EST) Received: from dlang-mobile (unknown [10.2.2.69]) by mail.lang.hm (Postfix) with ESMTP id 627C412524C; Wed, 9 Mar 2022 10:06:17 -0800 (PST) Date: Wed, 9 Mar 2022 10:06:17 -0800 (PST) From: David Lang To: Michael Menth cc: Jesper Dangaard Brouer , =?ISO-8859-15?Q?Toke_H=F8iland-J=F8rgensen?= , bloat In-Reply-To: <5a8b6b4a-7f15-3f08-56b5-9e04773271bb@uni-tuebingen.de> Message-ID: <3oq1pps-7sp1-4q54-5n8s-nq4p667923sn@ynat.uz> References: <87y21julxu.fsf@toke.dk> <9785d2cd-b164-deb4-4cbe-7d0fb356f16e@redhat.com> <5a8b6b4a-7f15-3f08-56b5-9e04773271bb@uni-tuebingen.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="228850167-1781433527-1646849177=:5261" Subject: Re: [Bloat] Up-to-date buffer sizes? 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, 09 Mar 2022 18:06:18 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --228850167-1781433527-1646849177=:5261 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT If the link is not a bottleneck, then you will not be using buffers (whatever they are configured to be) networking gear tends toward the proprietary (although there's a growing amount that's linux based now) and they tend to be very closed mouth about configuration like this. David Lang On Wed, 9 Mar 2022, Michael Menth wrote: > Date: Wed, 9 Mar 2022 18:39:08 +0100 > From: Michael Menth > To: Jesper Dangaard Brouer , > Toke Høiland-Jørgensen , bloat > Subject: Re: [Bloat] Up-to-date buffer sizes? > > Hi all, > > I don't question the usefulness of AQMs for buffers - on the contrary. > But what are up-to-date buffer sizes in networking gears, especially if > AQMs are not in use? It's hard to find public and information about it. > Anyone can point to a citable source? > > This raises also the question about the deployment of AQMs in networking > infrastructure. I know it's already adopted by some OSs, but what about > forwarding nodes? Any papers about it? > > Kind regards > > Michael > > Am 09.03.2022 um 18:24 schrieb Jesper Dangaard Brouer: >> >> >> On 09/03/2022 17.31, Toke Høiland-Jørgensen via Bloat wrote: >>> Michael Menth writes: >>> >>>> Hi all, >>>> >>>> are there up-to-date references giving evidence about typical buffer >>>> sizes for various link speeds and technologies? >>> >>> Heh. There was a whole workshop on it a couple of years ago; not sure if >>> it concluded anything: http://buffer-workshop.stanford.edu/program/ >>> >>> But really, asking about buffer sizing is missing the point; if you have >>> static buffers with no other management (like AQM and FQ) you're most >>> likely already doing it wrong... :) >> >> Exactly, I agree with Toke. The important parameter is the latency. >> Or the packet sojourn time (rfc8289 + rfc8290) observed waiting in the >> queue. >> >> The question you should be asking is: >>  - What is the max queue latency I'm "willing" to experience on this link? >> >> Hint, you can then depending on the link rate calculate the max buffer >> size you should configure. >> >> The short solution is: >>  - just use fq_codel (rfc8290) as the default qdisc. >> >> --Jesper >> >> >> > > --228850167-1781433527-1646849177=:5261--