From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 9ED783B29E for ; Thu, 17 Jun 2021 14:16:48 -0400 (EDT) Received: by mail-wr1-x429.google.com with SMTP id o3so7806811wri.8 for ; Thu, 17 Jun 2021 11:16:48 -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; bh=Nr7RV1pybXPl6CBV9CP44PdaeW+8Nzyh/NDkrDph2+M=; b=VFZgEsMZxouZjkM9ErB6MKSuLXuqD28A6fnar/xh680HI1bLn0ATfz2yc/XjgRvxFc 6cqukqTxfrLTT0hhvXyyDqF6NOeCF+gtQ7eIIyUxXPenJVRWh4scmswMjFjaP5SVr7w4 IceltGeUG7RrvKkG3Pzna/LujU3AwHKqIsRKLVKLCnK7s1hO0RcR/yIN8E1AUmq8Pgob lxR6lFVMAyUt1IhtCv1HEhtHytdtuCHqBYOKnEs+t78LsK0iJhQ3Vt7GvHXZzVaaMjeB NwgIcDAMZ89P2FUfExPrabwVjHYB8JKvQWQ+QtF/p/2hs0xN+Gtnn/s+jiLHyTXfBZr/ D9xw== 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; bh=Nr7RV1pybXPl6CBV9CP44PdaeW+8Nzyh/NDkrDph2+M=; b=IavxWfQ/zusNyCdDW9kl90LccX7WiEWKnMd27+aeRzemMWqkUauBP8luMskMYA+HWq NtTUkVWwxeh7lIf9AmZqlp2e67lqBSpQMd/1037cQA6Fy6vfg4xypnsUajLtt8eRSLvn okp2LLNnnDTPFgH/WNNmzBudr/WQQ8++AzjIiYg+2wL3LY/Cba73D/4SoBwdPE6X19vZ Wa8hjWayXo268m2RdbvCryQeA9vCerjJcNW7TvUwlZ8IIHvlgT9uGcY2GJcidM7KvLH7 XEElLZN9p8aFFEVuIBWa672FlhSjMgfoEP9uZTH1TsoPG4SaqDctXokQKTXQXt1VEKy6 0OoQ== X-Gm-Message-State: AOAM531lOWuD0vyl8iO9Zl82YSTD0ZxdqLgDfXqworVa6XqzYMehLFKc PiAGeUdLzWq1Z/E96BmTjFGf1xH/o3bSiOeFilF76G3Mad4= X-Google-Smtp-Source: ABdhPJzO43VZfUuXEmscBAIIYQJD5h+jflu+N8MB3xFqnXmuheJ9MR2WUeLS7D1RyVrAfVNd4UBEIYzAEdirkHsp9pI= X-Received: by 2002:adf:d1e4:: with SMTP id g4mr7393617wrd.405.1623953806527; Thu, 17 Jun 2021 11:16:46 -0700 (PDT) MIME-Version: 1.0 References: <62E013CF-ECE9-4022-B092-DFCE2176F772@gmail.com> In-Reply-To: <62E013CF-ECE9-4022-B092-DFCE2176F772@gmail.com> From: Matt Mathis Date: Thu, 17 Jun 2021 11:16:34 -0700 Message-ID: To: bloat Content-Type: multipart/alternative; boundary="000000000000c5b0c305c4fa356e" 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: Thu, 17 Jun 2021 18:16:48 -0000 --000000000000c5b0c305c4fa356e Content-Type: text/plain; charset="UTF-8" Is there a paper or spec for RPM? 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. 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. 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 > --000000000000c5b0c305c4fa356e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Is there a paper or spec for RPM?

There= are at least two different ways to define RPM, both of which might be rele= vant.

At the TCP layer: it can be directly compute= d from a packet capture.=C2=A0 The trick is to time reverse a trace and com= pute the critical path backwards through the trace: what event triggered ea= ch 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 othe= r kernel instrumentation - it might be possible.

A d= ifferent=C2=A0RPM 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 = RTT.

This is perhaps an important point: due to th= e retransmit and reassuebly=C2=A0queues (which are required to implement=C2= =A0robust 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, inc= luding any bloat in the network.=C2=A0=C2=A0

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

We mu= st 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 ris= ks spiraling out of control;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 too weak risks being mistaken for tacit approval.
<= /div>


On Sat, Jun 12, 2021 at 9:11 AM Rich= Brown <ric= hb.hanover@gmail.com> wrote:
> On Jun 12, 2021, at 12:00 PM, bloat-request@lists.bu= fferbloat.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 (not upcom= ing) macOS? Thanks.

Rich
_______________________________________________
Bloat mailing list
Bloat@list= s.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
--000000000000c5b0c305c4fa356e--