From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 DD51F3B29E; Tue, 14 Mar 2023 05:11:59 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1678785114; i=moeller0@gmx.de; bh=xYfYNwLLg8YnWTEx8+OJSnIqIKYF1vNdV/gvDioZFLU=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=Sm5axBIUxKb/gmtXYcztWar80dHmdWYNx0AxSX8P1Qnf+xvZMIVyJHznW/0nHIXPh 2MuSzEAYrT/q6Wum2WKYkMG1xt/rooZcqps7jDhyBx2psJVyicL2Dk2C7fFpsrmDwA weB0QNKXm+DoXX9tpCKI/ErhohCVlbFZNUSlDZS4qv8zAT6L+QEkeHQZti5dWpqGgT 3Ue+jQZJHeauT7AN5hw8rVaH3i2p9E/ougGM3SfNhA223HXgkuOuwllWwOwIKGa6f1 LLLjxVKR8stA+907nRwdE3mjAF1BP1Gtqdy+8h+lANDLZWn+N/gc97ylPYLyHkkE+j CTw5P0+k2KDkQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([78.50.125.61]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MtOGa-1qWrAq0tSg-00urgf; Tue, 14 Mar 2023 10:11:54 +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: Tue, 14 Mar 2023 10:11:53 +0100 Cc: Rpm , libreqos , Dave Taht via Starlink , rjmcmahon , bloat , Jeremy Austin Content-Transfer-Encoding: quoted-printable Message-Id: <471F544E-6887-4E15-BA28-3D22F6A0214A@gmx.de> 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> <22C819FA-DDD7-4B9B-8C09-8008D4273287@gmx.de> To: dan X-Mailer: Apple Mail (2.3696.120.41.1.2) X-Provags-ID: V03:K1:23WdE+5OBHT/xMMAM30xN2lfhPtKC0I4IpenNycVVMrLI4pSJYR WA47ma65nY6H2kJ0OLmsJsgyskCdk3fgp4gyXZnH0HsCAVO5B3PxLaYfY4fbdpIrGOp0cZI 5kUhqYyKfK3A6F4DOoo9E2XU3fU0htl3yVj4+zEvj39xjFfSjeidHoQYj9ud1D/DkFL78rO 5lK6dOe/zrqhOA47iSHgg== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:Oc+RQGfO/60=;+mWxLBVdYo5mUppwDdHUsIXW+7y 4O3YjpD2+e9rFdYW68eGsFz3E+NYFJM5TqLyV69AhP56exB0ljLms4jnCl40L2fAD1cTVCjgy 69AtWcwP4nZ+82lv5DnkdFM7ROYV/IaMQDdCicb3g0SLiUWdDEkAN7I1ucpujP9nIlltk2BZW ZUf4kVoIGIDCH+j/HxgW86ME6zHz5PLIiJmcWWT4VfAje4k2ScgavUlHQG1fBclZOhYknsoAm QEVSkEbR0ZYN6j5Hh4DI7tMlXKJsHvO5xJziowQWfILlBi7O/IkP1LRxGNTFcE8Di3XmXxiCN h55HTLaESdq4YwKyahNze0pAuA+1a60nhq/BXKDyab2J8LFO9/73GguJ2LwssLn+4UO2iMJ8P RYbSgoG+hZLrgY3LaKyF3xbdUaU2ZbYqX+Q4fhOGLWckGCy1BKaRhpzQthv8dtkww+VzSQ1Ro A8K3RYmkiSdlBn0XQPIeWwostVhEuk4FFejrWHAlRWnl834x+VUiHWJcoTj/qLrRzKs+ah+NF 5Uyci7Kp90IHsg1fkmgd/LFb6/BlCY2IMTF18reTIZNuoCadmXmIqhmNhAZOIdAHWv7xhpLPT 9ON4pKQO9dxw3bIMYmUZJouDlqjkCb7fJzHSzP7YPNAp5iLk4U2x0ino0oBFU5XC6BCKj8L9Y ZsuyimkQMQ/rIlRpw/BZYkRX8fCxnk91msjuA8/u0obfseqwLmcKjSz98Ir/ScbO1E5M01uc5 M5gJIf9+66ccF76s6hEVUtRr3BUJwTzuSSbs1u8lYVDFFIPVbzL5UyxgPv4D6MMs00trGNpz6 rATpKXWf2+LFpBZ7BINfb0yuQ14SrxbNja+zpyOviE+i7JGjKrT9DWECkv0s2Ila8MBQkL5ON 7QTwRg/Ymhvt7L+sW1VRwjO3morI/HKmFv9HHkzXKo1kBnn/6rii3FYgqyNn+hV7ISX2EDRZU VBBcHeRQIXjXG1pNF0K/AEqnoic= Subject: Re: [Rpm] [Starlink] [LibreQoS] [EXTERNAL] Re: Researchers Seeking Probe Volunteers in USA X-BeenThere: rpm@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: revolutions per minute - a new metric for measuring responsiveness List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2023 09:12:00 -0000 Hi Dan, > On Mar 13, 2023, at 22:27, dan wrote: >=20 > I=E2=80=99m sticking to my guns on this, but am prepared to let this = particular argument rest. The threads is approaching unreadable. [SM] Sorry I have a tendency of simultaneously pushing multiple = discussion threads instead of focussing on the most important... >=20 > Let me throw something else out there. It would be very nice to have = some standard packet type that was designed to be mangled by a traffic = shaper. So you could initiate a speed test specifically to stress-test = the link and then exchange a packet that the shaper would update both = ways with all the stats you might want. Ie, speed test is getting = 80Mbps but there=E2=80=99s an additional 20Mbps on-link so it should = report to the user that 100M aggregate with the details broken out = usably.=20 [SM] Yeah, that does not really work, the traffic shaper does = not know that elusive capacity either... on some link technologies like = ethernet something reportable might exist, but on variable rate links = not so much. However it would be nice if traffic shapers cpuld be = tickled to reveal their own primary configuration. As I answered to Dave = in a different post we are talking about 4 numbers per shaper instance = here: gross shaper rate, per-packet-overhead, mpu (minimum packet unit), = link-layer specific accpunting (e.g. 48/53 encapsulation for ATM/AAL5) The first two are clearly shaper specific and I expect all competent = shapers to use these; mpu is more a protocol issue (e.g. all link layers = sending partial ethernet frames with frame check sequence inherit = ethernets minimal packet size of 64 byte plus overhead. For my own shaper I know these already, but my ISPs shapers are = pretty opaque to me, so being able to query these would be great. (BTW, = for speedtests in dispues with my ISP, I disable my traffic shaper = obviously that capacity loss is not in their responsibility). > Could also report to that speed test client and server things like = latency over the last x minutes along [SM] A normal shaper does not know this... and even = cake/fq_codel that measure sojourn time per packet and have a decent = idea about a packets flow-identity (not perfect as there is a limited = number of hash buckets). It does not report anything useful in regards = to "average" sojourn time for the packets in the measurement flows... = (it would need to know when to start and when to stop at the very = least). Honestly this looks more like a post-hoc job to be performed on = packet captures than an on-line thing expected from a = traffic/shaper/AQM. > with throughput so again, could be charted out to show the =E2=80=98good= put=E2=80=99 and similar numbers. [SM] Sorry to sound contrarien, but goodput is IMHO a number = quite relevant to end-users, so that speed tests report an estimate of = that number is A-OK with me, but I also understand that speedtest can = not report the veridical gross bottleneck capacity in all cases anyway, = due to lack of important information. > Basically, provide the end user with decently accurate data that = includes what the speed test app wasn=E2=80=99t able to see itself.=20 [SM] Red herring IMHO, speedtests have clear issues and = problems, the fact that they do not measure 100% of packets traversing a = link is not one of them IMHO, they mostly are close enough to the = theoretical numbers that differences can simply be ignored... as I said = my ISP provisions a gross DSL sync of 116.7 Mbps but contractually only = asserts a maximum of 100 Mbps goodput (over IPv6), the math for this = works well and actually my ISP tends to over-fulfil the contractual rate = in that I get ~105 Mbps of the 100 my contract promises...=20 Sure personally I am more interested in the actuall gross rate = my ISP sets its traffic shapers for my link too, but generally hitting = the contract numbers is not rocket science if one is careful which rate = to promise... ;) > It could also insert useful data around how many packets arrived that = the speed test app(s) could use to determine if there are issues on wan = or lan. =20 [SM] I think speedtests should report: number of parallel flows, = total number of packets, total number of bytes transferred, number of = retransmits, and finally MTU and more importantly for TCP MSS (or = average packet size, but that is much harder to get at with TCP). AND = latency under load ;) >=20 > I say mangle here because many traffic shapers are transparent so the = speed test app itself doesn=E2=80=99t really have a way to ask the = shaper directly.=20 [SM] I am pretty sue that is not going to come... as this smells = like a gross layering violation, unless one comes up with some IP = extension header to add that contains that information. Having = intermediary nodes write into payload area of packets, is frowned upon = in the IETF IIRC... >=20 > My point in all of this is that if you=E2=80=99re giving the end user = information, it should be right. No information is better than false = information. [SM] A normal speedtest is not actually wrong, just because it = is not 100% precise and accurate. At the current time users operating = traffic shaper can be expected to turn that off during an official = speedtest. If a user wanted to cheat and artificially lower their = achieved rates there is way more bang for you buck in either forcing IP = fragmentation or using MSS clamping to cause the speedtest to use = smaller packets. This is not only due to the higher overhead fraction = for smaller packets, but simply because in my admittedly limited = experience few CPE seem prepared for the PPS processing required for = dealing with a saturating flow of small packets.=20 However cheating in official tests is neither permitted nor to = be expected (most humans act honestly). Between business partners like = ISP and customer there should be an initial assumption of good will in = either direction, no? > End users will call their ISP or worse get on social media and trash = them because they bought a $29 netgear at Walmart that is terrible. [SM] Maybe, but unlikely ot affect the reutation of an ISP = unless that is not a rare exception but the rule.... think about reading = e.g. amazon 1 star reviews, some read like a genuine faulty product and = sone clearly show the writer had no clue... same is true for social = media posts unless you happen to be in the center of a veritable shit = storm a decent ISP should be able to shrug off a few negative comments, = no? Over here from looking at ISPs forum, the issue is often = reversed, genuine problem reports are rejected because end-users did not = use the ISP supplied router/modem... (and admittedly that can cause = problems, but these problems are not guaranteed). >=20 > After all the entire point if all of this is end-user experience. The = only benefit to ISPs is that happy users are good for business. [SM] A customer that can confirm and see that what their ISP = promised is what the ISP actually and delivers likely to feel validated = for selecting that ISP. As a rule happy customers tend to stick... > A lot of the data that can be collected at various points along the = path are better for ISPs to use to update their networks to improve user = experience, but aren=E2=80=99t so useful to the 99% of users that just = want low =E2=80=98lag=E2=80=99 on their games and no buffering. >=20 >=20 >=20 >=20 > On Mar 13, 2023 at 3:00:23 PM, Sebastian Moeller = wrote: >> Hi Jeremy, >>=20 >>> On Mar 13, 2023, at 20:52, Jeremy Austin wrote: >>>=20 >>>=20 >>>=20 >>> On Mon, Mar 13, 2023 at 12:34=E2=80=AFPM dan = wrote: >>>=20 >>> See, you're coming around. Cake is autorating (or very close, 'on >>> device') at the wan port. not the speed test device or software. = And >>> the accurate data is collected by cake, not the speed test tool. = That >>> tool is reporting false information because it must, it doesn't know >>> the other consumers on the network. It's 'truest' when the network = is >>> quiet but the more talkers the more the tool lies. >>>=20 >>> cake, the kernel, and the wan port all have real info, the speed = test >>> tool does not. >>>=20 >>> I'm running a bit behind on commenting on the thread (apologies, = more later) but I point you back at my statement about NTIA (and, to a = certain extent, the FCC):=20 >>>=20 >>> Consumers use speed tests to qualify their connection. >>=20 >> [SM] And rightly so... this put a nice stop to the perverse practice = of selling contracts stating (up to) 100 Mbps for links that never could = reach that capacity ever, now an ISP is careful in what they promise... = Speedtest (especially using the official speedtest app that tries to = make users pay attention to a number of important points, e.g. not over = WiFi, but over an ethernet port that has a capacity above the contracted = speed) seem to be good enough for that purpose. Really over here that is = the law and ISP still are doing fine and we are taking low single digit = thousands of complaints in a market with ~40 million households. >>=20 >>>=20 >>> Whether AQM is applied or not, a speed test does not reflect in all = circumstances the capacity of the pipe. One might argue that it seldom = reflects it. >>=20 >> [SM] But one would be wrong, at least the official speedtests over = here are pretty reliable, but they seem to be competenyly managed. E.g. = users need to put in the contracted speed (drop down boxes to the select = ISP and contract name) and the test infrastructure will only start the = test if it managed to reserver sufficient capacity of the test servers = to reliably saturate the contracted rate. This is a bit of engineering = and not witchcraft, really. ;) >>=20 >>> Unfortunately, those who have "real info", to use Dan's term, are = currently nearly powerless to use it. I am, if possible, on both the ISP = and consumer side here. >>=20 >> [SM] If you are talking about speedtests being systemicly wrong in = getting usabe capacity estimates I disagree, if your point is that a = sole focus on this measure is missing the way more important point od = keeping latency under load limited, I fully agree. That point currently = is lost on the national regulator over here as well. >>=20 >>> And yes, Preseem does have an iron in this fire, or at least a dog = in this fight. >>=20 >> [SM] Go team! >>=20 >>> Ironically, the FCC testing for CAF/RDOF actually *does* take = interface load into account, only tests during peak busy hours, and = /then/ does a speed test. But NTIA largely ignores that for BEAD. >>=20 >> [SM] I admit that I have not looked deeply into these different test = methods, and will shut up about this topic until I did to avoid wasting = your time. >>=20 >> Regards >> Sebastian >>=20 >>=20 >>>=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/ >>=20