From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 922153B29E for ; Thu, 17 Jun 2021 23:34:03 -0400 (EDT) Received: by mail-wm1-x32d.google.com with SMTP id u5-20020a7bc0450000b02901480e40338bso5788959wmc.1 for ; Thu, 17 Jun 2021 20:34:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=obW5NMTqrmiT/j2MyTH9/R8bShVyIDDwRYqW58naAZc=; b=qpYKa1/NcaWpEXX0ltIAkU5jdHt7HSzrfq7TjPj64h6a9OA/dppKVgd+nv+V4wgJr/ dWRhG0uh+EwNXLnOrzt/nNczmRisnM3ec6pXDFq7y8HxB7hI9SJjHiYabH/NAanbPfao WIC359YNGekkql1qh7TMN17A59m8FM/kkS/zzVgQIj3l7ZxKc12OVgdx8kYjptW9blYd F/iRWMmZKCBo1MXQfW8hZC6lfKypMJTy6Q2tItAce+qO/aBhAPZU3FHWwLxvd2v/tJZQ oSpvvLwhfwPFGI2fNvtwJMOdqPMKEPJTJR3ZFHVFgBcqwBVuwFMYbgBbdZQlXnhl+8j1 bVdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=obW5NMTqrmiT/j2MyTH9/R8bShVyIDDwRYqW58naAZc=; b=r2scjI6VfvxXFkJmgxippHEO4Xa3LlFSEXfzgCbMokN709ftMtwa4HC+0EdfJYO++V fw7auF3L7xUMi8xP/n3InAo0oLw+iW+fHk4BJv2N6zv2c7Mxpe+EWybrWSwUhuvhiWJ0 03X9/Vhu/0H5uxohGXuqLuTKmTu85ZCY4LBrpa+8bk0epgjKobCzFuiDw4gG95bDEB5a IYxn+Hq6qaMFrTk5YOE/ifdxy/TEtMD+Fyqh4x8Tf/ggizI7I3AVn5jabaBxopLPzROy HI23PIBamnMPcgBnc8LA9ZAj8w9A35Sdsp9jG1Fq5GJVhNf3QAlsi10wPfHEQULgzlzb JbkQ== X-Gm-Message-State: AOAM533IDIUtDynnO12MuAc+pH4gqxehC45uarjYJEupOdf1ueNywg1S sFG55+XmHduU5i+Buw0SjxF0BZie1sIkvOKliDN5nw== X-Google-Smtp-Source: ABdhPJyih5RxnGcJjewRTmesdgJG4uB+BIZD6F+IVBeBXFoPV2m/z5k7JAFqCGVfF7S5MUsHhattcr9DiqTv+kSu58U= X-Received: by 2002:a1c:4c11:: with SMTP id z17mr197069wmf.82.1623987242261; Thu, 17 Jun 2021 20:34:02 -0700 (PDT) MIME-Version: 1.0 References: <30546A13-7887-47C6-9104-E2D7E20DA38F@apple.com> In-Reply-To: <30546A13-7887-47C6-9104-E2D7E20DA38F@apple.com> From: Matt Mathis Date: Thu, 17 Jun 2021 20:33:49 -0700 Message-ID: To: Christoph Paasch Cc: bloat Content-Type: multipart/alternative; boundary="000000000000b297f305c501fedf" 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 03:34:03 -0000 --000000000000b297f305c501fedf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=99t a good one that would really fit. Mayb= e tsvwg > or intarea. > > Suggestions? > > Cheers, > Christoph > > On Jun 17, 2021, at 5:17 PM, Matt Mathis 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; > 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 backwar= ds >> > 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 abou= t >> > 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 RT= T. >> > >> > This is perhaps an important point: due to the retransmit and >> > reassuebly queues (which are required to implement robust data deliver= y) >> > 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 h= ad >> retransmissions and then throw away the number. On the other hand, if th= e >> 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 ~1= 5 >> 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 represen= ts >> 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 o= f >> > 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 >> > > > =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 (no= t >> > > 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 >> >> --000000000000b297f305c501fedf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Also consider ippm.=C2=A0 intarea might be a good choice f= or joint sponsorship, but they=C2=A0probably 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=C2= =A0OS mis features.

Thanks,
--MM--
The best way to predict the f= uture is to create it. =C2=A0- Alan Kay

We must not tolerate intoler= ance;
=C2=A0 =C2=A0 =C2=A0 =C2=A0however our response= must be carefully measured:=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 too strong would be hypocritical and risks spiraling out of c= ontrol;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 too weak risks = being mistaken for tacit approval.

<= /div>
O= n Thu, Jun 17, 2021 at 6:04 PM Christoph Paasch <cpaasch@apple.com> wrote:
<= div dir=3D"ltr">Not sure yet - there isn=E2=80=99t a good one that would re= ally fit. Maybe tsvwg or intarea.

Suggestions?

Chee= rs,
Christoph

On Jun 17, 2021, at 5:17 PM, Matt Mathis <mattmathis@google.com> wro= te:

= =EF=BB=BF
Which WG are you targeting?

Thanks,
--MM--
The best way to predict the future is = to create it. =C2=A0- Alan Kay

We must not tolerate intolerance;
=C2=A0 =C2=A0 =C2=A0 =C2=A0however our response must be = carefully measured:=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 too strong would be hypocritical and risks spiraling out of control;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 too weak risks being mist= aken 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 mig= ht be
> relevant.
>
> At the TCP layer: it can be directly computed from a packet capture.= =C2=A0 The
> trick is to time reverse a trace and compute the critical path backwar= ds
> through the trace: what event triggered each segment or ACK, and count=
> round trips.=C2=A0 This would be super robust but does not include the= queueing
> required in the kernel socket buffers.=C2=A0 I need to think some more= about
> computing TCP RPM from tcp_info or other kernel instrumentation - it m= ight
> be possible.

We explicitly opted against measuring purely TCP-level round-trip times. Be= cause
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 wou= ld
experience the network. Which means, DNS-resolution, TCP handshake-time, TLS-handshake, HTTP/2 Request/response. Because, at the end, that's wha= t
actually matters to the users.

> A different RPM can be done in the application, above TCP, for example= by
> ping-ponging messages.=C2=A0 This would include the delays traversing = the kernel
> socket buffers which have to be at least as large as a full network RT= T.
>
> This is perhaps an important point: due to the retransmit and
> reassuebly queues (which are required to implement robust data deliver= y)
> TCP must be able hold at least a full RTT of data in it's own buff= ers,
> which means that under some conditions the RTT as seen by the applicat= ion
> 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 ye= t
factored it into the RPM-number.

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 network becomes extremely lossy under working conditions, it does impact th= e
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<= br> what users would experience.


Cheers,
Christoph


>
> Thanks,
> --MM--
> The best way to predict the future is to create it.=C2=A0 - Alan Kay >
> We must not tolerate intolerance;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 however our response must be carefully meas= ured:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0too strong would be hyp= ocritical and risks spiraling out of
> control;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0too weak risks being mi= staken 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 mention= ing CoDel,
> > > queueing, etc. Featuring Stuart Cheshire. iOS 15 adds a deve= loper test
> > for
> > > loaded latency, reported in "RPM" or round-trips p= er 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
> >

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