From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 9569C3B29E; Mon, 13 Mar 2023 12:13:06 -0400 (EDT) Received: by mail-yb1-xb2c.google.com with SMTP id u5so3980940ybm.7; Mon, 13 Mar 2023 09:13:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678723986; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Q3MgPC0yMTmta6L6kv+5kzpEQPcorO+H2/nehXk00TU=; b=YmaF1lqmOojgdzJ744ezcjv4eA8zt3boVcUrpJb7pZHvhdtMT7J3fmIm35ffSrjw+v xITiKkUnip62ffiJf0BktU165uQcZslKFN+1bIrZwWm8O/ifisMjhLa6O3Y6cAU7i3te r4yua+Zb9etrVxbAl7HG3Ldqlp4tZzSVV+ZIdJteQIGoD7cijGoHoNX2ssz2ACH/4cpI SmMKtkb7HCqXghvDAn6CGiYT4aFabIYowRP1UOvU4BMXA491wHRYox5HlW2PQpT3b8ZX IXY8ZVTDs/G+Rr4EWWVsd95Mmab5lNoVrqzLFsl8jeBtsvBDPac1cri3j0W4RMpPQw4C BeEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678723986; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Q3MgPC0yMTmta6L6kv+5kzpEQPcorO+H2/nehXk00TU=; b=dOBj4w/nMOj351o8tjLRdUcY/YTItNKq0r1btjwwPn9raKdq5Xrjbedt7cc+oHYF4Z FpHyTeyqprVy+frDcI5J/fpJfpnfTzYRJWXtJrtQHP5wxLM9IO2iGfy7VG4FzluU9oB2 VAQHeZOGg+HrUlXQgzByTsVWWQCN1BaE8Ei1Jo2p84WIUs79X/X8vQvb5CseiD/qoUUb ZOM5ZKAZp0pdBoAK1RXAI1l9EzEzwAZNMwtywxWbLq8jRoNKkfvA1Q2EGavV9VLExawF tVpHx3JnCBeen2pfL2P5M1Oz4GumnCyG7Vr1qnC84o0/WrH6KLrKeafr5816nCz+HnYS ILig== X-Gm-Message-State: AO0yUKW7HgztNlI83ASsfJ5yKTNjEhIkvXR3EjYeui5+Fb5DsYkoSbMq AhnuYQtngR52nMglDjfcynsb82UpAMM0/SEyP1E= X-Google-Smtp-Source: AK7set8dmnEPBJffVWbB6WA/DHKePY8/FmRYVXkSeU2GZGU6by3F2w2wfAUssRpOV/1NpSMmlfbSlBOpYKWmy4gRhDQ= X-Received: by 2002:a5b:b4b:0:b0:afd:2ef2:33c2 with SMTP id b11-20020a5b0b4b000000b00afd2ef233c2mr7316597ybr.2.1678723985819; Mon, 13 Mar 2023 09:13:05 -0700 (PDT) MIME-Version: 1.0 References: <1672786712.106922180@apps.rackspace.com> <77CCAD19-07E0-4F9E-88C1-D207CF7BF376@cable.comcast.com> <83ffc0dad19e3343e49271889369cefc@rjmcmahon.com> <3CD0B9E6-0B2A-4A70-8F53-ED0822DF77A6@gmx.de> In-Reply-To: <3CD0B9E6-0B2A-4A70-8F53-ED0822DF77A6@gmx.de> From: dan Date: Mon, 13 Mar 2023 10:12:54 -0600 Message-ID: To: Sebastian Moeller Cc: Jeremy Austin , Rpm , libreqos , Dave Taht via Starlink , rjmcmahon , bloat Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Bloat] [Starlink] [Rpm] [LibreQoS] [EXTERNAL] Re: Researchers Seeking Probe Volunteers in USA X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2023 16:13:06 -0000 " [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. High water mark on their router. Highwater mark on our CPE, on our shaper, etc. Modern services are very happy to burst traffic. 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] 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 )" You read this wrong. Consumer routers run their daily speeds tests in the middle of the night. Eero at 3am for example. Netgear 230-430am. THAT is a bad measurement of the experience the consumer will have. 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. 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." Yes it's completely useless to the customer. only their service latency matters. 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. On Mon, Mar 13, 2023 at 9:50=E2=80=AFAM Sebastian Moeller = wrote: > > Hi Jeremy, > > > On Mar 13, 2023, at 16:08, Jeremy Austin wrote: > > > > > > > > On Mon, Mar 13, 2023 at 3:02=E2=80=AFAM Sebastian Moeller via Starlink = wrote: > > Hi Dan, > > > > > > > On Jan 9, 2023, at 20:56, dan via Rpm wro= te: > > > > > > You don't need to generate the traffic on a link to measure how > > > much traffic a link can handle. > > > > [SM] OK, I will bite, how do you measure achievable throughput = without actually generating it? Packet-pair techniques are notoriously impr= ecise and have funny failure modes. > > > > I am also looking forward to the full answer to this question. While on= e can infer when a link is saturated by mapping network topology onto laten= cy sampling, it can have on the order of 30% error, given that there are mu= ltiple causes of increased latency beyond proximal congestion. > > So in the "autorates" a family of automatic tracking/setting meth= ods for a cake shaper that (in friendly competition to each other) we use a= ctive 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 co= ngestion detection (like distal congestion to individual reflectors). But t= hat dies not answer the tricky question how to estimate capacity without ac= tually creating a sufficient load (and doubly so on variable rate links). > > > > A question I commonly ask network engineers or academics is "How can I = accurately distinguish a constraint in suppl from a reduction in demand?" > > Good question. The autorates can not, but then they do not need t= o 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 bu= fferbloat... so the shaper is adapted based on the demand, aka "give the us= er as much thoughput as can be done within the users configured delay thres= hold, but not more"... > > If we had a reliable method to "measure how much traffic a link can handl= e." without having to track load and delay that would save us a ton of work= ;) > > Regards > Sebastian > > > > > > -- > > -- > > Jeremy Austin > > Sr. Product Manager > > Preseem | Aterlo Networks > > preseem.com > > > > Book a Call: https://app.hubspot.com/meetings/jeremy548 > > Phone: 1-833-733-7336 x718 > > Email: jeremy@preseem.com > > > > Stay Connected with Newsletters & More: https://preseem.com/stay-connec= ted/ >