From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 9F4773B29E for ; Tue, 28 Nov 2017 17:14:23 -0500 (EST) Received: by mail-wm0-x232.google.com with SMTP id i11so2355633wmf.4 for ; Tue, 28 Nov 2017 14:14:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mEFad/B3N9jW3e4cr5kd++84yd0jwKhCr1bodg/foBI=; b=EpS738+5IQhkKm55/amuKq6ETFmt1XxYF9rpyciLrQw16YUJAwFjxUQCeh86lx7JJj wc+tnJnOvleZ5mfUG5ncHRPmRo+l0HY+kTpsWC7BbECShwO3IUQQkkM7naUVq+o0BT1a cb56D00fszOCBy7HTcBiPUL3rFlAE/45QGREgM1u47GxKiHiaIhDlQ+ziwjPQsgShs5b bzs0pzR8/XRP+GLk0ZhxmjBVzC0k8SdrlwD63IHZIivOrsY7tYXwmTuLdEEb6f1OwE9n 89MhtjikvlnoBECcvIJzFfZjzkAD16xXIfsjSEoap2KZ+0Vtva0xhXYQZJeJZ4F7Dh6Y OKKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mEFad/B3N9jW3e4cr5kd++84yd0jwKhCr1bodg/foBI=; b=gyeWM+v/c2ZA7KCS3tfmG1bivd/JFLnrvYrSzWOe7yDvvRuujT/WfFkKOMdyTR6DQO Q8jLrpwiIozQNF7f5pj+8AKhxbUodkv6yqkI8MO608cZLXJ8wGM9kBkwCzEBlkxdSdRS rzZ+133U6xmHmxdoLFg0zlXmsUHrtdl5+evR7OBKfEI/ujn4yWNphUwPVuw3CxIFOMuD Mhfz2iTEY0zE9sqQUxTGlwzonai2qNkJCsfmxSGdvGjJAi4yFdro0HQJS0dl9SC9g+N+ PBKYe2wWmhVfotCa3RwH9eMNj9eXKOxzTx2j+H4epscuSmCvX8KT/RdsjmAA8qGzo1wg V8jQ== X-Gm-Message-State: AJaThX4dj3WRtos99h+VTyNYoMFrOGZnGGHu8L6nYAYZuXbv5YVEfOzD HWRnaYmrNAibF21gjNaH6uk= X-Google-Smtp-Source: AGs4zMbbQLk7XPdAEHPwO0JZE25iyzBPAx2FokM9lnFgmP+u2aTmfMuOd5I32Fz+QJmQjLwEZDa+Mg== X-Received: by 10.28.127.22 with SMTP id a22mr800021wmd.12.1511907262652; Tue, 28 Nov 2017 14:14:22 -0800 (PST) Received: from [10.72.0.130] (h-1169.lbcfree.net. [185.99.119.68]) by smtp.gmail.com with ESMTPSA id c54sm389342wra.84.2017.11.28.14.14.21 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 28 Nov 2017 14:14:21 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Pete Heist In-Reply-To: <87mv36p8vs.fsf_-_@nemesis.taht.net> Date: Tue, 28 Nov 2017 23:14:19 +0100 Cc: Jonathan Morton , Cake List Content-Transfer-Encoding: quoted-printable Message-Id: 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> To: Dave Taht X-Mailer: Apple Mail (2.3124) 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:14:23 -0000 > 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. 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? >> 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 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 = generates less traffic than an average active home user, depending on = the line of work of course. 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.=