From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-x112d.google.com (mail-yw1-x112d.google.com [IPv6:2607:f8b0:4864:20::112d]) (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 988083B29D for ; Wed, 2 Nov 2022 15:44:49 -0400 (EDT) Received: by mail-yw1-x112d.google.com with SMTP id 00721157ae682-3321c2a8d4cso176267697b3.5 for ; Wed, 02 Nov 2022 12:44:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; 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=0IqrH8TWLqt3OLIvoqmHVG7EEJu2CccITfyVmPSQ5zc=; b=Hvliqo7PH850CNEesK0FgxxqVrsfRG5nLK1xcZI5DqqEAMl70AvIzih3TVNpJYCH5s 80nQg2PGX+WQtj84D9Z9ahFEFNtfC/RH4ZrPox6YvIfpnpAxslVkElMJDfWOUiIPjbkS u0WbJMH29mf/IGRGWVpoyrAcDa/mrrUjSoU5oL0beBQYbWXoQHOvdcyCEXT4R3pb+gk4 7rTU4YkAN1kE5nXxwRl3ZuLANvrFfwCB7w+a9CdDh8Q/oEtnrkaHQgG6++4yGzInZHKz WhgX7oXDsc9+nLGHUaOgd2WZtczkxUgnGkS8IFQWfqNDbmEGy8vdy5ky03PWHhdkpzAo yQXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=0IqrH8TWLqt3OLIvoqmHVG7EEJu2CccITfyVmPSQ5zc=; b=wER2LW0cGvEWviVgYnHDkaZLxPjHMMTkdk1vsdUqGpYpCqX6RLodOuYDoCcnv82r1M VTRZDvdME9vTwjRMn5dptQ1bwQrpL/n0rWGht8t8xdj9091w4qHwYs7XbkAN1k+n1XQu tzGYwQDv/4uUbF8zYDeQ9aLuaICE98dmPXBn3laiPGRamMHSPjaee9Kb1kKweS6EFP5o EYS5bMIp2mQ+1SeT3fWK0odAzS0PxTzk8cFJ7PcwcIk1af3F2STD4AiELUbRPwXjS8u4 MyCwxBAXKZ2zX2v4yGJFv4jzHaydzG6x0JybQSVIGpGvgUF6pCtE3P7KbNbyzcvaI8m9 d7Sw== X-Gm-Message-State: ACrzQf1o35rmNZMwNKOiWzkkBBYbqGC6VN0xg+V+xnjagOIJ4OnG/aR8 93TYr5KuMB5tLz6CppbJimmrMNf1EzDBfWxTaQoEEFPkGlY= X-Google-Smtp-Source: AMsMyM5UHG7U7t6iV5RHiVu23h3hqQYTeR5dkuv12QFTsXkGwzE2xbuKMa/x/qTwwobUc5ZbyDyks1mzhUFt9srv6GI= X-Received: by 2002:a81:ab4f:0:b0:36f:d141:f9af with SMTP id d15-20020a81ab4f000000b0036fd141f9afmr24412523ywk.311.1667418288904; Wed, 02 Nov 2022 12:44:48 -0700 (PDT) MIME-Version: 1.0 References: <0a8cc31c7077918bf84fddf9db50db02@rjmcmahon.com> <344f2a33b6bcae4ad4390dcb96f92589@rjmcmahon.com> <261B90F5-FD4E-46D5-BEFE-6BF12D249A28@gmx.de> <9519aceac2103db90e363b5c9f447d12@rjmcmahon.com> In-Reply-To: <9519aceac2103db90e363b5c9f447d12@rjmcmahon.com> From: Dave Taht Date: Wed, 2 Nov 2022 12:44:36 -0700 Message-ID: To: rjmcmahon Cc: Ruediger.Geib@telekom.de, rpm@lists.bufferbloat.net, ippm@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Rpm] [ippm] 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 19:44:49 -0000 On Wed, Nov 2, 2022 at 12:29 PM rjmcmahon via Rpm wrote: > > Most measuring bloat are ignoring queue build up phase and rather start > taking measurements after the bottleneck queue is in a standing state. +10. It's the slow start transient that is holding things back. If we could, for example open up the 110+ objects and flows web pages require all at once, and let 'em rip, instead of 15 at a time, without destroying the network, web PLT would get much better. > My opinion, the best units for bloat is packets for UDP or bytes for > TCP. Min delay is a proxy measurement. bytes, period. bytes =3D time. Sure most udp today is small packets but quic and videconferencing change that. > > Little's law allows one to compute this though does assume the network > is in a stable state over the measurement interval. In the real world, > this probably is rarely true. So we, in test & measurement engineering, > force the standing state with some sort of measurement co-traffic and > call it "working conditions" or equivalent. ;) There was an extremely long, nuanced debate about little's law and where it applies, last year, here: https://lists.bufferbloat.net/pipermail/cake/2021-July/005540.html I don't want to go into it, again. > > Bob > > Bob, Sebastian, > > > > not being active on your topic, just to add what I observed on > > congestion: > > - starts with an increase of jitter, but measured minimum delays still > > remain constant. Technically, a queue builds up some of the time, but > > it isn't present permanently. > > - buffer fill reaches a "steady state", called bufferbloat on access I > > think; technically, OWD increases also for the minimum delays, jitter > > now decreases (what you've described that as "the delay magnitude" > > decreases or "minimum CDF shift" respectively, if I'm correct). I'd > > expect packet loss to occur, once the buffer fill is on steady state, > > but loss might be randomly distributed and could be of a low > > percentage. > > - a sudden rather long load burst may cause a jump-start to > > "steady-state" buffer fill. The above holds for a slow but steady load > > increase (where the measurement frequency determines the timescale > > qualifying "slow"). > > - in the end, max-min delay or delay distribution/jitter likely isn't > > an easy to handle single metric to identify congestion. > > > > Regards, > > > > Ruediger > > > > > >> On Nov 2, 2022, at 00:39, rjmcmahon via Rpm > >> wrote: > >> > >> 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;). > > 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 swit= ched > > 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.... > > > > > >> > >> 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 > > > > _______________________________________________ > > ippm mailing list > > ippm@ietf.org > > https://www.ietf.org/mailman/listinfo/ippm > _______________________________________________ > Rpm mailing list > Rpm@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/rpm --=20 This song goes out to all the folk that thought Stadia would work: https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-69813666656= 07352320-FXtz Dave T=C3=A4ht CEO, TekLibre, LLC