Also consider ippm. intarea might be a good choice for joint sponsorship, but they probably won't want to be the lead. 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. 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 6:04 PM Christoph Paasch wrote: > Not sure yet - there isn’t a good one that would really fit. Maybe tsvwg > or intarea. > > Suggestions? > > Cheers, > Christoph > > On Jun 17, 2021, at 5:17 PM, Matt Mathis wrote: > >  > 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 > 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 >> 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 >> >>