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 287403B2A4 for ; Wed, 2 Nov 2022 04:24:07 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1667377439; bh=aLt911BbA3ibVEwE74mm+qdroQk7b1of6R6kBxUHDQ0=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=luDC3Z8JTVq3pmjZAa6xftBhxm8WP6IZ94ukC7uTnIZP2vVOxLBqin1KSYXb9de9/ zPV6hmicCXjezeb3//MMXAKvroci+Oq2PtnPTixC/lU/NfhY04TcCwJyYeFWTTmQ1q mhzLS9mC827fyVV9KQlDW7mJJ0FqDvNZmVOwEJBIyqdW3aQX6+q9zmeY30TQYJDIsr e2qvyf9fac5FpQV0eQGgeTqSj9I7RRBjpsR8SzIuezQKi4EdndbjcMhY+Gvquc5J1u MsldEuYiRbrYsH/1PFH3Yw1w658ndKEM1fIGshcArk70SGVgcBqWGUNx65HILZcHK8 9GTf4gQ4ULojQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([134.76.241.253]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MLR1V-1oYLCm2aBP-00IT27; Wed, 02 Nov 2022 09:23:59 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) From: Sebastian Moeller In-Reply-To: <344f2a33b6bcae4ad4390dcb96f92589@rjmcmahon.com> Date: Wed, 2 Nov 2022 09:23:57 +0100 Cc: =?utf-8?Q?Dave_T=C3=A4ht?= , Rpm , "MORTON JR., AL" , ippm@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <261B90F5-FD4E-46D5-BEFE-6BF12D249A28@gmx.de> References: <0a8cc31c7077918bf84fddf9db50db02@rjmcmahon.com> <344f2a33b6bcae4ad4390dcb96f92589@rjmcmahon.com> To: rjmcmahon X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Provags-ID: V03:K1:cV7wRfeYZWJEE2GAjXqnW7Y7YQDDazmQOqU+uGudipghXIWxL5o LtSLimL5rw6wTGurAo4qrVZ8RegEXHciidn8/8EiQDcgsjP7/9Nc6fjM8bRIybava4a1kmK ShnrVnsdq+QJCtaqWx93hasZV+kh4c0WdvZfgWHLADSyDR4f4SCg9bi1pb78h73f1SxBIVF iwUnnJNAbWClOVTyf+JIg== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:dXEIc9hDJp8=;CDr82EWuUPG++mMFxjzo51u5WF7 lknkGHNCLnZG8yrSwARWwp/DHn9yTL9W8Zff7e92sP780fpWT4SjCaLwoGFBFCicngDaoReGl 5CHTxLQjg3dR4VyKSbYVeZ+PWKOTUuc5qazit4hkl/I1oulPyGoAsIfvciSeUd5HDN2s3PpGy pjpaQ3MXX0eGHE1plwrjehUzXXAUq/pmYL9/PvkRy8MFb99fcMFrN3mhfOE+CwictjuvdWLZd of/tB0JxgMe1uri6V4lzMVSiBhGCGKPjoVLgSNIO9jwqQS7owDx2Z1cwdiFIIP465mm5Ggi3y moU8mhXq0aWvOcFUUoZXqHCzlaHvrBoAQFi5RLiCHKk4ASQMMD6o0jfWQ6d/3oMc6ATTjuIMu BzM6uqI/G0LneTcV9rc5aJpmJDwqj9dvsq8BHBv86l/tPDHNT1mKRF/7L6m7GV/BWbVWCzEgs D2tgs2MKmTn7tFytu71vZoWdn4QQ8FeR3KH7nWq6BkO69W1nyp1taV5c8nEY0HgoSrVsUKvXO WqkDPLKM5FR5f2VZVh+FJwh1xYFraXv1R9/R66+U5qKAjPZ+ljAQFEBR/nRP3VJtz2LhkvLuk UmrTFJCnwykCeSZCR7DAKaEEs9XP8FrjvGIjBwMSmg+nKlT77FZpLr2hZM0zvq4kQaJ3zGUKX gLCH1p+WCNH+aqRfSd9SU8sSYj5kGvbs3nrN2UGeUUUVh6TehonPBRWEVLt5XFQqvZWr8JhUK /LI5HKsUAF/xx7bWZoaQHlDkQ1+jct2kB/tddXfh2xIqputcCVIUOzZcBIvhdyCISWM9AUfxQ fZi4eEXDv0dpU+qZ8zvBAFbtHXZQZA0vO1/ctEefl3DLQAzvsgFDIGCzPXMDEpUETicBSW9Ht c7IbkldzNABY9r7yTSfsNvTr6Ao6tbkcPLOZjSf7whJY/n3cbCfmKz7iAXeAyAcAKYfJpRJu2 KdsjohXJCr12d8kmplcOXUO2BDw= Subject: Re: [Rpm] lightweight active sensing of bandwidth and buffering 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: Wed, 02 Nov 2022 08:24:07 -0000 Hi Bob, thanks! > On Nov 2, 2022, at 00:39, rjmcmahon via Rpm = wrote: >=20 > Bufferbloat shifts the minimum of the latency or OWD CDF. [SM] Thank you for spelling this out explicitly, I only worked = on a vage implicit assumption along those lines. However what I want to = avoid is using delay magnitude itself as classifier between high and low = load condition as that seems statistically uncouth to then show that the = delay differs between the two classes;).=20 Yet, your comment convinced me that my current load threshold = (at least for the high load condition) probably is too small, exactly = because the "base" of the high-load CDFs coincides with the base of the = low-load CDFs implying that the high-load class contains too many = samples with decent delay (which after all is one of the goals of the = whole autorate endeavor). > A suggestion is to disable x-axis auto-scaling and start from zero. [SM] Will reconsider. I started with start at zero, end then = switched to an x-range that starts with the delay corresponding to 0.01% = for the reflector/condition with the lowest such value and stops at = 97.5% for the reflector/condition with the highest delay value. My = rationale is that the base delay/path delay of each reflector is not all = that informative* (and it can still be learned from reading the x-axis), = the long tail > 50% however is where I expect most differences so I want = to emphasize this and finally I wanted to avoid that the actual "curvy" = part gets compressed so much that all lines more or less coincide. As I = said, I will reconsider this *) We also maintain individual baselines per reflector, so I could just = plot the differences from baseline, but that would essentially equalize = all reflectors, and I think having a plot that easily shows reflectors = with outlying base delay can be informative when selecting reflector = candidates. However once we actually switch to OWDs baseline correction = might be required anyways, as due to colck differences ICMP type 13/14 = data can have massive offsets that are mostly indicative of un synched = clocks**. **) This is whyI would prefer to use NTP servers as reflectors with NTP = requests, my expectation is all of these should be reasonably synced by = default so that offsets should be in the sane range.... >=20 > Bob >> For about 2 years now the cake w-adaptive bandwidth project has been >> exploring techniques to lightweightedly sense bandwidth and = buffering >> problems. One of my favorites was their discovery that ICMP type 13 >> got them working OWD from millions of ipv4 devices! >> They've also explored leveraging ntp and multiple other methods, and >> have scripts available that do a good job of compensating for 5g and >> starlink's misbehaviors. >> They've also pioneered a whole bunch of new graphing techniques, = which >> I do wish were used more than single number summaries especially in >> analyzing the behaviors of new metrics like rpm, samknows, ookla, and >> RFC9097 - to see what is being missed. >> There are thousands of posts about this research topic, a new post on >> OWD just went by here. >> https://forum.openwrt.org/t/cake-w-adaptive-bandwidth/135379/793 >> and of course, I love flent's enormous graphing toolset for = simulating >> and analyzing complex network behaviors. > _______________________________________________ > Rpm mailing list > Rpm@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/rpm