From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.taht.net (mail.taht.net [IPv6:2a01:7e00::f03c:91ff:feae:7028]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 8AF4E3B29E for ; Tue, 28 Nov 2017 17:41:50 -0500 (EST) Received: from nemesis.taht.net (unknown [IPv6:2603:3024:1536:86f0:2e0:4cff:fec1:1206]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id 24E9A21341; Tue, 28 Nov 2017 22:41:48 +0000 (UTC) From: Dave Taht To: Pete Heist Cc: Jonathan Morton , Cake List References: <7B914FA7-38A6-4113-9B2C-D6246873676A@gmail.com> <1493791193941.83458@telenor.com> <53AFD81B-F9F5-4DE1-A418-A177D0F339E8@gmail.com> <5FD7BE71-CD6B-4C2F-8149-54763F43C519@gmx.de> <4939D5F5-B880-424B-874A-477E75B0D0A1@gmail.com> <9F1487EC-5300-4349-AC6B-7B9F7626F08F@gmail.com> <87mv36p8vs.fsf_-_@nemesis.taht.net> Date: Tue, 28 Nov 2017 14:41:47 -0800 In-Reply-To: (Pete Heist's message of "Tue, 28 Nov 2017 23:14:19 +0100") Message-ID: <87fu8yxbys.fsf@nemesis.taht.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] Simple metrics X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Nov 2017 22:41:50 -0000 Pete Heist writes: >> On Nov 28, 2017, at 7:15 PM, Dave Taht wrote: >>=20 >> Pete Heist writes: >>=20 >>> On Nov 27, 2017, at 7:28 PM, Jonathan Morton = wrote: >>>=20 >>> An important factor when designing the test is the difference between >>> intra-flow and inter-flow induced latencies, as well as the baseline >>> latency. >>>=20 >>> In general, AQM by itself controls intra-flow induced latency, while= flow >>> isolation (commonly FQ) controls inter-flow induced latency. I consi= der the >>> latter to be more important to measure. >>>=20 >>> Intra-flow induced latency should also be important for web page load t= ime and >>> websockets, for example. Maybe not as important as inter-flow, because = there >>> you=E2=80=99re talking about how voice, videoconferencing and other int= eractive apps >>> work together with other traffic, which is what people are affected by = the most >>> when it doesn=E2=80=99t work. >>>=20 >>> I don=E2=80=99t think it=E2=80=99s too much to include one public metri= c for each. People are >>> used to =E2=80=9Cupload=E2=80=9D and =E2=80=9Cdownload=E2=80=9D, maybe = they=E2=80=99d one day get used to =E2=80=9Creactivity=E2=80=9D >>> and =E2=80=9Cinteractivity=E2=80=9D, or some more accessible terms. >>=20 >> Well, what I proposed was using a pfifo as the reference >> standard, and "FQ" as one metric name against pfifo 1000/newstuff.=20 >>=20 >> That normalizes any test we come up with. > > So one could have 6 FQ on the intra-flow latency test and 4 FQ on the int= er-flow latency test, for example, because it=E2=80=99s always a factor of = pfifo 1000=E2=80=99s result on whatever test is run? yep. using 1000 for FIFO queue length also pleases me due to all the academic work at 50 or 100. It would even work for tcp RTT measurement changes, although "FQ" is sort of a bad name here. I'd be up to another name. LQ? (latency quotient). LS (latency stress) > >>> Baseline latency is a factor of the underlying network topology,= and is >>> the type of latency most often measured. It should be measured in the >>> no-load condition, but the choice of remote endpoint is critical. La= rge ISPs >>> could gain an unfair advantage if they can provide a qualifying endp= oint >>> within their network, closer to the last mile links than most realis= tic >>> Internet services. Conversely, ISPs are unlikely to endorse a measur= ement >>> scheme which places the endpoints too far away from them. >>>=20 >>> One reasonable possibility is to use DNS lookups to randomly-selecte= d gTLDs >>> as the benchmark. There are gTLD DNS servers well-placed in essentia= lly all >>> regions of interest, and effective DNS caching is a legitimate means= for an >>> ISP to improve their customers' internet performance. Random lookups >>> (especially of domains which are known to not exist) should defeat t= he >>> effects of such caching. >>>=20 >>> Induced latency can then be measured by applying a load and comparin= g the >>> new latency measurement to the baseline. This load can simultaneousl= y be >>> used to measure available throughput. The tests on dslreports offer = a decent >>> example of how to do this, but it would be necessary to standardise = the >>> load. >>>=20 >>> It would be good to know what an average worst case heavy load is on a = typical >>> household Internet connection and standardize on that. Windows updates = for >>> example can be pretty bad (many flows). >>=20 >> My mental reference has always been family of four - >>=20 >> Mom in a videoconference >> Dad surfing the web >> Son playing a game >> Daughter uploading to youtube >>=20 >> (pick your gender neutral roles at will) >>=20 >> + Torrenting or dropbox or windows update or steam or =E2=80=A6 > > That sounds like a pretty good reasonable family maximum. > >> A larger scale reference might be a company of 30 people. > > I=E2=80=99m only speculating that an average active company user generate= s less traffic than an average active home user, depending on the line of w= ork of course. > > Could there be a single test that=E2=80=99s independent of scale and inte= lligently > exercises the connection until the practical limits of its rrul related > variables are known? I think that=E2=80=99s what would make testing much = easier. I > realize I'm conflating the concept of a simple testing metric with this i= dea.