From: Matt Mathis <mattmathis@google.com>
To: Christoph Paasch <cpaasch@apple.com>
Cc: bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] Apple WWDC Talks on Latency/Bufferbloat
Date: Thu, 17 Jun 2021 17:17:34 -0700 [thread overview]
Message-ID: <CAH56bmCZhKLB762chqZSR9n0dNXYTh+x0zZTXw76i657RGr6Mg@mail.gmail.com> (raw)
In-Reply-To: <YMveJhEsnRi0OF2O@MacBook-Pro.local>
[-- Attachment #1: Type: text/plain, Size: 4778 bytes --]
Which WG are you targeting?
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 Thu, Jun 17, 2021 at 4:43 PM Christoph Paasch <cpaasch@apple.com> wrote:
> Hello,
>
> On 06/17/21 - 11:16, Matt Mathis via Bloat wrote:
> > Is there a paper or spec for RPM?
>
> we try to publish an IETF-draft on the methodology before the upcoming IETF
> in July.
>
> But, in the mean-time please see inline:
>
> > There are at least two different ways to define RPM, both of which might
> be
> > relevant.
> >
> > At the TCP layer: it can be directly computed from a packet capture. The
> > trick is to time reverse a trace and compute the critical path backwards
> > through the trace: what event triggered each segment or ACK, and count
> > round trips. This would be super robust but does not include the
> queueing
> > required in the kernel socket buffers. I need to think some more about
> > computing TCP RPM from tcp_info or other kernel instrumentation - it
> might
> > be possible.
>
> We explicitly opted against measuring purely TCP-level round-trip times.
> Because
> there are countless transparent TCP-proxies out there that would skew these
> numbers. Our goal with RPM/Responsiveness is to measure how an end-user
> would
> experience the network. Which means, DNS-resolution, TCP handshake-time,
> TLS-handshake, HTTP/2 Request/response. Because, at the end, that's what
> actually matters to the users.
>
> > A different RPM can be done in the application, above TCP, for example by
> > ping-ponging messages. This would include the delays traversing the
> kernel
> > socket buffers which have to be at least as large as a full network RTT.
> >
> > This is perhaps an important point: due to the retransmit and
> > reassuebly queues (which are required to implement robust data delivery)
> > TCP must be able hold at least a full RTT of data in it's own buffers,
> > which means that under some conditions the RTT as seen by the application
> > has be be at least twice the network's RTT, including any bloat in the
> > network.
>
> Currently, we measure RPM on separate connections (not the load-bearing
> ones). We are also measuring on the load-bearing connections themselves
> through H2 Ping frames. But for the reasons you described we haven't yet
> factored it into the RPM-number.
>
> One way may be to inspect with TCP_INFO whether or not the connections had
> retransmissions and then throw away the number. On the other hand, if the
> network becomes extremely lossy under working conditions, it does impact
> the
> user-experience and so it could make sense to take this into account.
>
>
> In the end, we realized how hard it is to accurately measure bufferbloat
> within a reasonable time-frame (our goal is to finish the test within ~15
> seconds).
>
> We hope that with the IETF-draft we can get the right people together to
> iterate over it and squash out a very accurate measurement that represents
> what users would experience.
>
>
> Cheers,
> Christoph
>
>
> >
> > 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 Sat, Jun 12, 2021 at 9:11 AM Rich Brown <richb.hanover@gmail.com>
> wrote:
> >
> > > > On Jun 12, 2021, at 12:00 PM, bloat-request@lists.bufferbloat.net
> wrote:
> > > >
> > > > Some relevant talks / publicity at WWDC -- the first mentioning
> CoDel,
> > > > queueing, etc. Featuring Stuart Cheshire. iOS 15 adds a developer
> test
> > > for
> > > > loaded latency, reported in "RPM" or round-trips per minute.
> > > >
> > > > I ran it on my machine:
> > > > nowens@mac1015 ~ % /usr/bin/networkQuality
> > > > ==== SUMMARY ====
> > > > Upload capacity: 90.867 Mbps
> > > > Download capacity: 93.616 Mbps
> > > > Upload flows: 16
> > > > Download flows: 20
> > > > Responsiveness: Medium (840 RPM)
> > >
> > > Does anyone know how to get the command-line version for current (not
> > > upcoming) macOS? Thanks.
> > >
> > > Rich
> > > _______________________________________________
> > > Bloat mailing list
> > > Bloat@lists.bufferbloat.net
> > > https://lists.bufferbloat.net/listinfo/bloat
> > >
>
> > _______________________________________________
> > Bloat mailing list
> > Bloat@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/bloat
>
>
[-- Attachment #2: Type: text/html, Size: 6471 bytes --]
next prev parent reply other threads:[~2021-06-18 0:17 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-12 16:11 Rich Brown
2021-06-17 18:16 ` Matt Mathis
2021-06-17 23:43 ` Christoph Paasch
2021-06-18 0:17 ` Matt Mathis [this message]
2021-06-18 1:03 ` Christoph Paasch
2021-06-18 3:33 ` Matt Mathis
2021-06-28 22:54 ` Christoph Paasch
2021-06-29 7:58 ` Sebastian Moeller
2021-07-06 18:54 ` Christoph Paasch
2021-07-06 19:08 ` Sebastian Moeller
-- strict thread matches above, loose matches on Subject: below --
2021-06-11 19:14 Nathan Owens
2021-06-11 21:58 ` Jonathan Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAH56bmCZhKLB762chqZSR9n0dNXYTh+x0zZTXw76i657RGr6Mg@mail.gmail.com \
--to=mattmathis@google.com \
--cc=bloat@lists.bufferbloat.net \
--cc=cpaasch@apple.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox