From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 8DCF23B29E; Mon, 13 Mar 2023 14:34:50 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1678732485; i=moeller0@gmx.de; bh=bCNEKo0t7eql5Bx8iUfB4j7VHyY/GANP1OYz8fEI6iU=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=e3rF20ek/5EZdnOR1YfeQzFu/nE91UDc9bGWhpelwXf9bP10N7Ts3EwKcPIROpxeG KckvhFFGT+C2keVVM3fexRTAW917+6Qz2cfiZ8wqcX9WdWliB8GJYdRssPXQ4u03e/ 8lCt46pdrDtsl0v6T1/rci9YiY/caeZjxg+8snyb13c5BugBag2RHmh35l8BKv0olY iBBP/rAKSFRiktlwwO2Vmpl+EjhuihV6akrc2IVRjmzD4Qi1vITuU82mCFASET1pp0 NwkXhqOPpNqT8Wp2ckMcVZ9kdHJxMFr31Y03iZ/njD7t2Z6g6NCGTd1TycMgrLV7o+ Gd6ASR3OcaRtg== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([134.76.241.253]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MI5QF-1pn2tG1rQV-00FBxC; Mon, 13 Mar 2023 19:34:45 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.2\)) From: Sebastian Moeller In-Reply-To: Date: Mon, 13 Mar 2023 19:34:44 +0100 Cc: dan , Rpm , libreqos , Dave Taht via Starlink , rjmcmahon , bloat Content-Transfer-Encoding: quoted-printable Message-Id: References: <1672786712.106922180@apps.rackspace.com> <77CCAD19-07E0-4F9E-88C1-D207CF7BF376@cable.comcast.com> <83ffc0dad19e3343e49271889369cefc@rjmcmahon.com> <3CD0B9E6-0B2A-4A70-8F53-ED0822DF77A6@gmx.de> <13DE6E53-665F-4C20-BBE2-70E685421E9D@gmx.de> To: Jeremy Austin X-Mailer: Apple Mail (2.3696.120.41.1.2) X-Provags-ID: V03:K1:+4OgyBnOsmkgxiTEi1i7La06QzFA3vSVB/4HZed9/jziccYdBjR qT0LfLAcE8y098iUX4PJUTnt15qsLuWz8QsjJkuJ1/oLWm1j8zAHn8QelHSIVbkzipuZWJV WpG7/IMlWIZLl+XAoH+XbocqjJf8kUQuqzgPiKfY2wk9CEh5zC9mOpOoPx/dC94+DYAv1Iq DHlD+SOnMt0hJYN5RVFXA== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:8hryUePtQ2M=;0prmXqn89cKEjQ66H/xi5zKeDeB t8kLnLe0sXLaqIz1Vfm8zZ50h7Q/PBzAUcshsxLGS7EJopMEkDIJmnX+jYE4S43KGGlZJFIBJ fD7LHY+rDP09Hygnb2d7yy8FMZHkOvAhdhOOS6GJfhx6QjUYBPCawVnUnld4yWy2jRVG76KK2 bMCgXtNkNGcOCImvSEHY1LW4ibR8nazkZBltyFWFQXOUggqGjTA2eSi1BIfP52Eb+Jd82qXAE 1+DGzvyz16YlRK0+k/olScNJAAHNMY8N931GDt/jJFXsB24zzvxdYc5NyhsTA6FIr/5GWP45N f8T62u5FioiZiIUxl5/6Ksbr5vohXYzR3pop4F+vk2gZamVR7l8KEFmuIkSyKdntcAOtaFr5u a+1utwoJbUHEN6PecD2/nNyEwSwMz757O7sN3fTepn3Mn0rigy98rRala6LkPXJdt4sy/JPSM 8JQSlfug4Ib1IX1rnLw3oLKdMAaBVsYNeCN+V3UWHgDLXDg+Kd5Z3GMsAA6qDAKows5UXKmRq o+glY72VhGi+mE2aNKWROU8cy7FGZTOy1JRA5m/m+n60vLOWuHgG8sZ2luR9PufltfTu9ESKW TVeae4DMRrxH/bR9MRtHf8Lv1lcjz2vvwkRHTgBwbDD0WPvBiR1xCF9aVpi36o+SGCmgZxtHW bdSwhm/USK0AUda93jQMHs5PNniMMuYakMEe5z54a7c7Z7qzbmL1akQaAXEj5Z128h9FvoFwX lg43erlj9pQZ+eNvQRd5seeD+8Z0s28+K8KxY8NyPc6twj//2xS9sCGZI3czu830U2+86r+bW V/1J91uqB93KREG+ffT1Jhiv+ohr1rOWdqZba6lVxp4xoA//j6FF79wFPl3G+Llr2cXFPy/DO z5n/4nBTQXsCtedz+eLw6a+PlByKOvzMEijZTloAEC4T22m9RpuDowFB55duZ8OTBEuCBuSCh pkkENM+DTiJQdd5WBithJAByLUs= Subject: Re: [Starlink] [Rpm] [LibreQoS] [EXTERNAL] Re: Researchers Seeking Probe Volunteers in USA X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2023 18:34:51 -0000 Hi Jeremy, > On Mar 13, 2023, at 18:37, Jeremy Austin wrote: >=20 >=20 >=20 > On Mon, Mar 13, 2023 at 10:26=E2=80=AFAM dan = wrote: >=20 >=20 > If you troubleshoot your ISP based on speed tests you will be chasing > your tail. Meanwhile, that internet facing interface can see the true > numbers the entire time. The consumer is pulling their full capacity > on almost all links routinely even if briefly and can be nudged into > pushing more a dozen ways (including a speed test). The only thing > lacking is a latency measurement of some sort. Preseem and Libreqos's > TCP measurements on the head end are awesome, but that's not available > on the subscriber's side but if it were, there's the full testing > suite. how much peak data, what happened to latency. If you could > get data from the ISP's head end to diff you'd have internet vs isp > latencies. 'speed test' is a stress test or a burn in test in > effect. >=20 > I cannot upvote this enough. I call speed tests =E2=80=94 and in fact = any packet injection doing more than a bare minimum probe =E2=80=94 = destructive testing, and said as much to NTIA recently. [SM] Why? With competent traffic shaping, scheduling and AQM = even a capacity test running at full throttle (like e.g a three minute = bidirectional flent RRUL test) is not destructive to network = responsiveness. I am not saying that the network behaves as if there was = no load, but the old, "stop your downloads I have a VoIP call/vide = conference coming scenario" really only need to happen at networks with = way too little capacity assigned.=20 > The *big problem* (emphasis mine) is that the recent BEAD NOFO, = pumping tens of billions of dollars into broadband, has *speedtests* as = the "proof" that an ISP is delivering. [SM] I respectfully disagree, as long as ISP market and price on = capacity it is not unreasonable to actually have end-users actually = measure capacity. I do agree the way we d this currently is sub-optimal = though. And it is a but unfair to ISPs as other business fields are not = held to such standards. However, my solution would be to hold other = businesses equally to account for their promises, not letting ISPs off = the hook ;) (but easy for me to say, I do not operate/work for an ISP = and likely misunderstand all the subtleties involved). > It's one thing to solve this problem at the ISP and consumer level. = It's another to solve it at the political level. In this case, I think = it's incumbent on ISPs to atone for former sins =E2=80=94 now that we = know that speed tests are not just bad but actively misleading, we need = to provide real tools and education. [SM] +1; however as long as ISP essentially sell capacity, = capacity tests will stay relevant.=20 >=20 > Going back to my previous comment, and no disrespect meant to the CAKE = autorate detection: "How do we distinguish between constrained supply = and reduced demand *without injecting packets or layer violations*?" [SM] Oh, I share this question especially with my cake-autprate = junior partner hat on... in theory one could not only use the organic = load, but also the organic TCP timestamp increases as shown by pping to = estimate times when the load exceeds/meets capacity (I think preseem = have an iron in the fire there as well), but that is also not without = its challenged. E.g. my router sits behind a bridged modem, but accesses = the modem over the same link as the internet and routinely collects data = from the modem, will pping now give the delay to the modem as its = minimal estimate? If it does it is pretty much useless as that RTT is = going to essentially stay flat as it is not affected by the bottleneck = queue to/from the internet... (that is why the autorates opted for = active probes as that allows to select spatially separate reflectors). Regards Sebastian >=20 > --=20 > -- > Jeremy Austin > Sr. Product Manager > Preseem | Aterlo Networks > preseem.com >=20 > Book a Call: https://app.hubspot.com/meetings/jeremy548 > Phone: 1-833-733-7336 x718 > Email: jeremy@preseem.com >=20 > Stay Connected with Newsletters & More: = https://preseem.com/stay-connected/