From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (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 AD3103B2A4 for ; Tue, 5 Oct 2021 13:26:19 -0400 (EDT) Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.42/8.16.0.42) with SMTP id 195HHtrJ063996; Tue, 5 Oct 2021 10:26:18 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=KqLZDkEPgm2r2PbNjtps7mNP+EXnbvJVVORB1BMbtK0=; b=Ns5zr+hCLWL0QUSMEfoK3/ESROYPwb975F9EIogK28INenmzNzPSqrzb6lGogh79o5R+ 5aBMquAr/Vs16+ByLlqpiuJ/ei5rBwOkGrSJvV9dMUtikj3p6SbtkQ2HcHAZpFFcQeIf OMvQmphgVQkC/HxaCaAwQI6KWyFwOclhant9WQCSIB5HKHLZRAciagkLmJLsDqnS0iqW uZbPEAdfVzVhU86wkL4SEBYkE0sINbcM65XjPKqaGDeqql8XK5vd+bkYnz78UeRaLfBX GQLsb4iefPhmwoZG55KQ4BXYS1opzj3WSe9sj81zhpANJAfYAX0O28X/gqeR/0CGu4Jq fw== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 3bep32y7sc-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 05 Oct 2021 10:26:18 -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 <0R0I0038BLRPG9H0@rn-mailsvcp-mta-lapp03.rno.apple.com>; Tue, 05 Oct 2021 10:26:13 -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 <0R0I00G00L9E1P00@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Tue, 05 Oct 2021 10:26:13 -0700 (PDT) X-Va-A: X-Va-T-CD: 0784ebc13a2136f668ccea2ff57975fe X-Va-E-CD: ef5276e520d02273e4ccfb1dc027673b X-Va-R-CD: 147313b022faf3d53befe0ce09e8c0e1 X-Va-CD: 0 X-Va-ID: 8ea29fb8-401f-4002-9449-f04a516751c0 X-V-A: X-V-T-CD: 0784ebc13a2136f668ccea2ff57975fe X-V-E-CD: ef5276e520d02273e4ccfb1dc027673b X-V-R-CD: 147313b022faf3d53befe0ce09e8c0e1 X-V-CD: 0 X-V-ID: aa3f9d8b-2b06-4369-91c1-b7437d6391c1 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-10-05_03:2021-10-04, 2021-10-05 signatures=0 Received: from [17.11.105.157] (unknown [17.11.105.157]) 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 <0R0I00KFBLROT400@rn-mailsvcp-mmp-lapp01.rno.apple.com>; Tue, 05 Oct 2021 10:26:13 -0700 (PDT) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Stuart Cheshire In-reply-to: Date: Tue, 05 Oct 2021 10:26:12 -0700 Cc: Rpm Content-transfer-encoding: quoted-printable Message-id: <49EE1D58-AF0F-4748-83D3-784B0D5F35EF@apple.com> References: To: Matt Mathis X-Mailer: Apple Mail (2.3608.120.23.2.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-10-05_03:2021-10-04, 2021-10-05 signatures=0 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, 05 Oct 2021 17:26:19 -0000 On 4 Oct 2021, at 16:23, Matt Mathis via Rpm = wrote: > It has a super Heisenberg problem, to the point where it is unlikely = to have much predictive value under conditions that are different from = the measurement itself. The problem comes from the unbound = specification for "under load" and the impact of the varying drop/mark = rate changing the number of rounds needed to complete a transaction, = such as a page load. >=20 > For modern TCP on an otherwise unloaded link with any minimally = correct queue management (including drop tail), the page load time is = insensitive to the details of the queue management. There will be a = little bit of link idle in the first few RTT (early slowstart), and then = under a huge range of conditions for both the web page and the AQM, TCP = will maintain at least a short queue at the bottleneck Surely you mean: TCP will maintain an EVER GROWING queue at the = bottleneck? (Of course, the congestion control algorithm in use affects = the precise nature of queue growth here. For simplicity here I=E2=80=99m = assuming Reno or CUBIC.) > TCP will also avoid sending any duplicate data, so the total data sent = will be determined by the total number of bytes in the page, and the = total elapsed time, by the page size and link rate (plus the idle from = startup). You are focusing on time-to-completion for a flow. For clicking = =E2=80=9Csend=E2=80=9D on an email, this is a useful metric. For = watching a two-hour movie, served as a single large HTTP GET for the = entire media file, and playing it as it arrives, time-to-completion is = not very interesting. What matters is consistent smooth delivery of the = bytes within that flow, so the video can be played as it arrives. And if = I get bored of that video and click another, the the amount of (now = unwanted) stale packets sitting in the bottleneck queue is what limits = how quickly I get to see the new video start playing. > If AQM is used to increase the responsiveness, the losses or ECN marks = will cause the browser to take additional RTTs to load the page. If = there is no cross traffic, these two effects (more rounds at higher RPM) = will exactly counterbalance each other. Right: Improving responsiveness has *no* downside on time-to-completion = for a flow. Throughput -- in bytes per second -- is unchanged. What = improving responsiveness does is improve what happens throughout the = lifetime of the transfer, without affecting the end time either for = better or for worse. > This is perhaps why there are BB deniers: for many simple tasks it has = zero impact. Of course. In the development of any technology we solve the most = obvious problems first, and the less obvious ones later. If there was a bug that occasionally resulted in a corrupted file system = and loss of data, would people argue that we shouldn=E2=80=99t fix it on = the grounds that sometimes it *doesn=E2=80=99t* corrupt the file system? If you car brakes didn=E2=80=99t work, would people argue that it = doesn=E2=80=99t matter, because -- statistically speaking -- the brake = pedal is depressed for only a tiny percentage of overall the time you = spend driving? Stuart Cheshire