From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 2DE5F3B29E; Mon, 13 Mar 2023 12:19:28 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1678724363; i=moeller0@gmx.de; bh=K9tr1A4Ry20htnzWCbJgCtZ9/+3FOB4YoMWCljGhg3Y=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=G3OOM8RN62/c/B8Ms5dz/nb9rCSHWbUka1nep1AODiErIDpdtkHExruVd0VpqyZtV 0fNj0OV444/a3l1TGDDYLsPJeybk5mWyQIpdCyQMDd1m5d49z2aOcPzRJjzQdJZTb7 aZHcI5BGFza6HXPpojXLZsiE94h66PfOG0s+ODLO1/+RWEbAzxheIHcJVfPg1MFQGq VoEHK57aJoC3SgqaksEQBq7EPGIbXn6uXnkynZhTR3Cj3ppVt2KwypNEHfCv7nGUxO KgmxLT2rfhdEiry/c/9X1jqwgQ6PF/FPeaoi37nB0ly7Z4xCabXR785PiPV1xg7Blo VPmhaeH7qJOPQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([134.76.241.253]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MjS9I-1qHAWX0QDS-00kvIu; Mon, 13 Mar 2023 17:19:23 +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:19:22 +0100 Cc: Jeremy Austin , Dave Taht via Starlink , dan , libreqos , Rpm , 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> To: =?utf-8?Q?Dave_T=C3=A4ht?= X-Mailer: Apple Mail (2.3696.120.41.1.2) X-Provags-ID: V03:K1:XehGZeaxBsU7RX9UXBiRGX/yxL0VTnpfO88PWwZDaP7uuEcHz+M Xt+zcizBtLUtsqInPM2YaHCddXXLhtmeSBFHITaCSv+oImu9JbFUi3pw/Q9KbjzkLQat0Cl gfxeK3bR4Dk8YSQyY3OQe3B+R0O0BJeefaKqeFrIrZhq0ckUoWqCOkpKoY4miRAmbjROS+U 2cUkwt/AqVejoTIlPKyFQ== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:cExn1e9JEds=;OIhiKa4awr1cq/W2eodecpyNQj8 gQlwzTk9hA5Ih7bOon2A8zJ6gteIEJlolLRFnUuGHKEq/3lSFwIHl8jf3DRTTII6Ih5PG+ZlP BxmlGOyVXFH8Hugp6cA9aVCVm6D4hWNFvGdeQ0uCDbp54+3O83wW0pFraMfVFQ+MEt0FCV7i6 nzKGtE6bhhMeYGsa5+d2DCukg+inJn/kgww0jX7+Fc/+RPnGqnRSUqYHeIxx9NFaf/jJCvLGU 5AXmlwgV8lBJkNugyW0W7QL0srNoMEttBZ3Y6xXz7C/mSBQ6e3Ej6+ggUAxA+nYoOGHX2RY/I azJNUXwVgBXCxUo4W/ag8kPyXeBQQIXHjmKlR1tOP+VgcH75cuy1qcTx1CVNE3EuDnyVOTP96 X3QTYoo2JDDPpMF2qUqDrszkG8U2tvt+0r6LG12ixyP/oooZ9erqSTn9kVyfaamazvUfvUCit S0o26ge+3b+bvEQrSgNRIYVqGO7vgPH5kCOabrQkGEXxrvV1zxXrC3LkwjViaCc3R3mIAbMX9 D2CZpCr7QitcqzO97bcD2ZOhkkeDN7knBQoKb3W2WISQrGDz5gsHCgWI9cCj5UropUc+ciemN bSiXvEJVxl/mnnEE2JfMwr4UoFRrSjASkUg7jKDTdhjaGS8qJpUnYUespPKXR3kCWQOYmRPRe i4Yi6Rgh4QL7Q+ExTspV6PzE/9fIyzwaamO1Q2bIJv86pYHd5HfVcmUu+qqFzMq00+aTP+HwD 4nOb1y1nGQi6ThCxU4DhRb9bMLoiys9UQ0Lj6aoxzxyiCxjIAInopOD6k9kKeHBATnVvBgBjo pgaGlp9kH+ESLs0wdPntheQ7H5zQl6eElO5vresJacVWoxonTMQ4DviUQWm7GImcN1g5NHx2R 1LZmJmXm/qJfCvhaqxUQJNiEWQ3/PCqgF8s5uzvmWG0BlHIP5eVrxma6epxizdy8zcihEKxvi V6d/ywlfoEDAauh4seYzgY18Xl8= Subject: Re: [Starlink] [Bloat] [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:19:28 -0000 Hi Dave, > On Mar 13, 2023, at 17:06, Dave Taht wrote: >=20 > On Mon, Mar 13, 2023 at 8:50=E2=80=AFAM Sebastian Moeller via Bloat > 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 > My hope has generally been that a public API to how much bandwidth the > ISP can reliabily provide at that moment would arise. There is one for > at least one PPOe server, and I thought about trying to define one for > dhcp and dhcpv6, but a mere get request to some kind of json that did > up/down/link type would be nice. [SM] The incumbent telco over here (and one of its competitors) = indeed encode the rate the traffic shaper for an individual link is set = via the PPPoE AuthACK message field (both ISPs use a slightly different = format with one giving net rate and the other gross rates, but that can = be dealt with). However this is not adjusted during load periods. So = this still describes the most likely bottleneck link well (albeit only = once per PPPoE session, so either every 24 hours or in the limit every = 180 days with the incumbent) but does little for transient congestion of = up- or downstream elements (in their defense the incumbent mostly = removed its old aggregation network between DSLAMs and PPPOE termination = points so there is little on that side than can get congested). If this was a pony ranch, I would ask for: downstream gross shaper rate downstream per packet overhead downstream MTU downstream mpu upstream gross shaper rate upstream per packet overhead upstream MTU upstream mpu the last three likely are identical for both directions, so we are = essentially talking about 5 numbers, of which only two can be expected = to fluctuate under load. Now, a competent ISP would ask why do my users want to know that and the = simply implement sufficiently competent AQM/traffic shaping at the = download side ;) in addition to these 5 numbers. Regards Sebastian >=20 >=20 >>=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 >> _______________________________________________ >> Bloat mailing list >> Bloat@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/bloat >=20 >=20 >=20 > --=20 > Come Heckle Mar 6-9 at: https://www.understandinglatency.com/ > Dave T=C3=A4ht CEO, TekLibre, LLC