[Bloat] Apple WWDC Talks on Latency/Bufferbloat

[Matt Mathis]

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 <cpaasch at apple.com> 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 <mattmathis at google.com> 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 <cpaasch at 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 at gmail.com>
>> wrote:
>> >
>> > > > On Jun 12, 2021, at 12:00 PM, bloat-request at 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 at 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 at lists.bufferbloat.net
>> > > https://lists.bufferbloat.net/listinfo/bloat
>> > >
>>
>> > _______________________________________________
>> > Bloat mailing list
>> > Bloat at lists.bufferbloat.net
>> > https://lists.bufferbloat.net/listinfo/bloat
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20210617/f61feb36/attachment-0001.html>