[Rpm] Outch! I found a problem with responsiveness

[Matt Mathis]

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 <cheshire at apple.com> wrote:

> On 4 Oct 2021, at 16:23, Matt Mathis via Rpm <rpm at lists.bufferbloat.net>
> 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.
> >
> > 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’m 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 “send” 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’t fix it on the
> grounds that sometimes it *doesn’t* corrupt the file system?
>
> If you car brakes didn’t work, would people argue that it doesn’t matter,
> because -- statistically speaking -- the brake pedal is depressed for only
> a tiny percentage of overall the time you spend driving?
>
> Stuart Cheshire
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/rpm/attachments/20211005/7a90a826/attachment-0001.html>