From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 75AEC3B29E for ; Wed, 29 Nov 2017 03:08:56 -0500 (EST) Received: from [192.168.250.101] ([134.76.241.253]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MbxJ8-1eZq9A0t1i-00JNYM; Wed, 29 Nov 2017 09:08:54 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sebastian Moeller In-Reply-To: <87fu8yxbys.fsf@nemesis.taht.net> Date: Wed, 29 Nov 2017 09:08:45 +0100 Cc: Pete Heist , Cake List Content-Transfer-Encoding: quoted-printable Message-Id: <3EC16495-43FE-4B26-9D21-17A2BA7D7186@gmx.de> 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> <87fu8yxbys.fsf@nemesis.taht.net> To: Dave Taht X-Mailer: Apple Mail (2.3273) X-Provags-ID: V03:K0:D4TqmfSKQGu5ZOQ74ZLPHrQOuiZYvV4528wCVDk5ivSjIal/gkc Y1pKLr/29lvWTWlLxJhMzp56ifLeJhVjl4aERlb3uE+vE0aOtJwJGXCSfLLvpZvrYOYBq2A MJM2qreRreTdxHdqz45ZnP3+7ECOHt6qgHcoQACtpt0+M1yPWWz/HmrGb8ZlncFNz9/Tei4 B0pvVn58fEv7EnVJYRXog== X-UI-Out-Filterresults: notjunk:1;V01:K0:qep/vLHCfTs=:g+hRYqe8bVFK6pVJgCUFU4 fGf8o47CVNJIiDfU+33xv9f6GClAZapSRfXzLoR5U+iwwEIWJvL/mrEwvW0aSEhbFT/2lzJ/o TwyH/1OxXS5f0I1yJXdIRuv2jHao+AfbTuePLBCqfq+wSiCE+xC4qCgDbHotknBm7hgHeDlyk t5aWIFnozcbRfLapO3SPUYyfVHeoPLuwpANMLB0BDWYtf7B4XnTbyCkl6ipuDdPMEN5NUb3w8 rlNPFa6cD5YFbQY4u+w9WqmAK/mWAV+DKr1kX+3vhhfNzyGlivvkrTHMHieKuHsx+0MASr9nP +cJNHQudUAcwvWNfuGpwk26thOXZVpSesaCX9tLtsen3j3KZpXg8yj64jXArtT1OQADG8ElGq scZkT1UX4e6vaLVat9AbVEafV8RhL3slk1GE2eqwrcQnwAPmuTpistQeNKtzSPqQP6YJLaPnq BgIssLj0te6abGTsJOhh5g0S/77iwPim/PNfhSHel62zKr1gdGbUnFj46C2B+LBGVivIw+8cO xk+jsDoFcDwEqbWYxd9x99fSyfb37JhClHKA+6Ea9GeVjf27zOrXIiQKbWON6vYb0G587Ywnw 9mP4o6ttibVdPlje7XKKL3h10o86U2aiRxSXJQMdqJ3yRKdxc4DSPC9/X/PqlFT56rKns6VBl 4vEiAStcZO0o/qon3VjMDTGhIgAjyISb8LaepHYaFaSPAGnFqS7FtqvGVroy8P/xaE+UdCv8A lXnmxpQVsaOjutEWEQEH+5M8LKm5lK8VPCut5YkQv3yMbinMinYNlj1SeHMiNgs/UaX1liSfA Eo8p9waREQ2EO5t+0HMQ9JBWV7PBCMm16unv9gif06Ct53qC1YYTp5ycyE5tb//Hs5YHY7K 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: Wed, 29 Nov 2017 08:08:56 -0000 I know I am simple minded, but still... I think that giving the RTT = increase incurred on a sparse flow during full up- and downstream = saturation seems the rawest and most useful; I guess one would need to = select the number of concurrent flows and define sparseness. This will = show the effect of fair queueing quite nicely and will have immediate = relevant information for gamers; how much "lag" does the internet link = add. I simply assume that for latency improvements FPS player might be = our best hope to popularize the concept. Nothing against a ratio or a = quotient, but honestly fractions are not intuitively understood by most = people (that is, without actually thinking about them). Best Regards Sebastian > On Nov 28, 2017, at 23:41, Dave Taht wrote: >=20 > Pete Heist writes: >=20 >>> 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 = consider the >>>> latter to be more important to measure. >>>>=20 >>>> Intra-flow induced latency should also be important for web page = load time and >>>> websockets, for example. Maybe not as important as inter-flow, = because there >>>> you=E2=80=99re talking about how voice, videoconferencing and other = interactive 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 = metric 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. >>=20 >> So one could have 6 FQ on the intra-flow latency test and 4 FQ on the = inter-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? >=20 > yep. using 1000 for FIFO queue length also pleases me due to all the > academic work at 50 or 100. >=20 > 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) >=20 >=20 >>=20 >>>> 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. = Large ISPs >>>> could gain an unfair advantage if they can provide a qualifying = endpoint >>>> within their network, closer to the last mile links than most = realistic >>>> Internet services. Conversely, ISPs are unlikely to endorse a = measurement >>>> scheme which places the endpoints too far away from them. >>>>=20 >>>> One reasonable possibility is to use DNS lookups to = randomly-selected gTLDs >>>> as the benchmark. There are gTLD DNS servers well-placed in = essentially 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 the >>>> effects of such caching. >>>>=20 >>>> Induced latency can then be measured by applying a load and = comparing the >>>> new latency measurement to the baseline. This load can = simultaneously 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 >>=20 >> That sounds like a pretty good reasonable family maximum. >>=20 >>> A larger scale reference might be a company of 30 people. >>=20 >> I=E2=80=99m only speculating that an average active company user = generates less traffic than an average active home user, depending on = the line of work of course. >>=20 >> Could there be a single test that=E2=80=99s independent of scale and = intelligently >> 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 idea. > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake