From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 761033B29D; Tue, 11 Oct 2022 02:28:13 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1665469691; bh=FL5hMVzXjvEZFlcX/CLWCPwemDV9z9mTGGLMT42+nKo=; h=X-UI-Sender-Class:Date:From:To:CC:Subject:In-Reply-To:References; b=BzV4LkwUAZylnd5RitEllObtI2jT2aCoUzLmYb/zIhr/VmSd5MTCXxwfdzKQmJFXq sGl69TsAvifi4o4F2waRrNEfsQwu8A0QoV2uRcaCndMcnve6TCGgqXVxuBLS0h8e2z ajaVRoeYCiTPigNBGHS6ooZihHRC5werq9If28cY= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [127.0.0.1] ([80.187.111.72]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MatRT-1pJwbQ0F9X-00cOnW; Tue, 11 Oct 2022 08:28:11 +0200 Date: Tue, 11 Oct 2022 08:28:07 +0200 From: Sebastian Moeller To: Bob McMahon CC: Taraldsen Erik , Rpm , Make-Wifi-fast , Cake List , bloat User-Agent: K-9 Mail for Android In-Reply-To: References: <72674884-9E0D-4645-B5F5-C593CC45A8F0@gmx.de> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:PCaMQcNKPbtx5gGbP6vycQR/P4K8MDgkQGYqgnUo68fyq74JAx3 GNOh6L4UjxjeTNkpR0hEyBvCpRaeO50BKFK/Is+q1bPKDu9Ci7un4Bu9wpTUzKgsIkbV50E CL5opz2vhjhZ7/BlR5yTPJWq1yWLS9LFYAqpPQo8gs/zlzksKGifRJfhKCqxaoXRM2SzBjo h4EpIoQMkHbkNOXpEuBuw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:gDWnoQsIJKQ=:pUbQ7AlCkD4uZsH2r7qEP/ HvGyAn1svm3MBpAax0qJ1/maI1iaTCuDfmVI6DberEPSyshMQIUz5WKTQgCGNngA0HKqFSkaP iQCq8/64KTuNsTH4SUxGweG3zd+VGsnjzEfsceLSi5HZDatNWkQk2tPTBxndhcSQ6BJYLsWAz 0OMCw1Ct4B6HTsnrY8ZQYBomhiF74eBrrUQgxsl+R9GxJnGqtQTmGy8zyIXN7RANduvSTz2m7 oiH8V9fReW/gQj/S7LgFotslAMLktqo8YNP9bavrl2xhQ+KDkN4ySU7d1+NDSoahD8aVMkl58 5+mVu0aydi995D7VZqHv8A7b7xhpgvNq+HXwEHNu6YzoGmWywCzhv3YVsVzM5SJbspOIvKnib ythVvj+9Nwix7lWD8TeMeSPpMnsY41BfacI311w9rV25FtDEme2mfIk1WJb4MDsSLAouMGcuF +gyzYC53iZUe9Mwpk5WujqPgLFAjMG9n9mRNOql/3AQXyHQrcwdNK8PSBTwajNqLYsmzdVd7+ //tN7MT51trEzMT1W+6d/GJ5QBymCghK1Ap0JH21DNdF4stAMayQR0RtWgx+WssTVuvgKCGV0 hK55xP4LZwXSQIC3XUkFwZwY0+EgZjFU5Skw9y4wnbOj+6FPJHs7yulOd2Ry4b8L5ZiDwKpk5 2qLmtnM1N8l/7H9wcdUJkBlTo8JJVcncIV56yHVDG+T2vRQiM6r5ofj/7bfLZMncsUrPK1xy6 eO/hramhxUBOHsJISXJQokv4wJtiB3CyDRbGmcVPKK29/ju6KOVKjg2sQV4l5Zxl6rinwX6NI V3C75ETYV3l80TWAEVrTe7+mWG78k/cZD4wLLWslUcIrUdjSfsIYpLP/sNZPTkL/vrGzmNxJA 24IbOLf7ui8gTl9PxFXCiQD9tMiIGdk5Ch5C1RwpjyL4NzNQTDuAxYTS6HT5we5pcOPuw5Zrl V+pbXse16856Giakl22RfLImhmuUqTPmkcwrGcin/AXrySM/UUyeAbm4rG7goa0bwCPdSKtlI xah965bt+THN+mI2BQ5YLkhLRaGgjaxaIc57+Rnv6JXnnXwDys0pTy4jS1IJtIe2vCZaBLg6D lbCtTluj10Yt90t1xgOQQ59Qkded8GQ5B/hLyZ1nXEqRx2BWXUnrhpwhmGv901hoFXo90LVcv 5THJ7vDjaOnkVZkfDlH7AOBZIA/tlb32dVDtnau0VKYejtoozvvRTHT4xc42+Mj53R2LneMyY Z8FLWvWyHg4v7erSKjyC967gK9Rzrj+5tSf4fRYKSw6s/I9ID8+cU03SmYjaGri1zuRFpXvdH uwgDaGWTZCrvspp/GNeZZZN8zDajnpEe3mFcjVvP9V/mg9J3aD2Dn+17TRsW4bnkTEEhaZxQi el9ZMFXtx5jzh7buSc7Qkg1CHm/sTDIh6Rhc4PFXh1GLSK92HmpJXKBix9j42KO2RzmWTxoyf XTGVPdsSEkBr2Ff1vfmThJ76v0B3NMtlK0DJzw2sJWotJGPUYFiJbtcCjjvXkQSafl7s8Iv5b sOB1cEHaA27f0IBQ9zym+GG/x5GBxq9MSkK2qc7Dqjc0Y Subject: Re: [Make-wifi-fast] [Cake] [Bloat] The most wonderful video ever about bufferbloat X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2022 06:28:13 -0000 Hi Bob, On 10 October 2022 18:45:31 CEST, Bob McMahon wrote: >I think conflating bufferbloat with latency misses the subtle point in th= at >bufferbloat is a measurement in memory units more than a measurement in >time units=2E The first design flaw is a queue that is too big=2E=20 [SM] I tend to describe the problem as on-path queues being "over-sized an= d under-managed"=2E IMHO this makes it easier to see both potential approac= hes to address the consequences: a) the back-bone solution of working hard to never/rarely actually fill th= e buffer noticeably=2E b) the better-manage-(developing)-queues solution=2E While a crude systematic, this covers all approaches to tackle the problem= I am aware of=2E This youtube >video analogy doesn't help one understand this important point=2E > >Another subtle point is that the video assumes AQM as the only solution a= nd >ignores others, i=2Ee=2E pacing at the source(s) and/or faster service ra= tes=2E=20 [SM] Not all applications/use-cases interested in low latency are fully co= mpatible with pacing=2E E=2Eg=2E reaction-time gated multiplayer on-line ga= mes tend to send and receive on a 'tick' which looks like natural pacing, e= xcept especially on receive depending on circumstances world state updates = can consist out of quite a number of packets which the client needs all ASA= P so these burst should not be paced out over a tick=2E Faster service rates is a solution, that IMHO mostly moves the location of= the problematic queue around, in fact the opposite, lowering the service r= ate is how sqm achieves its goal to get the problematic queue under its con= trol=2E Also on variable rate links faster service rate is a tricky proposi= tion (as you well know)=2E >A restaurant that let's one call ahead to put their name on the waitlist >doesn't change the wait time=2E Just because a transport layer slowed dow= n >and hasn't congested a downstream queue doesn't mean the e2e latency >performance will meet the gaming needs as an example=2E The delay is stil= l >there it's just not manifesting itself in a shared queue that may or may >not negatively impact others using that shared queue=2E [SM] +1, this is part of my criticism of how the L4S proponents tout their= 1ms queueing delay goal, ignoring that the receiver only cares about total= delay and not so much where exactly the delay was 'collected'=2E However, experience with sqm makes me believe that trying to avoid naively= shared queues can help a lot=2E Trying as L4S does to change all senders to play nicer with shared queues,= is simply less robust and reliable than actually enforcing the desired beh= avior at the bottleneck queue in a fine grained and targeted fashion=2E > >Bob > > > >On Mon, Oct 10, 2022 at 2:40 AM Sebastian Moeller via Make-wifi-fast < >make-wifi-fast@lists=2Ebufferbloat=2Enet> wrote: > >> Hi Erik, >> >> >> > On Oct 10, 2022, at 11:32, Taraldsen Erik >> wrote: >> > >> > On 10/10/2022, 11:09, "Sebastian Moeller" wrote: >> > >> > Nice! >> > >> >> On Oct 10, 2022, at 07:52, Taraldsen Erik via Cake < >> cake@lists=2Ebufferbloat=2Enet> wrote: >> >> >> >> It took about 3 hours from the video was release before we got the >> first request to have SQM on the CPE's we manage as a ISP=2E Finally >> getting some customer response on the issue=2E >> > >> > [SM] Will you be able to bump these requests to higher-ups and = at >> least change some perception of customer demand for tighter latency >> performance? >> > >> > That would be the hope=2E >> >> [SM} Excellent, hope this plays out as we wish for=2E >> >> >> > We actually have fq_codel implemented on the two latest generations = of >> DSL routers=2E Use sync rate as input to set the rate=2E Works quite = well=2E >> >> [SM] Cool, if I might ask what fraction of the sync are you >> setting the traffic shaper for and are you doing fine grained overhead >> accounting (or simply fold that into a grand "de-rating"-factor)? >> >> >> > There is also a bit of traction around speedtest=2Enet's inclusion of >> latency under load internally=2E >> >> [SM] Yes, although IIUC they are reporting the interquartile me= an >> for the two loaded latency estimates, which is pretty conservative and = only >> really "triggers" for massive consistently elevated latency; so I expec= t >> this to be great for detecting really bad cases, but I fear it is too >> conservative and will make a number of problematic links look OK=2E But= hey, >> even that is leaps and bounds better than the old only idle latency rep= ort=2E >> >> >> > My hope is that some publication in Norway will pick up on that score >> and do a test and get some mainstream publicity with the results=2E >> >> [SM] Inside the EU the challenge is to get national regulators = and >> the BEREC to start bothering about latency-under-load at all, "some >> mainstream publicity" would probably help here as well=2E >> >> Regards >> Sebastian >> >> >> > >> > -Erik >> > >> > >> > >> >> _______________________________________________ >> Make-wifi-fast mailing list >> Make-wifi-fast@lists=2Ebufferbloat=2Enet >> https://lists=2Ebufferbloat=2Enet/listinfo/make-wifi-fast > --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E