From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from aye.elm.relay.mailchannels.net (aye.elm.relay.mailchannels.net [23.83.212.6]) (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 E66503CB52 for ; Tue, 6 Jul 2021 17:56:24 -0400 (EDT) X-Sender-Id: dreamhost|x-authsender|nichols@pollere.net Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 0C4144823D3; Tue, 6 Jul 2021 21:56:23 +0000 (UTC) Received: from pdx1-sub0-mail-a51.g.dreamhost.com (100-101-162-68.trex-nlb.outbound.svc.cluster.local [100.101.162.68]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id EBD0848192B; Tue, 6 Jul 2021 21:56:20 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nichols@pollere.net Received: from pdx1-sub0-mail-a51.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by 100.101.162.68 (trex/6.3.3); Tue, 06 Jul 2021 21:56:22 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nichols@pollere.net X-MailChannels-Auth-Id: dreamhost X-Stop-Continue: 15d914c43bbb423f_1625608582729_2707576003 X-MC-Loop-Signature: 1625608582729:140143931 X-MC-Ingress-Time: 1625608582729 Received: from pdx1-sub0-mail-a51.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a51.g.dreamhost.com (Postfix) with ESMTP id 6C4457F549; Tue, 6 Jul 2021 14:56:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pollere.net; h=reply-to :subject:to:cc:references:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s= pollere.net; bh=ObtlTyhLbyiJkJDnESYk+FhN8fE=; b=WNq9poPWY4dSkuKv Q0V0wttx/tD5UOLjFYUFG6dDze5+OoBcDoak3m2nXyw9mU/xjw+RK9xH6KpGKd4y TLuJsMLb2a4twWCVvPD1OnGqGAlixf0pLvJDeqlKr1ekd1AVfS9rW9TztwU7SK6m HXHv6KamCUo8mFmHkeqjRf7Yh9s= Received: from kmnimac.local (c-73-189-214-156.hsd1.ca.comcast.net [73.189.214.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nichols@pollere.net) by pdx1-sub0-mail-a51.g.dreamhost.com (Postfix) with ESMTPSA id 6120E7F537; Tue, 6 Jul 2021 14:56:19 -0700 (PDT) Reply-To: nichols@pollere.net To: Matt Mathis , Jonathan Morton Cc: Randall Meyer , Omer Shapira , bloat References: <5C8DA517-01DE-477F-9B3D-952D953EEC89@gmail.com> X-DH-BACKEND: pdx1-sub0-mail-a51 From: Kathleen Nichols Message-ID: <18b021f6-1f2e-1653-01dd-283f9882a17a@pollere.net> Date: Tue, 6 Jul 2021 14:56:17 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable 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 21:56:25 -0000 In coming up with metrics, I would really encourage you to think about making use of tdigest to gather statistics in some of your on-line measurement. I'm not sure users see "average" behavior. I mean if someone is getting great latency numbers most of the time, with a small percentage of unacceptable values, I don't think their meeting is seeing that "average" latency as the performance. Kathie On 7/6/21 12:04 PM, Matt Mathis via Bloat wrote: > (Adding other Apple developers back in) > Jonathan, you didn't even go in the direction I was expecting.=C2=A0 =C2= =A0My > fragmentary ideas: >=20 > Round counting (the underlying primitive) can be measured or estimated > in several different ways at different layers: > TCP/transport layer: >=20 > From a .pcap, count rounds: data->ACK->data.=C2=A0 easiest in rever= se > time, but timeouts are hard > From polled smoothed RTT (TCP_INFO or Web100): SUM > (poll_interval/SRTT) is an estimate=C2=A0of the number of elapsed r= ounds > - The SRTT algorithm=C2=A0has been 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 exposed in the current > data processing pipeline (my current project) >=20 > transport ABI (untested idea); >=20 > Use instrumented minimal TCP or QUIC applications (e.g. chargen, > echo and discard) to count rounds > For WFID, this would also include=C2=A0the socket=C2=A0buffer backl= og, and how > intelligently=C2=A0the kernel manages buffer space >=20 > library: >=20 > Use ping messages=C2=A0in http, websockets and other "application" = protocols >=20 > This also includes the library buffers and their management >=20 >=20 > Note that (rounds per second) * (throughput) is network power >=20 > Also the number of rounds "consumed" by an application can be measured. >=20 > I will see everybody on Dave's call. >=20 > Thanks, > --MM-- > The best way to predict the future is to create it. =C2=A0- Alan Kay >=20 > We must not tolerate intolerance; > =C2=A0 =C2=A0 =C2=A0 =C2=A0however our response must be carefully measu= red:=C2=A0 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 too strong would be hypocriti= cal 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 approval. >=20 >=20 > On Tue, Jul 6, 2021 at 1:48 AM Jonathan Morton > wrote: >=20 > > On 6 Jul, 2021, at 2:21 am, Matt Mathis > wrote: > > > > The rounds based responsiveness metric is awesome!=C2=A0 =C2=A0Th= ere 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.=C2=A0 =C2=A0I don't = really know > if I am retracing somebody else's steps, or on a parallel but > different path (more likely).=C2=A0 =C2=A0I would be really sad to = publish > something and then find out later that I trashed some PhD students' > thesis.... >=20 > It's possible that I had some small influence in originating it, > although Dave did most of the corporate marketing. >=20 > 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".=C2=A0 The advanta= ge of > Hz is that you can directly compare it to framerates of video or > gameplay. >=20 > 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. >=20 > I'm not overly concerned with taking credit for it, though.=C2=A0 I= t's a > reasonably obvious idea to anyone who takes a genuine interest in > this field, and other people did most of the hard work. >=20 > > 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. >=20 > 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: >=20 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 > https://www.ietf.org/archive/id/draft-morton-tsvwg-interflow-intraf= low-delays-00.html > >=20 > 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).=C2=A0 The two > typically differ when the path bottleneck has a flow-isolating > queue, or when the application flow experiences loss and > retransmission recovery. >=20 > I think both measures are important in different contexts.=C2=A0 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.=C2=A0 Network engineers should b= e > 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 controlled by differ= ent > mechanisms - FQ versus AQM - which is why the combination of the tw= o > is so powerful. >=20 > Feel free to use material from the above with appropriate attributi= on. >=20 > =C2=A0- Jonathan Morton >=20 >=20 > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat >=20