From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 6BB7D3B2A4 for ; Sun, 4 Jun 2023 15:55:44 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1685908542; x=1686513342; i=moeller0@gmx.de; bh=q9YKJtJB2TaoMub4PKWaIKb0h0ely+BhPq8JSyG3Xwg=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=Aayl/hVBWxMNzcZ2jpMLrGJpDlHdYZey0qdXYQsVO+0Yl7oXDP6Mue787lrvlfsnVmN8U73 a23zDcM7M4qQyab2uhYiX1h4XvbXGPKP5UwX+BiSlUU+ytYOKKIx+AB95DD08JJ6vzZR3ntsK mLDMIpUCd26ARlPQf2b46MpJr5XSugvbQSkfSFULWre+RFdQ78M29vdeTdmvIqnWoY6sp7f8W Xm4p6IW/5qXvQ6IK1PvGWbpaizdHZr1pfbBqaCoW5/PxlVF5CDUAH1z1xH8H1vPBH/jR7QYDu pbgpIknDferqP8zhVUSI1A9DoWWfNThFJ5wYz7fuJ/fjdfZ7GcWg== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([80.187.108.116]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MFsZ3-1pqCMD074h-00HSRX; Sun, 04 Jun 2023 21:55:42 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.3\)) From: Sebastian Moeller In-Reply-To: Date: Sun, 4 Jun 2023 21:55:41 +0200 Cc: John D , bloat@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <63272858-46FF-493E-9A81-F6152DD13E8D@gmx.de> References: <39DED14A-AACF-4C45-9834-C295F92E8800@gmail.com> To: Aaron Wood X-Mailer: Apple Mail (2.3696.120.41.1.3) X-Provags-ID: V03:K1:+1UhEWPvYF0Td6fXz8KxMhr7lV8NE1EiFRfq6K3GZsVsmNuD/Dd lKGXKB+fBQEOY4AdHn784163uV07GXnoAhLRAagazpLFE1Wq3iUjqVcozk8O+vQjnGj1O5P /oEqfc384Pk7qjWTo/iJo8ypBcWWlzn36PQg24sLwSAvLKp0wWSJN4W9cwZM8HhOcEqWdLj ze7DuqzKix/IN9j0bDrZQ== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:UUG0K/kKRow=;3I5ZYfW8wt90UfvIoB1lCTKIJBN sNIxxrcXUZvQypigPDoCUGDRNg3iWXjO7CIcpImcLLYMzWvkHzBhRtyAbn64ykZoV5bDoXP5s BQZcsBtuKTrtF/rCpHw/XNRPAhG9QbaG17DFw01fndj/pgTpOoW5WY2by8/NYXTWdFGW6aQwm 7UpquX0Z4iVDBYA9WNrGkqxCywWjgYEvchOS1tRMHDKs5n1yfIp3z84xFyxqd84stiIoXE9QB XJH7Yhbn1beboLDRPSJz9TlKT601Pb1JeKGcygfb2k2/9gXwdgiPkowfom0klGvjTSoePU+tB DIF5oAryKSNoCzyQa3qM2ar/TvQ3Y0VW4E8EHBspAiaKqC1yjYq/qztVc+8MYYKA3PjRvbgy6 hCXr3dxdlva4Gzr1YaheQ3B1KvJEHnxCWqlEthnZ517L1W5BVcz+4brPYvz8IPI9gdSVWYukf GSkDt+DhKLOEZjs6TkJgD1Mv38bYrNG3f1IbRrHawemLlkIr8HpBmpWpBlWqR2jsnTciqlpKs 9Frf5SIGAE6IP/09nJs6admdoo0w4cGOPwJAWgrC3FY01M2MQOLwdXHfbvBn0ljJQ+Kr0z0Vp 8T6iuNqhbU46G0x4nxX+ojHZD05CgTCrZw8st6SO5QMrezhXHpowPkG/WMBxJw76mwpTBFdWM KTFwLEKYDacT2VHkfL9/4uOEWzPGpokdrGXbmZeZcHLN4pZGshKXTt7kGHhEk/dqePQdM1KQ9 N+ZSchBi4wGaSZUmrcp66hGetFFK0Iak+eIFc86wMbJsBJTGT+tEzJyqUEh3kwm+wgj35b7zV weOLMItlkIubiHDo/LHveB0AlWEAnidBfDMwXAnNvoRlBo2IcM9qmKh0pRc/PZZYwSnRBDRS8 ewBnADZY2nyCADxjJXfsvnXwdOEINAItuhpWJrN1QYjimj/rR7O/GdDZVCgc3Sg1s3Jak3AMZ P2Q5oBbYmGPOxlWdBS/dgjTgC6I= Subject: Re: [Bloat] SQM tuning question 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: Sun, 04 Jun 2023 19:55:44 -0000 Hi Aaron, > On Jun 3, 2023, at 20:04, Aaron Wood via Bloat = wrote: >=20 > I=E2=80=99ve found that _usually_ I can set cake=E2=80=99s bandwidth = limits to 90-95% of the advertised bandwidth, and everything =E2=80=9Cjust= works=E2=80=9D. So long as you=E2=80=99re routinely able to achieve = the bandwidth, it tends to work. >=20 > I=E2=80=99ve found in my testing over the years (I=E2=80=99ve been a = user of fq_codel since 2013) that limiting the upstream bandwidth is the = most important one to do. Downstream bandwidth limits, especially if = you have well above 100Mbps downstream aren=E2=80=99t as critical, but = it still can make a big difference if you routinely saturate your = downstream connection. >=20 > It=E2=80=99s especially important to manage the upstream bandwidth = when the connection is asymmetric. For instance my 1Gbps Comcast = internet service only has a 35Mbps upstream limit, which is just a bit = more than you need for the acks that go back upstream in response to = 1Gbps of downstream traffic. >=20 > But if your connection quality suffers with time of day (congestion on = shared local ISP infrastructure), or due to weather (radio links can = degrade during the rain), then that can be a bit more annoying. >=20 > But as I said, I=E2=80=99ve found with my Comcast connection that I = can just set my bandwidth limits to 90-95% of advertised and it just = works. >=20 > The other thing to look into is DNS. Most of the weird pauses that I = see are, DNS related. I e switches to using a local DNS = cache/lookup-forwarding server, and use DNS over HTTPS to parallel = requests to both cloudflare and google=E2=80=99s HTTPS DNS proxies. = That seems to be more stable (long-lived connections with faster = recovery from a dropped packed than UDP has). >=20 > (More continued below) >=20 > On Sat, Jun 3, 2023 at 10:17 AM John D via Bloat = wrote: > Thanks for the detail. It makes sense but it kind of feels like in = some (maybe many) cases the router could know the internet link = performance. Particularly home router-modems often monitor this already. = Maybe that's just not exposed in any standardised way? >=20 > There are two issues I=E2=80=99ve seen here: >=20 > 1) there=E2=80=99s not a standardized way (or even usually any api) = for getting the provisioned rate, or the current link speed, from the = modem portion of things. >=20 > 2) local congestion at the ISP can degrade things below the = provisioned rates, and that=E2=80=99s even harder to detect or have = available. >=20 > If your upstream connection is DOCSIS 3.1, you should have the PIE AQM = running in the modem, which _should_ help considerably. But at least at = my cable headend, while downstream runs DOCSIS 3.1, upstream is only = DOCSIS 3.0, and definitely isn=E2=80=99t using PIE. >=20 > The PIE AQM, running on the modem itself has the advantage of running = on what is almost always the bottle neck for upstream traffic in my = experience: the provisioned upstream bandwidth in the modem. [SM] Even better, the cable modem requests mini-slots from the = scheduler and really has control over the true upstream queue, so even = in an overloaded segment (where mini-slot scheduling gets slow) the PIE = instance sees the relevant queueing delay to do its thing even if the = current rate is well below the "provisioned" rate (which is just a = maximum peak rate anyway). Now this will only help for congestion in the = DOCSIS segment, as you said that is likely to be the most likely cause = for upstream delay anyways... >=20 > I'm guessing if I was into openwrt I could maybe do something, but I = prefer just to find something off the shelf with half decent SQM... If = "auto configuration" isn't a feature then that answers my question and I = can get on choosing the best option. >=20 > I=E2=80=99m not aware of any decent =E2=80=9Coff the shelf=E2=80=9D = solutions that can track bandwidth correctly, aside from DOCSIS 3.1 = modems (which still requires the cable company to provision it correctly = to enable it) >=20 > But, as I said, if your connection is stable, you can get the majority = of the benefits just by setting it up once and leaving it be. >=20 > I=E2=80=99ve only tweaked things 1-2 times a year, for the last three = years, and that was only because I was moving. Once I had setup a = router that could run cake at my line rates, I=E2=80=99ve just left it = there and it=E2=80=99s been fine. >=20 > Especially since for me, WiFi is my usual bottleneck (my APs only do = about 250-300Mbps) >=20 > -Aaron >=20 >=20 > On Sat, Jun 3, 2023, 16:44 Jonathan Morton = wrote: > > On 3 Jun, 2023, at 4:56 pm, John D via Bloat = wrote: > >=20 > > On the website it says the following: > >=20 > > CoDel is a novel =E2=80=9Cno knobs=E2=80=9D, =E2=80=9Cjust works=E2=80= =9D, =E2=80=9Chandles variable bandwidth and RTT=E2=80=9D, and simple = AQM algorithm. > >=20 > > =E2=80=A2 It is parameterless =E2=80=94 no knobs are required = for operators, users, or implementers to adjust. > > =E2=80=A2 It treats good queue and bad queue differently - = that is, it keeps the delays low while permitting bursts of traffic. > > =E2=80=A2 It controls delay, while insensitive to round-trip = delays, link rates, and traffic loads. > > =E2=80=A2 It adapts to dynamically changing link rates with no = negative impact on utilization. > >=20 > > But everywhere I have read about about hardware which implements SQM = (including the bufferbloat website) it describes the need to tune based = on actual internet connection speed. > > These seem to conflict especially that "handles variable bandwidth" = bit. Have I misunderstood or do the algorithms used in modern hardware = just not provide this part typically? My connection performance is quite = variable and I'm worried about crippling SQM to the lowest speed seen. >=20 > SQM in practice requires three components: >=20 > 1: Flow isolation, so that different flows don't affect each others' = latency and are delivered fairly; >=20 > 2: Active Queue Management (AQM) to signal flows to slow down = transmissions when link capacity is exceeded; >=20 > 3: Bandwidth shaping to match the queue to the available capacity. >=20 > CoDel is, in itself, only the AQM component. It does indeed work = pretty well with no additional tuning - but only in combination with the = other two components, or when applied directly to the actual bottleneck. = Unfortunately in most consumer internet links, the actual bottleneck is = inaccessible for this purpose. Thus an artificial bottleneck must be = introduced, at which SQM is applied. >=20 > The most convenient tool for applying all three SQM components at once = is Cake. This includes implementations of advanced flow isolation, = CoDel AQM, and a deficit-mode bandwidth shaper. All you really need to = do is to tell it how much bandwidth you have in each direction, minus a = small margin to ensure it becomes the actual bottleneck and can exert = the necessary control. >=20 > When your available bandwidth varies over time, that can be = inconvenient. There are methods, however, of observing how available = capacity tends to change over time (typically on diurnal and weekly = patterns, if the variations are due to congestion in the ISP backhaul or = peering) and scheduling adjustments on that basis. If you have more = information on your situation, we might be able to give more detailed = advice. >=20 > - Jonathan Morton > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > --=20 > - Sent from my iPhone. > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat