From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 242C23CB35 for ; Mon, 4 Oct 2021 19:23:29 -0400 (EDT) Received: by mail-wm1-x32a.google.com with SMTP id j10-20020a1c230a000000b0030d523b6693so924501wmj.2 for ; Mon, 04 Oct 2021 16:23:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=hm0hbmYgOP3KmWLbZHHtYipzZSU7uNjpB2NHKAZGElg=; b=UfURKu2aDqAXiN/AFbSNMzetByztSaJZapoYNTwVUXSY5XPcAuyUrNauGG11J5Du38 gwnNj017T+rbFhuGlQiMUNryZbsgpJMbaNOb9sW5O95Uo2PsQtOVyiC4C9X3RL5Cgjbx Gk3XjeRsQVlSGoPrLeNJ/10U9fxlrbKZIx61OQim4Nc83mBZcrW953HAZiXUXPypuCCi VTzM/hdKy9JCbs1bChRT86+e6py0FpRQJ48eALW2h+7bQkFPaCT4S+R+FaPi3Nw3bBDx LImnlMOs1MUlLZHxOzFvaI1p0r78q1UJRszPsd1s4zD14CX6kQqBPHXaNYMJUL0k/zh+ M3dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=hm0hbmYgOP3KmWLbZHHtYipzZSU7uNjpB2NHKAZGElg=; b=YMYhQB01eHHGBzljj7PtFvtMD8Y0NYW3rbyNZD8di/SHzMDBbV1IFAL9EkTS2IVYge EGk9+7e+eJGYJ9FzYhDRJOU3crSF8pW0TIqjMG2FLIyJbRq+hOdghd+GngXka/qHBbg+ sBiE7x83Thm4A7FwmcUSvo3iXZEcls9uhyWlE1iFyXor8QSjUy86qAYHaxuabQ1TTzPS Y7SHyzBGpT00rxFeaIusv2mKSCwqKGLhCrB22/5V6a+rdSDix9/h4A+r7iC3pQOYI/iF 49eIfG8PBzMJ1MsfqgIUr6sT94j9rR3g4Z2NZ69zLSk0pbOGFYn4G9PE+3zKw3AVc716 eJYA== X-Gm-Message-State: AOAM530nSRpaUQ+Wg9gJ2ekSG30RJA0tHH/j0ZClHFnys7kyVmsu7wgw UBUgMeRoOIOzh9BdRmV6QqF3zlrbGRjD4sqf9g9R6XbcibDaUA== X-Google-Smtp-Source: ABdhPJw5vYf+ej/L7rWeAq0F+Sqodg6mNe0gAQfaIucp47xflz848wtUS9gEaSNk+30lDWmf8BiLOkEv7ehXSVNANs8= X-Received: by 2002:a7b:c056:: with SMTP id u22mr21460343wmc.15.1633389807037; Mon, 04 Oct 2021 16:23:27 -0700 (PDT) MIME-Version: 1.0 From: Matt Mathis Date: Mon, 4 Oct 2021 16:23:15 -0700 Message-ID: To: Rpm Content-Type: multipart/alternative; boundary="0000000000003b10bd05cd8f33f4" Subject: [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: Mon, 04 Oct 2021 23:23:29 -0000 --0000000000003b10bd05cd8f33f4 Content-Type: text/plain; charset="UTF-8" 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. 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 with zero idle, up until the last segment is delivered, 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). 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. This is perhaps why there are BB deniers: for many simple tasks it has zero impact. A concrete definition for "under load" should help to compare metrics between implementations, but may not help predicting application performance. (Note there is a similar issue for base RTT). 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. --0000000000003b10bd05cd8f33f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It has a super Heisenberg=C2=A0problem, to the point where= it=C2=A0 is unlikely to have much predictive value under conditions that a= re different from the measurement itself.=C2=A0 =C2=A0 The problem comes fr= om the unbound specification for "under load" and the impact of t= he 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=C2=A0unloaded=C2=A0link with any minimally correct queue managem= ent=C2=A0(including drop tail), the page load time is insensitive to the de= tails of the queue management.=C2=A0 =C2=A0 There will be a little bit of l= ink idle in the first few RTT (early slowstart), and then under a huge rang= e of conditions for both the=C2=A0web page and the AQM, TCP will maintain a= t least=C2=A0a short queue at the bottleneck with zero idle, up until=C2=A0= the last segment is delivered,=C2=A0 =C2=A0TCP will also avoid sending any = duplicate data, so the total data sent will be determined by the total numb= er of bytes in the page, and the total elapsed=C2=A0time, by the page size = and link rate (plus the idle from startup).

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) will exactly = counterbalance each other.

This is perhaps why the= re are BB deniers: for many simple tasks it has zero impact.

=
A concrete definition for "under load" should help to = compare metrics between implementations, but may not help predicting applic= ation performance.
(Note there is a similar issue for base RTT).<= /div>

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.
--0000000000003b10bd05cd8f33f4--