From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 7CA9C3B29E for ; Tue, 12 Oct 2021 03:11:29 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1634022684; bh=qq92L97UnmHPND3opNOrSO4HENnRyGAWytfQ4B8lyEw=; h=X-UI-Sender-Class:From:Subject:Date:References:To:In-Reply-To; b=kKhOkGCtLZX6Du55aVHyMM8NhUNwsgBS4/TmkZ/GwpubUugijGq7riQO5ogcdMw/P LxWO1oLz+84SKiRsDMuUXhRK6wfq2o9c0HnIsqdwLfwLqMkJIgNa/XDgAQndcXn2oq t6ea4YQzciOK5i3Cbeu9LXXcMUvlONiZBMxi8P3U= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.250.101] ([134.76.241.253]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M7b6l-1mfP0A3ncz-007zfN; Tue, 12 Oct 2021 09:11:23 +0200 From: Sebastian Moeller Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Date: Tue, 12 Oct 2021 09:11:23 +0200 References: To: Christoph Paasch , Christoph Paasch via Rpm , Simon Leinen In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3608.120.23.2.7) X-Provags-ID: V03:K1:HGuVKJDMgJLrLJswHBpBPW5jizE87P1J69L8oxo2GNLkvcSjjVA KtQn0lLNtUe5oTeNh8fwi4pZqC+AqU2odMnyzhdAiWDVK+as3HIf0EuTirrtUYLQUcCuWUy K8ntQoTEe4CUKbJen+OcLUHClypXuetfELEAknDl0ATJWe+GuDEHoU3xPB8rsacixFPnBPB +squQil7Eif5oVogdWTGA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:6aavLAIJ1hY=:jL+VndiQPKqizV4NwGDqkw ttlSz1XNT/N+L8LsnKHjkzvBejOYVhc5sn5Zd0DEyXOJRKUnKLhs8Gm4zrGed6433MzT8nntP gb0GLNQG3g7cc0AKtfbBnYPv1sfffhrjlODvI8aerHhIuN2xvpoOR9iav6L9cyjHYQ1JRcuuQ UHHokmfSCELZzjbiYDC4ZWkq6+OO1D10xFrlviRaUwPQ1a7EYgbvyynUXW6aWEk4roEkGkLyV zptmDDYAvrcH5E+gwA7tMVbtn9ehcLY78KgsfNpws+yoLhgqozjIDDaliCfgqS7fr0HhyrEvD 7v8V+dFTx0yUvZHaqg+QsLcjlTnaqGN1FRbuSjKUrbAHuaV6rkkc83V1g6BC3Dm0lPiUga11M cTD0dpDZe0cIfj1iSJGgpklQ/adUZq5wcUjVcAdINrVw4beUYqJZ/7I00sB3u82jdQ4Rc/FkI 1vycw8GZXrMvThs5vFGQSi76To3SIaZO2JvtUzBPKRXfQiZVvuB9CIWsKhA8Bn8XH6kRPCQDX +h7UgoyqNSoZJe6KKoPYlFLQUv7l9AfiYHxAAULZ7u13vWkIZR2QIffeQukg1ZJEDk2kfw2yj 4pl/K1kjIU8iGOmVzumdkhKuZhwPEL1kztAArkhyHRBhWT+VS+r2UUkjTXa5TVO6FJ++vKnYY Gvfz5MZlowXFzXLCGStKDuQXF+iQIIcBqg3UDtpWouOgPeeuxD6gFzTcfoZ+jyCywQyQHUK90 PkzUK8Al9IArirNU7eU79GktyaFDTmjgg0IMKhqzN4Wr1Na4xOp1bJRnFYiGP6+9IaiWJhMy7 PXmurLWUwYqB7crmFiW5dOEkFaCShNSTsW+nYrXvlzi3Sfx/dNAwUu76QP+VdpsskuO2RhfQF j8nOe32JIWeu+sjGhPIqXNr4oaee3ghzWQ3s4E4QSCuXECuHN4Uko+8kPUY6TCxXzPME2p4m6 kRDH2p7oDFJSOTEsNBxXKD2d8SdJyyi+r78FJXGHFAkWhI+L7zUZ0gEoFeIJBTqX3iL7hQDsS nXUeUPDP9khm5nElU4i26Z4ealBz8IuG8Zaob8rKOkPZ2q+Ts9dhdHeHj2HIQ3TwZ7CgZdXsS lfFbWy1cl7td1g= Subject: Re: [Rpm] Outch! I found a problem with responsiveness 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: Tue, 12 Oct 2021 07:11:29 -0000 HI Christoph On 11 October 2021 23:01:20 CEST, Christoph Paasch via Rpm = wrote: Hello Simon, On 10/05/21 - 23:43, Simon Leinen via Rpm wrote: Hallo Christoph, That's right. BB is a transient problem that is extremely short-lived. Having tried for the past year to reliably demo the user-visible impact of bufferbloat, I have learned two things: 1. When it happens, it is bad - really bad. 2. However, it is very difficult to trigger it "on-demand". I seem to be able to trigger it quite reliably by using mobile data while traveling on the train and doing normal remote work. Here in Switzerland I often see RTTs in excess of 10 seconds. In France I have seen more than two MINUTES. wow! Were you able to trace it down? (like, on which device it happend) Maybe I should start setting up systematic measurements. For example, if I just sent pings both from my laptop to a well-connected fixed host, and vice-versa, while capturing all ICMP packets on both ends, I should be able to learn about bufferbloat in both directions. Having tried to debug some bufferbloat problems in a complex enterprise-network, it is extremely hard to pinpoint where the = bufferbloat happens. Especially on such kind of a train network, where there is possible = either a VPN or GRE-tunnel involved to get the data out on the Internet... [SM] Mmmh, to really localize points of congestion, I assume one = needs continuous traceroutes (like mtr or pingplotter) from both = directions and ideally one-way delay measurements. Tunnels where the = congested node might be invisible add to the challenge. But getting = information for the reverse path is really important especially for = internet targets as path's are very likely to be asymmetrical with = handover between different AS at wildly different locations in both = directions. If you have macOS Monterey, you could run the networkQuality tool to see = how much bufferbloat there is. [SM] Is that officially out or still in late beta/RC? Cheers, Christoph It would be even better to have this in a mobile (web) app that could record/send location data from the mobile node, to spot the regions (presumably around tunnels and other connectivity-challenged areas) where the problem tends to occur most often. Alternatively, correlate the probe timestamps with real-time location data provided by the railway company. Cheers, -- Simon. Rpm mailing list Rpm@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/rpm Rpm mailing list Rpm@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/rpm