From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (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 162973CB52 for ; Tue, 6 Jul 2021 15:04:49 -0400 (EDT) Received: by mail-wr1-x42b.google.com with SMTP id t6so177727wrm.9 for ; Tue, 06 Jul 2021 12:04:49 -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=z2GgHmgmBuoP8htfqCNu3qQVFn4PWNprFnkOEJcfpxM=; b=BP327ceMThgi7Rk55VY4g0lPgo2U8Sc0cYjav5y0d6cNCDpYpC69cH9XUX0XzumGqr wZ8e0plRE0HReLieIPfAT3ilSL7pbRqTZT2Jcbr1YkSssfPSoifkEMrV+Icllyjg3tna im+O1I7/aEHHM1D/aTdJYAp8rdUG0NwT4SHrJijG5Kqkjmq/UiUfBGOFDOzXne2ph+eD gYiocARXwqK6w+O/9gG+3Xk8xVCpli74owpHBnPwEol1dy+hIZNVgC9dgnE9hxhwrOnq a6Y6v9iVIzUbKfTdvCzvdbcXgW8pJRkEXu5ia/vNJ8bLEwfiX98Fc6AwY6xgEElewzrw 9U/g== 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=z2GgHmgmBuoP8htfqCNu3qQVFn4PWNprFnkOEJcfpxM=; b=jmm8lVGo0oUwZkFvyUYtfruxGwequQDycO8mQaqEHD1QTpHcFsd8S3n8zCn9Pkcx+y WiSw4zCCXG3rWbD21zjm3XN7vsBhYujAfttneMsErV58SPP1LW7So0/ThYZTKrrqjo5h y9LsCqAA6s6dG0TcgCbOVWuQZMJbe/3bHWvgN+WjVhlGe4wjZjB4xVKa7YN5slcLaH1X CnMuOvO/bQY62u93s7MUzFCAFpH7gN0nbcXNujjnS3Qawj2uqpOSAiXQQx0bWiJBzh4A 72FH7D7CLV+yB4JokrQH5nfHAvNniINSaiQ6nDPQgsptEVxOZJsY2ncFozq7TXvTV3ax yzlw== X-Gm-Message-State: AOAM530tCOqujmql44Vp01ZY+GqQ2SJEnONwuScKnWYMT69mWXUZb1R3 wShysWiZ4avh/3BPgnOKfS6Teqq/GooGhAlgDVA5Qg== X-Google-Smtp-Source: ABdhPJzDIadUnGMPOyQzNMLp0aohNdMJUMkkNAZBHF924IJb5upObhs5rvjmofnOljYfz8Zi6GId7oz7E7BS/x9ubco= X-Received: by 2002:a5d:560c:: with SMTP id l12mr23930484wrv.310.1625598287927; Tue, 06 Jul 2021 12:04:47 -0700 (PDT) MIME-Version: 1.0 References: <5C8DA517-01DE-477F-9B3D-952D953EEC89@gmail.com> In-Reply-To: <5C8DA517-01DE-477F-9B3D-952D953EEC89@gmail.com> From: Matt Mathis Date: Tue, 6 Jul 2021 12:04:35 -0700 Message-ID: To: Jonathan Morton Cc: Stuart Cheshire , Christoph Paasch , bloat , Omer Shapira , Randall Meyer Content-Type: multipart/alternative; boundary="0000000000008070e505c67918a7" Subject: Re: [Bloat] Credit and/or collaboration on a responsiveness metric? 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: Tue, 06 Jul 2021 19:04:49 -0000 --0000000000008070e505c67918a7 Content-Type: text/plain; charset="UTF-8" (Adding other Apple developers back in) Jonathan, you didn't even go in the direction I was expecting. My fragmentary ideas: Round counting (the underlying primitive) can be measured or estimated in several different ways at different layers: TCP/transport layer: >From a .pcap, count rounds: data->ACK->data. easiest in reverse time, but timeouts are hard >From polled smoothed RTT (TCP_INFO or Web100): SUM (poll_interval/SRTT) is an estimate of the number of elapsed rounds - The SRTT algorithm has been quite stable for decades - This algorithm could be applied to ~ 4 Billion MLab traces, collected over the last 11 years but are not exposed in the current data processing pipeline (my current project) transport ABI (untested idea); Use instrumented minimal TCP or QUIC applications (e.g. chargen, echo and discard) to count rounds For WFID, this would also include the socket buffer backlog, and how intelligently the kernel manages buffer space library: Use ping messages in http, websockets and other "application" protocols This also includes the library buffers and their management Note that (rounds per second) * (throughput) is network power Also the number of rounds "consumed" by an application can be measured. I will see everybody on Dave's call. 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 Tue, Jul 6, 2021 at 1:48 AM Jonathan Morton wrote: > > On 6 Jul, 2021, at 2:21 am, Matt Mathis wrote: > > > > The rounds based responsiveness metric is awesome! There are several > slightly different versions, with slightly different properties.... > > > > I would like to write a little paper (probably for the IAB workshop), > but don't want to short change anybody else's credit, or worse, scoop > somebody else's work in progress. I don't really know if I am retracing > somebody else's steps, or on a parallel but different path (more likely). > I would be really sad to publish something and then find out later that I > trashed some PhD students' thesis.... > > It's possible that I had some small influence in originating it, although > Dave did most of the corporate marketing. > > My idea was simply to express delays and latencies as a frequency, in Hz, > so that "bigger numbers are better", rather than always in milliseconds, > where "smaller numbers are better". The advantage of Hz is that you can > directly compare it to framerates of video or gameplay. > > Conversely, an advantage of "rounds per minute" is that you don't need to > deal with fractions or rounding for relatively modest and common levels of > bloat, where latencies of 1-5 seconds are typical. > > I'm not overly concerned with taking credit for it, though. It's a > reasonably obvious idea to anyone who takes a genuine interest in this > field, and other people did most of the hard work. > > > Please let me know if you know of anybody else working in this space, of > any publications that might be in progress or if people might be interested > in another collaborator. > > There are two distinct types of latency that RPM can be used to measure, > and I have written a short Internet Draft describing the distinction: > > > https://www.ietf.org/archive/id/draft-morton-tsvwg-interflow-intraflow-delays-00.html > > Briefly, "inter-flow delays" (or BFID) are what you measure with an > independent latency-measuring flow, and "intra-flow delays" (or WFID) are > what you measure by inserting latency probes into an existing flow (whether > at the protocol level with HTTP2, or by extracting it from existing > application activity). The two typically differ when the path bottleneck > has a flow-isolating queue, or when the application flow experiences loss > and retransmission recovery. > > I think both measures are important in different contexts. An individual > application may be concerned with its own intra-flow delay, as that > determines how quickly it can respond to changes in network conditions or > user intent. Network engineers should be concerned with inter-flow delays, > as those determine what effect a bulk application load has on other, more > latency-sensitive applications. The two are also optimally controlled by > different mechanisms - FQ versus AQM - which is why the combination of the > two is so powerful. > > Feel free to use material from the above with appropriate attribution. > > - Jonathan Morton --0000000000008070e505c67918a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(Adding other Apple developers back in)
Jonathan, you = didn't even go in the direction I was expecting.=C2=A0 =C2=A0My fragmen= tary ideas:

Round counting (the underlying primiti= ve) can be measured or estimated in several different ways at different lay= ers:
TCP/transport layer:
From a .pcap, count rounds: data->ACK= ->data.=C2=A0 easiest in reverse time, but timeouts are hard
From pol= led smoothed RTT (TCP_INFO or Web100): SUM (poll_interval/SRTT) is an estim= ate=C2=A0of the number of elapsed rounds
- The SRTT algorithm=C2=A0has b= een quite stable for=C2=A0 decades
- This algorithm could be applied to = ~ 4 Billion MLab traces, collected over the last 11 years but are not expos= ed in the current data processing pipeline (my current project)
transport ABI (untested idea);
Use instrumented minimal TCP or QUI= C applications (e.g. chargen, echo and discard) to count rounds
F= or WFID, this would also include=C2=A0the socket=C2=A0buffer backlog, and h= ow intelligently=C2=A0the kernel manages buffer space
library:
Use ping messages=C2=A0in http, websockets and other &= quot;application" protocols
This also includes the library= buffers and their management

Note that (r= ounds per second) * (throughput) is network power

= Also the number of rounds "consumed" by an application can be mea= sured.

I will see everybody on Dave's call.

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 Tue, Jul 6, 2021 at 1:48 AM Jonathan Morton <chromatix99@gmail.com> wrote:
> On 6 Jul, 2021, at 2:21 am, Mat= t Mathis <mat= tmathis@google.com> wrote:
>
> The rounds based responsiveness metric is awesome!=C2=A0 =C2=A0There a= re several slightly different versions, with slightly different properties.= ...
>
> I would like to write a little paper (probably for the IAB workshop), = but don't want to short change anybody else's credit, or worse, sco= op somebody else's work in progress.=C2=A0 =C2=A0I don't really kno= w if I am retracing somebody else's steps, or on a parallel but differe= nt path (more likely).=C2=A0 =C2=A0I would be really sad to publish somethi= ng and then find out later that I trashed some PhD students' thesis....=

It's possible that I had some small influence in originating it, althou= gh Dave did most of the corporate marketing.

My idea was simply to express delays and latencies as a frequency, in Hz, s= o that "bigger numbers are better", rather than always in millise= conds, where "smaller numbers are better".=C2=A0 The advantage of= Hz is that you can directly compare it to framerates of video or gameplay.=

Conversely, an advantage of "rounds per minute" is that you don&#= 39;t need to deal with fractions or rounding for relatively modest and comm= on levels of bloat, where latencies of 1-5 seconds are typical.

I'm not overly concerned with taking credit for it, though.=C2=A0 It= 9;s a reasonably obvious idea to anyone who takes a genuine interest in thi= s field, and other people did most of the hard work.

> Please let me know if you know of anybody else working in this space, = of any publications that might be in progress or if people might be interes= ted in another collaborator.

There are two distinct types of latency that RPM can be used to measure, an= d I have written a short Internet Draft describing the distinction:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/archive/id/draft-morton-tsvwg-interflow-i= ntraflow-delays-00.html

Briefly, "inter-flow delays" (or BFID) are what you measure with = an independent latency-measuring flow, and "intra-flow delays" (o= r WFID) are what you measure by inserting latency probes into an existing f= low (whether at the protocol level with HTTP2, or by extracting it from exi= sting application activity).=C2=A0 The two typically differ when the path b= ottleneck has a flow-isolating queue, or when the application flow experien= ces loss and retransmission recovery.

I think both measures are important in different contexts.=C2=A0 An individ= ual application may be concerned with its own intra-flow delay, as that det= ermines how quickly it can respond to changes in network conditions or user= intent.=C2=A0 Network engineers should be concerned with inter-flow delays= , as those determine what effect a bulk application load has on other, more= latency-sensitive applications.=C2=A0 The two are also optimally controlle= d by different mechanisms - FQ versus AQM - which is why the combination of= the two is so powerful.

Feel free to use material from the above with appropriate attribution.

=C2=A0- Jonathan Morton
--0000000000008070e505c67918a7--