From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 E23FC3CB55 for ; Tue, 29 Jun 2021 03:58:07 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1624953483; bh=/LgFWCPPR+oQCVXv35kpAouYxS5O5pbp8Xc05hVb900=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=eOsq8dHtejrbalA6t3xlbGXXVNRWDvvnJi4v9wdDG2jc23f7yH9fSESaoMZTa+xG1 e1H47aO1BS/+Gymwh4Jt0B85b3vNZfDnS37DdzErmUQG6VX1PXol5vbEx2gPgzCzn6 W8Ke1gHmhcT/2LdW5kL40HnVLxdVe9lVPmZchtYY= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.250.105] ([134.76.241.253]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MI5UD-1m3Nq02MC7-00FEUQ; Tue, 29 Jun 2021 09:58:03 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) From: Sebastian Moeller In-Reply-To: Date: Tue, 29 Jun 2021 09:58:02 +0200 Cc: Matt Mathis , bloat Content-Transfer-Encoding: quoted-printable Message-Id: References: <62E013CF-ECE9-4022-B092-DFCE2176F772@gmail.com> To: Christoph Paasch X-Mailer: Apple Mail (2.3445.104.21) X-Provags-ID: V03:K1:dDj6ihCSk00UGLm/VHXV9veL086BCRRK5m71rmZ8/j+2DqGtcew u3MwLwLHVyher1J8mEiZr5fIPWgz/xfovCHf7vwlzpFQFiLFeF7gT5mFSg+ZT5aJMZyNni/ Cowtag1UXRDbGVumZ9uepOFYiBnajiCSm0o2USjW/Huu0h9IqH7SutTOcQKHcixsSYxqmyp O6LAQjgc1kmYUX31FQ4hw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:xbWyPHA+g5w=:P/sXmJKqzvDbth4TVH6kyi ytOavX75vH4Ndh9fhnhKEl1tbsEX1FAsZ5sAfG22Ek0SoUiIsIctKkbUyvcO9jb813ojwdi+3 eAnBE2LsN5yI8kpOS1na2XkZk8Z3vOhcysb1emKhUms+FEUejXmjpb5AtzebGm27DCXYehk8b DYmUhAcTdoEdX9G0Ni7+vkliz/QfsrZ6WeacWFiTn087N42+a8/mmhi+VSmicWdRTAeHwOhs2 Z3JrL95zTbS/hyahTwiAM/QT8mGacQlsLYQDodqnRS4j1aovqVJw0JRYwSKNJ23n9Oj28nk6k WWkJRDNAiaWw8p2nVX3CvOnwktq/zr7aYxNCvaIKxuH9rCgurCVMQVQRUnwapcP8vJip0aqpn 8O2UgIPnf8/E+nhxjcoom8W7tzzmg42n98At2n1AHcoECe6QNQ7DtZbHgkWh/TzgI2cD59sfb VE4XU1qvYUdaU79BPqxtYtDyGghHzP/nCEDd2wcGT+c/NQuunKKgQU5TYW6o70fTHo5NgAaTX vFfAq19gDiR3ky+Qpa1YaFLHcwcPbLOPnGeMuXA3Q8DnEqHXonG6y92wqRx2ybOVDMDEPjtmP 96DLONMyuEyFqwPIIQEuDKPG2sfjRU4zIu63y2lqPzsl/rxpcK/2e6rpMNcJUN8z+6MXuuZuf CgIRHGJXFDiEE53BkyQzBbY5VEyH64wYxzqOzUOTPxW/vG1OaJukWECGpTgHoyvG8d7whU08P ZE0W8VgT+ZLJMQX+LNKIggUzL1KziGxTTAbdd/odrPfe27QyL16U9h+jSVv1K4xvvwEhWYs9e qi2kgmcahnu9s1tIUVJpSMZEwojZYWZ7+JaZZ6u0YORP63qJd6fxb9D965IB0vpf2zXcyINZs 8azYoHzr6PkGs/V8oe/Wa0a8QLyfSFcvP2ZxIlIPfZ4ukjAWbVpxUjaE1Z72YOlfsdj6xsl+i M5Na+eBa8/H6do0XOcSH0+M2stAyGPQR7W9PuvL8bi7++tTVQ+xtc5P9DwXsO+G1UAkpWH3bi uUp9BZzWJ1KHOYmtDILlukvVC84/jyrUB4w6YMDuTi27dAQ060ivoCM147dCTCSaIzZykiFi4 fqHbOarVnazOkXDstI69bspTJPP4sgmuoRe 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, 29 Jun 2021 07:58:08 -0000 Hi Christoph, one question below: > On Jun 18, 2021, at 01:43, Christoph Paasch via Bloat = wrote: >=20 > Hello, >=20 > On 06/17/21 - 11:16, Matt Mathis via Bloat wrote: >> Is there a paper or spec for RPM? >=20 > we try to publish an IETF-draft on the methodology before the upcoming = IETF > in July. >=20 > But, in the mean-time please see inline: >=20 >> There are at least two different ways to define RPM, both of which = might be >> relevant. >>=20 >> 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. >=20 > 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. >=20 >> 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. >>=20 >> 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. >=20 > 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. >=20 > 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. >=20 >=20 > 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? 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 >=20 > 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. >=20 >=20 > Cheers, > Christoph >=20 >=20 >>=20 >> Thanks, >> --MM-- >> The best way to predict the future is to create it. - Alan Kay >>=20 >> 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. >>=20 >>=20 >> On Sat, Jun 12, 2021 at 9:11 AM Rich Brown = wrote: >>=20 >>>> On Jun 12, 2021, at 12:00 PM, bloat-request@lists.bufferbloat.net = wrote: >>>>=20 >>>> 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. >>>>=20 >>>> I ran it on my machine: >>>> nowens@mac1015 ~ % /usr/bin/networkQuality >>>> =3D=3D=3D=3D SUMMARY =3D=3D=3D=3D >>>> Upload capacity: 90.867 Mbps >>>> Download capacity: 93.616 Mbps >>>> Upload flows: 16 >>>> Download flows: 20 >>>> Responsiveness: Medium (840 RPM) >>>=20 >>> Does anyone know how to get the command-line version for current = (not >>> upcoming) macOS? Thanks. >>>=20 >>> Rich >>> _______________________________________________ >>> Bloat mailing list >>> Bloat@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/bloat >>>=20 >=20 >> _______________________________________________ >> Bloat mailing list >> Bloat@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/bloat >=20 > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat