From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) (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 C0AC33B29E for ; Thu, 17 Jun 2021 19:43:40 -0400 (EDT) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.42/8.16.0.42) with SMTP id 15HNhdaV028026; Thu, 17 Jun 2021 16:43:39 -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=REm05z1qahPhFUen6E/F8sDGzUqgd7Jn8zTGKJPraPw=; b=MMulrPDNMD2yh23MDZxcMROkzzGsE2008Oxjxf2Em7FLCDUjDVjXfl03/C3V5JEgesoY b1nrNpo8kwHBlzee6fy2ANjBQ6BJ5aL3qby7iBG3iyZKRkkHO+1QTC0acDzMKI8CNfZm Iv24QMQX+OtriqbW3FTtK1unmcpo26E6xZnFTKdP+ROJ4+S3YWEv46JNdenbOCpy9UEz 2rtW5wLdW92wWUQ7OZCKd6kvfEbIy0caJ8ReH9Q2JrmpA23WuDvF5ehbXq46lnMIFf8M WaSN5Q1UPng8nBOg07g+p/NAZgDnSMdvM5MFEz9d8fmx6nRwDx+B+avJkMePs9/hcGz9 tw== Received: from rn-mailsvcp-mta-lapp02.rno.apple.com (rn-mailsvcp-mta-lapp02.rno.apple.com [10.225.203.150]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 394skuw18p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 17 Jun 2021 16:43:39 -0700 Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp02.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPS id <0QUV00DTLDWNVSH0@rn-mailsvcp-mta-lapp02.rno.apple.com>; Thu, 17 Jun 2021 16:43:35 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) id <0QUV00D00DST6300@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Thu, 17 Jun 2021 16:43:35 -0700 (PDT) X-Va-A: X-Va-T-CD: 0784ebc13a2136f668ccea2ff57975fe X-Va-E-CD: bcb3ed6ab20966b139d3f01c1a94bc42 X-Va-R-CD: c61df103aa9e6bfe62892afaffca7067 X-Va-CD: 0 X-Va-ID: 3558d75d-9cfa-4df3-8151-a5658432a78c X-V-A: X-V-T-CD: 0784ebc13a2136f668ccea2ff57975fe X-V-E-CD: bcb3ed6ab20966b139d3f01c1a94bc42 X-V-R-CD: c61df103aa9e6bfe62892afaffca7067 X-V-CD: 0 X-V-ID: 8196a30a-bfd7-4ba1-915a-a6137b2c3fbb X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-06-17_16:2021-06-15, 2021-06-17 signatures=0 Received: from localhost ([17.234.15.180]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPSA id <0QUV00E23DWMVQ00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Thu, 17 Jun 2021 16:43:34 -0700 (PDT) Date: Thu, 17 Jun 2021 16:43:34 -0700 From: Christoph Paasch To: Matt Mathis Cc: 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-06-17_16:2021-06-15, 2021-06-17 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: Thu, 17 Jun 2021 23:43:40 -0000 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). 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