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 7297E3B29E; Mon, 13 Mar 2023 12:37:02 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1678725417; i=moeller0@gmx.de; bh=cuFcDg8MuR7NCXSX1Ga6/LrEezgxs6KuzQjNAwJU6lI=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=qmuvU3qyXl+k6/wKdo9OrPk3R5mk8HrQEzuM1FvqG+5K2/tMBu7GMOm/8o1xuG2r3 Jo4JDFe6PZIcmXncXIfO6yHFV4N9HmyujpyzFqlv9qST07suT2NbElOJzLbdZ/nWaQ YNKFvLlRXbFHYd1D1dcOHQwXSfEWUs8uQjfXrurtBnsuEi7lGtIQvNLZoud+QZ+Y/Y Yh/JpytzOcZnju/JI+uCFOpdzWoljgwds9ujfAxIbJxu+IBTx7QfsEBcHMakRQhJVk tyQOH1jk9RgflGjhxUCWlcFV6Ec/U5Eo2kvttnGOnjFuZMRN9szpTU39aFnAAZ3O2O X6VIDfWwgeMNA== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([134.76.241.253]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MEUz4-1pmEkd1dhy-00FxjF; Mon, 13 Mar 2023 17:36:57 +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 17:36:56 +0100 Cc: Jeremy Austin , Rpm , libreqos , Dave Taht via Starlink , rjmcmahon , bloat Content-Transfer-Encoding: quoted-printable Message-Id: <13DE6E53-665F-4C20-BBE2-70E685421E9D@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> To: dan X-Mailer: Apple Mail (2.3696.120.41.1.2) X-Provags-ID: V03:K1:xtqXSF9G2jdkYY1ASaOvM2s2bOx42zurETAHKTX7jxg78WCl5m4 E7sX38LYXVPPIybSDxlclzBmisASY9yyAK5M3gKYpO/pfph0bj23a7NdTuludHQJUTrUWfF hP1aZJdzrvmyrSrr/AXoRv5dWDHjBMqDTqt6L+fgtpw/q3mkjFCX3fVNQPrxR5lMdAh3W57 2cJYiGc3GcqBS05Z/Ljiw== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:v5yhjlTYiC8=;+m4Id5+uRCWbLHn0JEyXgfV2eAw TPQdRh39pEmo5TN8x3seKnTDvlDjxtXvNqex4vJYGNsouHDBATbT7XBsC8RKRfzPcgSlXwZa9 tJfC1jJrs0rzTpirsX7x+yR0FRkXVlEIpITJ2LGLMUMW6I1qn/6xcZbR7RwVP5yWovTXW/2z2 LTFvo+j/z0CyS6Fuon8cgV2cF6LRI8a+3IjyeWXpKA52Z3yS9g2lSoT7oX8wDEYTYJXuI0swO bMR0Q8ItUo0DsP857SyNkbGH0JqQu6L8tUcYUr74Whzdj0AzrBm1xjFDh27Q9qt16IO6xTig8 4CYwFLDfIkK7DqP7bUATh5OJGku8BRR8Uds9/bvgKQlxwyMol9m4T824HzfTs9ETKRBXmml8e EMEgcp1KU0zf0zDFruSIm07YC6aD33WlsSiy53Be/jHt9PROVUxmDMay43gFc+lGKRw9bw+T0 QLXphW6zaLu0nL2qIhZsnFL/6rnQujRrdPxf0X7uIXaCMmBIZRGiUDjcEQYvbnR/PKdJoyKSk kGC26whFQPazw8U8hjUXGfoXir/eqz1cE8xEVMehFiQTTvm40ISJaTttcE39e3T2Z3DYt3Vp6 U/MeuNMaMwb/rcqE9hrulbtYKJAdzzViF2bYJN0jTIxzhXqsiXWq9Ki9bVnA6awgbZUuR2H4v hkjehKxb3KQ5aT9HHVx06H1SORAZmX4mtRsvKOHF9bf8o/okZYnEzkkwUsGq7rWgbE1U38ypR P+ARYEO5zwmrm8JRhwqF4vOLaAXwqgkTjhH4/NnuGKoYbiLl+IuzwZi/7zMZj+4T+2uj7vJYT HDe95QKHOog9W/kBtnL0YJfI1O+g4aVkVl5z2arRZ04tJIR7KLV9heEWQmnN4WbXWm8fQnl4K 6hYmNAiJzf4MrZMW4qs/vRkBGETr2AaF2linnWY06AdgU2QFjxLudbtCbsj4EEM5MjYsRiPii Px5gxx7TZ7hPfzGb2QjHQfeBpFI= 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 16:37:02 -0000 Hi Dan, > On Mar 13, 2023, at 17:12, dan wrote: >=20 > " [SM] For a home link that means you need to measure on the router, > as end-hosts will only ever see the fraction of traffic they > sink/source themselves..." > & > [SM] OK, I will bite, how do you measure achievable throughput > without actually generating it? Packet-pair techniques are notoriously > imprecise and have funny failure modes. >=20 > High water mark on their router. =20 [SM] Nope, my router is connected to my (bridged) modem via = gigabit ethernet, with out a traffic shaper there is never going to be = any noticeable water mark on the router side... sure the modem will = built up a queue, but alas it does not expose the length of that DSL = queue to me... A high water mark on my traffic shaped router informs me = about my shaper setting (which I already know, after al I set it) but = little about the capacity over the bottleneck link. And we are still = talking about the easy egress direction, in the download direction = Jeremy's question aplied is the achieved thoughput I measure limited by = the link's capacity of are there simply not enoiugh packet = available/sent to fill the pipe. > Highwater mark on our CPE, on our > shaper, etc. Modern services are very happy to burst traffic. [SM] Yes, this is also one of the readons, why = too-little-buffering is problematic, I like the Nichols/Jacobsen analogy = of buffers as shiock (burst) absorbers. > Nearly > every customer we have will hit the top of their service place each > day, even if only briefly and even if their average usage is quite > low. Customers on 600Mbps mmwave services have a usage charge that is > flat lines and ~600Mbps blips. [SM] Fully agree. most links are essentially idle most of the = time, but that does not answer what instantaneous capacity is actually = available, no? >=20 > " [SM] No ISP I know of publishes which periods are low, mid, high > congestion so end-users will need to make some assumptions here (e.g. > by looking at per day load graphs of big traffic exchanges like DE-CIX > here https://www.de-cix.net/en/locations/frankfurt/statistics )" >=20 > You read this wrong. Consumer routers run their daily speeds tests in > the middle of the night. [SM] So on my turris omnia I run a speedtest roughly every 2 = hours exactly so I get coverage through low and high demand epochs. The = only consumer router I know that does repeated tests is the IQrouter, = which as far as I know schedules them regularly so it can adjust the = traffic shaper to still deliver acceptale responsiveness even during = peak hour. > Eero at 3am for example. Netgear 230-430am. [SM] That sounds"specisl" not a useless daa point per se, but of = limited utility during normal usage times. > THAT is a bad measurement of the experience the consumer will have. [SM] Sure, but it still gives a usable reference for "what is = the best my ISP actually delivers" if if the odds are stacked in his = direction. > It's essentially useless data for the consumer unless they are > scheduling their downloads at 3am. Only a speed test during use hours > is useful and that's also basically destructive unless a shaper makes > sure it isn't. >=20 > re per segment latency tests " [SM] Well is it really useless? If I > know the to be expected latency-under-load increase I can eye-ball > e.h. how far away a server I can still interact with in a "snappy" > way." >=20 > Yes it's completely useless to the customer. only their service > latency matters. [SM] There is no single "service latency" it really depends on = he specific network paths to the remote end and back. Unless you are = talking about the latency over the access link only tere we have a = single number but one of limited utility. > My (ISP) latency from hop 2 to 3 on the network has > zero value to them. only the aggregate. per segment latency testing > is ONLY valuable to the service providers for us to troubleshoot, > repair, and upgrade. Even if a consumer does a traceroute and get's > that 'one way' testing, it's irrelevant as they can't do anything > about latency at hop 8 etc, and often they actually don't know which > hops are which because they'll hidden in a tunnel/MPLS/etc. [SM] Yes, end-users can do little, but not nothing, e.g. one can = often work-around shitty peering by using a VPN to route one's packets = into an AS that is both well connected with one's ISP as well as with = one's remote ASs. And I accept your point of one-way testing, getting a = remote site at the ight location to do e.g. reverse tracerputes mtrs is = tricky (sometimes RIPE ATLAS can help) to impossible (like my ISP that = does not offer even simple lookingglas servers at all)). >=20 >=20 >=20 > On Mon, Mar 13, 2023 at 9:50=E2=80=AFAM Sebastian Moeller = wrote: >>=20 >> Hi Jeremy, >>=20 >>> On Mar 13, 2023, at 16:08, Jeremy Austin wrote: >>>=20 >>>=20 >>>=20 >>> On Mon, Mar 13, 2023 at 3:02=E2=80=AFAM Sebastian Moeller via = Starlink wrote: >>> Hi Dan, >>>=20 >>>=20 >>>> On Jan 9, 2023, at 20:56, dan via Rpm = wrote: >>>>=20 >>>> You don't need to generate the traffic on a link to measure how >>>> much traffic a link can handle. >>>=20 >>> [SM] OK, I will bite, how do you measure achievable = throughput without actually generating it? Packet-pair techniques are = notoriously imprecise and have funny failure modes. >>>=20 >>> I am also looking forward to the full answer to this question. While = one can infer when a link is saturated by mapping network topology onto = latency sampling, it can have on the order of 30% error, given that = there are multiple causes of increased latency beyond proximal = congestion. >>=20 >> So in the "autorates" a family of automatic tracking/setting = methods for a cake shaper that (in friendly competition to each other) = we use active measurements of RTT/OWD increases and there we try to vary = our set of reflectors and then take a vote over a set of reflectors to = decide "is it cake^W congestion", that helps to weed out a few = alternative reasons for congestion detection (like distal congestion to = individual reflectors). But that dies not answer the tricky question how = to estimate capacity without actually creating a sufficient load (and = doubly so on variable rate links). >>=20 >>=20 >>> A question I commonly ask network engineers or academics is "How can = I accurately distinguish a constraint in suppl from a reduction in = demand?" >>=20 >> Good question. The autorates can not, but then they do not = need to as they basically work by upping the shaper limit in correlation = with the offered load until it detects sufficiently increased delay and = reduces the shaper rates. A reduction n demand will lead to a reduction = in load and bufferbloat... so the shaper is adapted based on the demand, = aka "give the user as much thoughput as can be done within the users = configured delay threshold, but not more"... >>=20 >> If we had a reliable method to "measure how much traffic a link can = handle." without having to track load and delay that would save us a ton = of work ;) >>=20 >> Regards >> Sebastian >>=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