From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (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 697593B29E for ; Thu, 17 Jun 2021 20:17:47 -0400 (EDT) Received: by mail-wm1-x334.google.com with SMTP id c84so4496296wme.5 for ; Thu, 17 Jun 2021 17:17:47 -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=gKHg7zTC4k/43w/C0jImronyzq9WHXUvwzuibZTYTBE=; b=tPEddFGdLmyITEDk/LLBuwRjPy9ya9JXnYKvOzUTOVKyw3fUDwdzUYO2RLcvyYn/uJ zOF4EVY+qFmArB/hyr3HfZDuv1UWx541Y4WXLbF/sq5QnI8FClKtkAg2n/VL3co3lklF j9Ivjudg2JuKJsjENcUlexW5RJT6SHBlwFWnGTNre04JvHvUJk1s6lyNVXXAlEv9q/xX BJVSUB7LRJ0s/GGckNoL+Ov7ivr7el0GLoqv5MnpzyvhfITIsju3uVMj/+3+jxa9p8d0 jJwLREYCu0zBFxis9KiZZp3D9w0r+ndmuiTKITbONtZ5KyZSoZJnqbjefwQ1UbKYYcmX QS5A== 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=gKHg7zTC4k/43w/C0jImronyzq9WHXUvwzuibZTYTBE=; b=VXLceUeyd5ZXsjkGHeVihwymIL5Y6NtltKG0Kn+xnTm2sIRvoEQR3O1HjQu8D84BLT WQr/JwUG5q8LxEysIlTGi+upKsBSLMQ/KiVws88fuUrOtQRi4ytkTzgaTuCUq5eIFktb 3PQaPi3/xFQXmTQ7pETcNP+XGhMDLQ37Lpg4t0kdl59ek7EfI3BXCuFm1wZrct6g02Ar Ai6Hn4p2sSvhQSL94HcJHD5a9mx45Xl7Nq15CxKFBTKz8YLqhEts1sFr7ZmeEzaJhHzH 4NNG0pntPSZQXw3THfKJd/if7mUgES4Mncr5ILNbH9nIYMl2nZWyKpgji1y0s+9YVO7+ ruOA== X-Gm-Message-State: AOAM533Lld+b5VQ6zxuy7oEzn3LnBTLp3ActTYKu/xtRR4a2/WLX6uEC g7Bk3/eCZfaKDAj8P2srF/uQrBlMsXCi436UN+mo0A== X-Google-Smtp-Source: ABdhPJzWOcHR8YXH30x2P44I4yMFuSbLIZHMpWNqlkBBPcz8psOVrB22M5fmSwtvGQwtMJ4IzSQc+vMi2a5t5x6iPfk= X-Received: by 2002:a1c:a445:: with SMTP id n66mr8070818wme.140.1623975466261; Thu, 17 Jun 2021 17:17:46 -0700 (PDT) MIME-Version: 1.0 References: <62E013CF-ECE9-4022-B092-DFCE2176F772@gmail.com> In-Reply-To: From: Matt Mathis Date: Thu, 17 Jun 2021 17:17:34 -0700 Message-ID: To: Christoph Paasch Cc: bloat Content-Type: multipart/alternative; boundary="000000000000cabed905c4ff406b" 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 00:17:47 -0000 --000000000000cabed905c4ff406b Content-Type: text/plain; charset="UTF-8" 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 > > --000000000000cabed905c4ff406b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Which WG are you targeting?

=
Thanks,--MM--
The best way to predict the future is to create it. =C2=A0- A= lan 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 mistaken for tacit approva= l.


On Thu, Jun 17, 2021= at 4:43 PM Christoph Paasch <cpaas= ch@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
--000000000000cabed905c4ff406b--