<div dir="ltr">Also consider ippm.  intarea might be a good choice for joint sponsorship, but they probably won't want to be the lead.<div><br></div><div>BTW by using two TCP connections you potentially give a free pass to many types of networks (e.g. ECMP, SFQ, etc) and certain OS mis features.</div><div><br></div><div>Thanks,<div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr">--MM--<br>The best way to predict the future is to create it.  - Alan Kay<br><br>We must not tolerate intolerance;</div><div dir="ltr">       however our response must be carefully measured: </div><div>            too strong would be hypocritical and risks spiraling out of control;</div><div>            too weak risks being mistaken for tacit approval.</div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 17, 2021 at 6:04 PM Christoph Paasch <<a href="mailto:cpaasch@apple.com">cpaasch@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="ltr"></div><div dir="ltr">Not sure yet - there isn’t a good one that would really fit. Maybe tsvwg or intarea.</div><div dir="ltr"><br></div><div dir="ltr">Suggestions?</div><div dir="ltr"><br></div><div dir="ltr">Cheers,</div><div dir="ltr">Christoph</div><div dir="ltr"><br><blockquote type="cite">On Jun 17, 2021, at 5:17 PM, Matt Mathis <<a href="mailto:mattmathis@google.com" target="_blank">mattmathis@google.com</a>> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr">Which WG are you targeting?<div><br clear="all"><div><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Thanks,</div>--MM--<br>The best way to predict the future is to create it.  - Alan Kay<br><br>We must not tolerate intolerance;</div><div dir="ltr">       however our response must be carefully measured: </div><div>            too strong would be hypocritical and risks spiraling out of control;</div><div>            too weak risks being mistaken for tacit approval.</div></div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jun 17, 2021 at 4:43 PM Christoph Paasch <<a href="mailto:cpaasch@apple.com" target="_blank">cpaasch@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
On 06/17/21 - 11:16, Matt Mathis via Bloat wrote:<br>
> Is there a paper or spec for RPM?<br>
<br>
we try to publish an IETF-draft on the methodology before the upcoming IETF<br>
in July.<br>
<br>
But, in the mean-time please see inline:<br>
<br>
> There are at least two different ways to define RPM, both of which might be<br>
> relevant.<br>
> <br>
> At the TCP layer: it can be directly computed from a packet capture.  The<br>
> trick is to time reverse a trace and compute the critical path backwards<br>
> through the trace: what event triggered each segment or ACK, and count<br>
> round trips.  This would be super robust but does not include the queueing<br>
> required in the kernel socket buffers.  I need to think some more about<br>
> computing TCP RPM from tcp_info or other kernel instrumentation - it might<br>
> be possible.<br>
<br>
We explicitly opted against measuring purely TCP-level round-trip times. Because<br>
there are countless transparent TCP-proxies out there that would skew these<br>
numbers. Our goal with RPM/Responsiveness is to measure how an end-user would<br>
experience the network. Which means, DNS-resolution, TCP handshake-time,<br>
TLS-handshake, HTTP/2 Request/response. Because, at the end, that's what<br>
actually matters to the users.<br>
<br>
> A different RPM can be done in the application, above TCP, for example by<br>
> ping-ponging messages.  This would include the delays traversing the kernel<br>
> socket buffers which have to be at least as large as a full network RTT.<br>
> <br>
> This is perhaps an important point: due to the retransmit and<br>
> reassuebly queues (which are required to implement robust data delivery)<br>
> TCP must be able hold at least a full RTT of data in it's own buffers,<br>
> which means that under some conditions the RTT as seen by the application<br>
> has be be at least twice the network's RTT, including any bloat in the<br>
> network.<br>
<br>
Currently, we measure RPM on separate connections (not the load-bearing<br>
ones). We are also measuring on the load-bearing connections themselves<br>
through H2 Ping frames. But for the reasons you described we haven't yet<br>
factored it into the RPM-number.<br>
<br>
One way may be to inspect with TCP_INFO whether or not the connections had<br>
retransmissions and then throw away the number. On the other hand, if the<br>
network becomes extremely lossy under working conditions, it does impact the<br>
user-experience and so it could make sense to take this into account.<br>
<br>
<br>
In the end, we realized how hard it is to accurately measure bufferbloat<br>
within a reasonable time-frame (our goal is to finish the test within ~15<br>
seconds).<br>
<br>
We hope that with the IETF-draft we can get the right people together to<br>
iterate over it and squash out a very accurate measurement that represents<br>
what users would experience.<br>
<br>
<br>
Cheers,<br>
Christoph<br>
<br>
<br>
> <br>
> Thanks,<br>
> --MM--<br>
> The best way to predict the future is to create it.  - Alan Kay<br>
> <br>
> We must not tolerate intolerance;<br>
>        however our response must be carefully measured:<br>
>             too strong would be hypocritical and risks spiraling out of<br>
> control;<br>
>             too weak risks being mistaken for tacit approval.<br>
> <br>
> <br>
> On Sat, Jun 12, 2021 at 9:11 AM Rich Brown <<a href="mailto:richb.hanover@gmail.com" target="_blank">richb.hanover@gmail.com</a>> wrote:<br>
> <br>
> > > On Jun 12, 2021, at 12:00 PM, <a href="mailto:bloat-request@lists.bufferbloat.net" target="_blank">bloat-request@lists.bufferbloat.net</a> wrote:<br>
> > ><br>
> > > Some relevant talks / publicity at WWDC -- the first mentioning CoDel,<br>
> > > queueing, etc. Featuring Stuart Cheshire. iOS 15 adds a developer test<br>
> > for<br>
> > > loaded latency, reported in "RPM" or round-trips per minute.<br>
> > ><br>
> > > I ran it on my machine:<br>
> > > nowens@mac1015 ~ % /usr/bin/networkQuality<br>
> > > ==== SUMMARY ====<br>
> > > Upload capacity: 90.867 Mbps<br>
> > > Download capacity: 93.616 Mbps<br>
> > > Upload flows: 16<br>
> > > Download flows: 20<br>
> > > Responsiveness: Medium (840 RPM)<br>
> ><br>
> > Does anyone know how to get the command-line version for current (not<br>
> > upcoming) macOS? Thanks.<br>
> ><br>
> > Rich<br>
> > _______________________________________________<br>
> > Bloat mailing list<br>
> > <a href="mailto:Bloat@lists.bufferbloat.net" target="_blank">Bloat@lists.bufferbloat.net</a><br>
> > <a href="https://lists.bufferbloat.net/listinfo/bloat" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/bloat</a><br>
> ><br>
<br>
> _______________________________________________<br>
> Bloat mailing list<br>
> <a href="mailto:Bloat@lists.bufferbloat.net" target="_blank">Bloat@lists.bufferbloat.net</a><br>
> <a href="https://lists.bufferbloat.net/listinfo/bloat" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/listinfo/bloat</a><br>
<br>
</blockquote></div>
</div></blockquote></div></blockquote></div>