From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from rn-mailsvcp-ppex-lapp34.apple.com (rn-mailsvcp-ppex-lapp34.rno.apple.com [17.179.253.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 3F53D3B29E for ; Thu, 17 Jun 2021 21:04:01 -0400 (EDT) Received: from pps.filterd (rn-mailsvcp-ppex-lapp34.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp34.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 15I13rxR021781; Thu, 17 Jun 2021 18:03:59 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=content-type : content-transfer-encoding : from : mime-version : subject : date : message-id : references : cc : in-reply-to : to; s=20180706; bh=pnztVFGJJfZEaYgRP7i0N3gpucCX2YMYg4T0f5s1u6c=; b=w+ASyx5qODQr6Yjcm+SUjaO9aG/ErpqpMmWZIB9ebklk7k9XW/KhiO2bweoXQjJVJMjB 3lDyKoKzW+25SY6Ujml58FPnlCUVi+TEaVncRMWd42u48uH+yUCk6lhPjFr4sykLpDut UhCQSV2CPbyrPH4A+O3giL3+0tg4hzxVQKwHeneSJgTO+vkXEO5Z/ye2JdezFJn01ajL i/Yc5AV2LcSNzm4Ua9F7n5EyCJXUT9wQ8v1JPwBs5Ocj4/rCzxf4P3jUjdvoxZXAUfI3 7ifYeuPGIS1Qmv/BKizPPRbf3ivZ0SWmTGqNrEeLt4D8caYiUO1kcf/w+yW5q5dkvZDD FA== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by rn-mailsvcp-ppex-lapp34.rno.apple.com with ESMTP id 394rs3r71j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 17 Jun 2021 18:03:59 -0700 Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPS id <0QUV002RVHMM9O30@rn-mailsvcp-mta-lapp03.rno.apple.com>; Thu, 17 Jun 2021 18:03:58 -0700 (PDT) Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) id <0QUV00V00HHCZW00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Thu, 17 Jun 2021 18:03:58 -0700 (PDT) X-Va-A: X-Va-T-CD: 0784ebc13a2136f668ccea2ff57975fe X-Va-E-CD: bcb3ed6ab20966b139d3f01c1a94bc42 X-Va-R-CD: c61df103aa9e6bfe62892afaffca7067 X-Va-CD: 0 X-Va-ID: 9c9aa660-a55b-4f1c-a765-501775b1c9b2 X-V-A: X-V-T-CD: 0784ebc13a2136f668ccea2ff57975fe X-V-E-CD: bcb3ed6ab20966b139d3f01c1a94bc42 X-V-R-CD: c61df103aa9e6bfe62892afaffca7067 X-V-CD: 0 X-V-ID: dfd0d023-50cf-4a03-9a4b-17ac4db78057 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-06-17_16:2021-06-15, 2021-06-17 signatures=0 Received: from smtpclient.apple (unknown [17.11.164.242]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPSA id <0QUV00GE5HMJW500@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Thu, 17 Jun 2021 18:03:58 -0700 (PDT) Content-type: multipart/alternative; boundary=Apple-Mail-5FD0E1ED-72F7-4427-8659-58594F1F9728 Content-transfer-encoding: 7bit From: Christoph Paasch MIME-version: 1.0 (1.0) Date: Thu, 17 Jun 2021 18:03:54 -0700 Message-id: <30546A13-7887-47C6-9104-E2D7E20DA38F@apple.com> References: Cc: bloat In-reply-to: To: Matt Mathis X-Mailer: iPhone Mail (19A283a) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-06-17_16:2021-06-15, 2021-06-17 signatures=0 Subject: Re: [Bloat] Apple WWDC Talks on Latency/Bufferbloat X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jun 2021 01:04:01 -0000 --Apple-Mail-5FD0E1ED-72F7-4427-8659-58594F1F9728 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Not sure yet - there isn=E2=80=99t a good one that would really fit. Maybe t= svwg or intarea. Suggestions? Cheers, Christoph > On Jun 17, 2021, at 5:17 PM, Matt Mathis wrote: >=20 > =EF=BB=BF > Which WG are you targeting? >=20 > Thanks, > --MM-- > The best way to predict the future is to create it. - Alan Kay >=20 > We must not tolerate intolerance; > however our response must be carefully measured:=20 > too strong would be hypocritical and risks spiraling out of co= ntrol; > too weak risks being mistaken for tacit approval. >=20 >=20 >> On Thu, Jun 17, 2021 at 4:43 PM Christoph Paasch wrot= e: >> Hello, >>=20 >> On 06/17/21 - 11:16, Matt Mathis via Bloat wrote: >> > Is there a paper or spec for RPM? >>=20 >> we try to publish an IETF-draft on the methodology before the upcoming IE= TF >> in July. >>=20 >> But, in the mean-time please see inline: >>=20 >> > There are at least two different ways to define RPM, both of which migh= t be >> > relevant. >> >=20 >> > At the TCP layer: it can be directly computed from a packet capture. T= he >> > trick is to time reverse a trace and compute the critical path backward= s >> > through the trace: what event triggered each segment or ACK, and count >> > round trips. This would be super robust but does not include the queue= ing >> > required in the kernel socket buffers. I need to think some more about= >> > computing TCP RPM from tcp_info or other kernel instrumentation - it mi= ght >> > be possible. >>=20 >> We explicitly opted against measuring purely TCP-level round-trip times. B= ecause >> there are countless transparent TCP-proxies out there that would skew the= se >> numbers. Our goal with RPM/Responsiveness is to measure how an end-user w= ould >> 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. >>=20 >> > A different RPM can be done in the application, above TCP, for example b= y >> > ping-ponging messages. This would include the delays traversing the ke= rnel >> > socket buffers which have to be at least as large as a full network RTT= . >> >=20 >> > 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 applicati= on >> > has be be at least twice the network's RTT, including any bloat in the >> > network. >>=20 >> 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. >>=20 >> One way may be to inspect with TCP_INFO whether or not the connections ha= d >> retransmissions and then throw away the number. On the other hand, if the= >> network becomes extremely lossy under working conditions, it does impact t= he >> user-experience and so it could make sense to take this into account. >>=20 >>=20 >> 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). >>=20 >> 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 represent= s >> what users would experience. >>=20 >>=20 >> Cheers, >> Christoph >>=20 >>=20 >> >=20 >> > Thanks, >> > --MM-- >> > The best way to predict the future is to create it. - Alan Kay >> >=20 >> > 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. >> >=20 >> >=20 >> > On Sat, Jun 12, 2021 at 9:11 AM Rich Brown wr= ote: >> >=20 >> > > > On Jun 12, 2021, at 12:00 PM, bloat-request@lists.bufferbloat.net w= rote: >> > > > >> > > > Some relevant talks / publicity at WWDC -- the first mentioning CoD= el, >> > > > queueing, etc. Featuring Stuart Cheshire. iOS 15 adds a developer t= est >> > > for >> > > > loaded latency, reported in "RPM" or round-trips per minute. >> > > > >> > > > I ran it on my machine: >> > > > nowens@mac1015 ~ % /usr/bin/networkQuality >> > > > =3D=3D=3D=3D SUMMARY =3D=3D=3D=3D >> > > > 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 >> > > >>=20 >> > _______________________________________________ >> > Bloat mailing list >> > Bloat@lists.bufferbloat.net >> > https://lists.bufferbloat.net/listinfo/bloat >>=20 --Apple-Mail-5FD0E1ED-72F7-4427-8659-58594F1F9728 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Not= sure yet - there isn=E2=80=99t a good one that would really fit. Maybe tsvw= g or intarea.

Suggestions?<= /div>

Cheers,
Christoph

On Jun 17, 2= 021, at 5:17 PM, Matt Mathis <mattmathis@google.com> wrote:

=EF=BB=BF
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;
    &nbs= p;  however our response must be carefully measured: 
&n= bsp;           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 Pa= asch <cpaasch@apple.com> wrot= e:
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<= br> in July.

But, in the mean-time please see inline:

> There are at least two different ways to define RPM, both of which migh= t be
> relevant.
>
> At the TCP layer: it can be directly computed from a packet capture.&nb= sp; The
> trick is to time reverse a trace and compute the critical path backward= s
> 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 q= ueueing
> required in the kernel socket buffers.  I need to think some more a= bout
> computing TCP RPM from tcp_info or other kernel instrumentation - it mi= ght
> be possible.

We explicitly opted against measuring purely TCP-level round-trip times. Bec= ause
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 woul= d
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 b= y
> ping-ponging messages.  This would include the delays traversing t= he 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,<= br> > which means that under some conditions the RTT as seen by the applicati= on
> has be be at least twice the network's RTT, including any bloat in the<= br> > 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 measu= red:
>             too strong would be hypo= critical and risks spiraling out of
> control;
>             too weak risks being mis= taken for tacit approval.
>
>
> On Sat, Jun 12, 2021 at 9:11 AM Rich Brown <richb.hanover@gmail.com> wrote:<= br> >
> > > On Jun 12, 2021, at 12:00 PM, bloat-request@lists.bufferbloat.ne= t wrote:
> > >
> > > Some relevant talks / publicity at WWDC -- the first mentioni= ng CoDel,
> > > queueing, etc. Featuring Stuart Cheshire. iOS 15 adds a devel= oper test
> > for
> > > loaded latency, reported in "RPM" or round-trips per minute.<= br> > > >
> > > I ran it on my machine:
> > > nowens@mac1015 ~ % /usr/bin/networkQuality
> > > =3D=3D=3D=3D SUMMARY =3D=3D=3D=3D
> > > 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
> > B= loat@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/bloat=
> >

> _______________________________________________
> Bloat mailing list
> Bloat@= lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat

= --Apple-Mail-5FD0E1ED-72F7-4427-8659-58594F1F9728--