[Rpm] Outch! I found a problem with responsiveness

[Matt Mathis <mattmathis@google.com>]

[-- Attachment #1: Type: text/plain, Size: 1897 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 2337 bytes --]