From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 776303B2A4 for ; Tue, 5 Oct 2021 18:01:34 -0400 (EDT) Received: by mail-wr1-x430.google.com with SMTP id k7so2214281wrd.13 for ; Tue, 05 Oct 2021 15:01:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=G7r4kIDCohSmT9otFIqCM4mcVfRa2Th+o28nwxwTE9s=; b=nB7G9Zly4CTNNRxEbDrFKz5MrMf8O7FABBzP8ROZA1JIeeBGrvL8PzhqM5SVdHAf5X 9ja0qsbR+F5gwxvynSE0CHFuqJtbfEqe71rc8ahfcwgneB7VLFvpDUoBUegoTfN1yerw b8bX39mYLMduvCkvyyJizheQzrgJDVrb/L+EipYekPmjTvldweg46vzY79lJmYy8MqJO vRSPU84rW5wMgX+XDqRKscm/nk6fEJ6c4mNACZtFRjIKFue/5BNjEcL3ynHveThwsStP Bx5U+LpVwVwnzpPc/KsqAoMnUr1fBin1CIW6LT0iCGIouPgD7uAs6m1hpg6wp+/w5yYc 2EOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=G7r4kIDCohSmT9otFIqCM4mcVfRa2Th+o28nwxwTE9s=; b=mNc2IRZ1i6xE6meJ4PSNLmh80Pog+CcgDxU5hciCBetAMOpUjQT0jVJABi8goBfAvL 8m3xxRS7nxhlJ5t0MHV63/LiQ+PvwtZkRKl9SsZgZReLKhQHYpekOWnczkIky37PvpHd h7L/2pCUmcnNM21pvsV0l0+9P7XqkJfqf3O7T52b7W7R3w2mJCfpkqaEWSDCm7KzPs9o eprMiVG8LLYGpSwbquQUOUmaT1ibj9GYPmaVTt6st3H1rI+F+q+N8jWelaZoeAmDuWxY W7+dx0CLkzhFEt9heWtkmYDprjhusfyzL/LEtuscx7iTHibytBmQSM0yThGe4rVQCVSN FcfA== X-Gm-Message-State: AOAM5329055wSEdNOO5baLworKbc9xrkedEBvUdqIegEZ9mrwSCZwm/Q DK4yqFxBTjyr3M005bmqUcCMhfUaajRnQq3Lmsbrtg== X-Google-Smtp-Source: ABdhPJyL+Zlbcf08IGWy0ebFwBOCcytz5VWXu2zN9v5RCwAoZ1ZN/GEhnCGelYLlUWSdtIEsxcJmMRMvSB+dOzOugZQ= X-Received: by 2002:a1c:e915:: with SMTP id q21mr6278058wmc.180.1633471292765; Tue, 05 Oct 2021 15:01:32 -0700 (PDT) MIME-Version: 1.0 References: <49EE1D58-AF0F-4748-83D3-784B0D5F35EF@apple.com> In-Reply-To: <49EE1D58-AF0F-4748-83D3-784B0D5F35EF@apple.com> From: Matt Mathis Date: Tue, 5 Oct 2021 15:01:20 -0700 Message-ID: To: Stuart Cheshire Cc: Rpm Content-Type: multipart/alternative; boundary="000000000000287e9705cda22ce9" 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 22:01:34 -0000 --000000000000287e9705cda22ce9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable What you say is correct for effectively infinite bulk transfers. I was talking about transactional data such as web pages. These days most video (including many VC systems) are paced transactions. 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 Tue, Oct 5, 2021 at 10:26 AM Stuart Cheshire wrote: > 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 t= o > have much predictive value under conditions that are different from the > measurement itself. The problem comes from the unbound specification f= or > "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. > > > > 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 t= he > precise nature of queue growth here. For simplicity here I=E2=80=99m assu= ming 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 tota= l > 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=9C= send=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 ca= n > 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 ther= e > 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 bette= r > 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 onl= y > a tiny percentage of overall the time you spend driving? > > Stuart Cheshire > > --000000000000287e9705cda22ce9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What you say is correct for effectively infinite=C2=A0bulk= transfers.=C2=A0 =C2=A0 I was talking about transactional data such as web= pages.=C2=A0 =C2=A0 These days most video (including many VC systems) are = paced transactions.=C2=A0
=C2=A0
Thanks,
--MM--
The best way to predict the = future is to create it. =C2=A0- Alan Kay

We must not tolerate intole= rance;
=C2=A0 =C2=A0 =C2=A0 =C2=A0however our respons= e must be carefully measured:=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 too strong would be hypocritical and risks spiraling out of c= ontrol;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 too weak risks = being mistaken for tacit approval.

<= /div>

On Tue, Oct 5, 2021 at 10:26 AM Stuart Cheshire <cheshire@apple.com> wrote:
On 4 Oct 2021, at 16:23, Matt M= athis via Rpm <rpm@lists.bufferbloat.net> wrote:

> It has a super Heisenberg problem, to the point where it=C2=A0 is unli= kely to have much predictive value under conditions that are different from= the measurement itself.=C2=A0 =C2=A0 The problem comes from the unbound sp= ecification for "under load" and the impact of the varying drop/m= ark rate changing the number of rounds needed to complete a transaction, su= ch as a page load.
>
> For modern TCP on an otherwise unloaded link with any minimally correc= t queue management (including drop tail), the page load time is insensitive= to the details of the queue management.=C2=A0 =C2=A0 There will be a littl= e 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 maint= ain 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 na= ture 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=9Cse= nd=E2=80=9D on an email, this is a useful metric. For watching a two-hour m= ovie, served as a single large HTTP GET for the entire media file, and play= ing it as it arrives, time-to-completion is not very interesting. What matt= ers is consistent smooth delivery of the bytes within that flow, so the vid= eo 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 bott= leneck queue is what limits how quickly I get to see the new video start pl= aying.

> 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.=C2=A0 If = there is no cross traffic, these two effects (more rounds at higher RPM) wi= ll 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 p= roblems first, and the less obvious ones later.

If there was a bug that occasionally resulted in a corrupted file system an= d 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 dep= ressed for only a tiny percentage of overall the time you spend driving?
Stuart Cheshire

--000000000000287e9705cda22ce9--