From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rn-mailsvcp-ppex-lapp35.apple.com (rn-mailsvcp-ppex-lapp35.rno.apple.com [17.179.253.44]) (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 A3DF83CB52 for ; Tue, 6 Jul 2021 14:54:07 -0400 (EDT) Received: from pps.filterd (rn-mailsvcp-ppex-lapp35.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp35.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 166IqIvb024226; Tue, 6 Jul 2021 11:54:03 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=20180706; bh=naEIAemnTOGI7Bs3nKRre90VgmrxakRUA6fDAmOFcRg=; b=MkJC8RtXdeHujWaDlqtCUZsbcOQdrITUJ/Lec7KPwa2zfbai8pMP+30tzn0jgdfieeLa Q7iOhrd4m6D9M0ZUerfGLdS+N4RgC3PuWbKCvb9dX2pBaSgpMFg3Dt4z806nnqU4vlVk xV1yoD/cMJS8Kh1fYE1HGkl8HWdwbzGdh5KaRcT7CVzgCaz8+n9RIrfUctCxO4oYCzh4 imM/9RzG9NNCX3Dbg2mk4V8iKhusvz6Xx3dz2EnHIXAwKgGovo12GWqtiIgiXnBjjp4c 5f/xfWtJxJ6TuG2DRKoJJ7UIkL5onzk8/ZEecybqjn8v7zwjSHOh40dPs8SofsyuMpc0 Hw== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by rn-mailsvcp-ppex-lapp35.rno.apple.com with ESMTP id 39jke6b9pd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 06 Jul 2021 11:54:03 -0700 Received: from rn-mailsvcp-mmp-lapp01.rno.apple.com (rn-mailsvcp-mmp-lapp01.rno.apple.com [17.179.253.14]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPS id <0QVU00Q487636240@rn-mailsvcp-mta-lapp03.rno.apple.com>; Tue, 06 Jul 2021 11:54:03 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp01.rno.apple.com by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) id <0QVU00R00715XI00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Tue, 06 Jul 2021 11:54:03 -0700 (PDT) X-Va-A: X-Va-T-CD: 0af778c0afa90afa8c4c05937d25c782 X-Va-E-CD: bcb3ed6ab20966b139d3f01c1a94bc42 X-Va-R-CD: c61df103aa9e6bfe62892afaffca7067 X-Va-CD: 0 X-Va-ID: ab5cd51e-3d6f-4d8f-a7d4-f62a665af047 X-V-A: X-V-T-CD: 0af778c0afa90afa8c4c05937d25c782 X-V-E-CD: bcb3ed6ab20966b139d3f01c1a94bc42 X-V-R-CD: c61df103aa9e6bfe62892afaffca7067 X-V-CD: 0 X-V-ID: c24be0b5-e012-4ecf-a2e6-3e494d48828d X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-06_10:2021-07-06, 2021-07-06 signatures=0 Received: from localhost ([17.149.231.91]) by rn-mailsvcp-mmp-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPSA id <0QVU00KVQ762OK00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Tue, 06 Jul 2021 11:54:02 -0700 (PDT) Date: Tue, 06 Jul 2021 11:54:02 -0700 From: Christoph Paasch To: Sebastian Moeller Cc: Matt Mathis , bloat Message-id: References: <62E013CF-ECE9-4022-B092-DFCE2176F772@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline In-reply-to: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-07-06_10:2021-07-06, 2021-07-06 signatures=0 Subject: Re: [Bloat] Apple WWDC Talks on Latency/Bufferbloat 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: Tue, 06 Jul 2021 18:54:07 -0000 Hello Sebastian, On 06/29/21 - 09:58, Sebastian Moeller wrote: > Hi Christoph, > > one question below: > > > On Jun 18, 2021, at 01:43, Christoph Paasch via Bloat > > wrote: > > > > Hello, > > > > On 06/17/21 - 11:16, Matt Mathis via Bloat wrote: > >> Is there a paper or spec for RPM? > > > > we try to publish an IETF-draft on the methodology before the upcoming > > IETF in July. > > > > But, in the mean-time please see inline: > > > >> There are at least two different ways to define RPM, both of which > >> might be relevant. > >> > >> At the TCP layer: it can be directly computed from a packet capture. > >> The trick is to time reverse a trace and compute the critical path > >> backwards through the trace: what event triggered each segment or ACK, > >> and count round trips. This would be super robust but does not include > >> the queueing required in the kernel socket buffers. I need to think > >> some more about computing TCP RPM from tcp_info or other kernel > >> instrumentation - it might be possible. > > > > We explicitly opted against measuring purely TCP-level round-trip times. > > Because there are countless transparent TCP-proxies out there that would > > skew these numbers. Our goal with RPM/Responsiveness is to measure how > > an end-user would experience the network. Which means, DNS-resolution, > > TCP handshake-time, TLS-handshake, HTTP/2 Request/response. Because, at > > the end, that's what actually matters to the users. > > > >> A different RPM can be done in the application, above TCP, for example > >> by ping-ponging messages. This would include the delays traversing the > >> kernel socket buffers which have to be at least as large as a full > >> network RTT. > >> > >> This is perhaps an important point: due to the retransmit and > >> reassuebly queues (which are required to implement robust data > >> delivery) TCP must be able hold at least a full RTT of data in it's own > >> buffers, which means that under some conditions the RTT as seen by the > >> application has be be at least twice the network's RTT, including any > >> bloat in the network. > > > > Currently, we measure RPM on separate connections (not the load-bearing > > ones). We are also measuring on the load-bearing connections themselves > > through H2 Ping frames. But for the reasons you described we haven't yet > > factored it into the RPM-number. > > > > One way may be to inspect with TCP_INFO whether or not the connections > > had retransmissions and then throw away the number. On the other hand, > > if the network becomes extremely lossy under working conditions, it does > > impact the user-experience and so it could make sense to take this into > > account. > > > > > > In the end, we realized how hard it is to accurately measure bufferbloat > > within a reasonable time-frame (our goal is to finish the test within > > ~15 seconds). > > [SM] I understand that 10-15 seconds is the amount of time users > have been trained to expect an on-line speedtest to take, but > experiments with flent/RRUL showed that there are latency affection > processes on slower timescales that are better visible if one can > also run a test for 60 - 300 seconds (e.g. cyclic WiFi channel > probing). Does your tool optionally allow to specify a longer > run-time? Currently the tool does not have a "deep-dive"-mode. There are a few things (besides running longer) that a "deep-dive"-mode could provide. For example, traceroute-style probes during the test to identify the location of the bufferbloat. Use H3 for testing and/or run TCP on a different port to identify traffic-classifiers/transparent TCP-proxies that treat things differently. Study the impact of TCP bulk transfer on UDP latency. And so on... Such a deep-dive mode would be possible in the command-line tool but very unlikely in the UI-mode. Our primary goal in this first iteration is to provide a tool that gives a quick insight into how bad/good the bufferbloat is on the network in such a way that a non-expert user can run it and understand the result. We also want it to be using standard protocols so that any basic web-server can be configured to serve as an endpoint to it and because that's the protocols that the users are actually using in the end. Cheers, Christoph > Thinking of it, to keep everybody on their toes, how > about occasionally running a test with longer run-time (maybe after > asking the users consent) and store the test duration as part of the > results? > > > Best Regards Sebastian > > > > > > We hope that with the IETF-draft we can get the right people together to > > iterate over it and squash out a very accurate measurement that > > represents what users would experience. > > > > > > Cheers, Christoph > > > > > >> > >> Thanks, --MM-- The best way to predict the future is to create it. - > >> Alan Kay > >> > >> We must not tolerate intolerance; however our response must be > >> carefully measured: too strong would be hypocritical and risks > >> spiraling out of control; too weak risks being mistaken for tacit > >> approval. > >> > >> > >> On Sat, Jun 12, 2021 at 9:11 AM Rich Brown > >> wrote: > >> > >>>> On Jun 12, 2021, at 12:00 PM, bloat-request@lists.bufferbloat.net > >>>> wrote: > >>>> > >>>> Some relevant talks / publicity at WWDC -- the first mentioning > >>>> CoDel, queueing, etc. Featuring Stuart Cheshire. iOS 15 adds a > >>>> developer test > >>> for > >>>> loaded latency, reported in "RPM" or round-trips per minute. > >>>> > >>>> I ran it on my machine: nowens@mac1015 ~ % /usr/bin/networkQuality > >>>> ==== SUMMARY ==== Upload capacity: 90.867 Mbps Download capacity: > >>>> 93.616 Mbps Upload flows: 16 Download flows: 20 Responsiveness: > >>>> Medium (840 RPM) > >>> > >>> Does anyone know how to get the command-line version for current (not > >>> upcoming) macOS? Thanks. > >>> > >>> Rich _______________________________________________ Bloat mailing > >>> list Bloat@lists.bufferbloat.net > >>> https://lists.bufferbloat.net/listinfo/bloat > >>> > > > >> _______________________________________________ Bloat mailing list > >> Bloat@lists.bufferbloat.net > >> https://lists.bufferbloat.net/listinfo/bloat > > > > _______________________________________________ Bloat mailing list > > Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat >