From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (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 CE36F3B2A4 for ; Mon, 27 Nov 2017 16:49:48 -0500 (EST) Received: by mail-wr0-x233.google.com with SMTP id z75so26547895wrc.5 for ; Mon, 27 Nov 2017 13:49:48 -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:message-id:references :to; bh=lZqDl9GZvhY4PA9tstQ92emonXm8upYjE47vJwYAJlk=; b=m36LH9EtQw47R96RSIkxWraqmtBe9JvAl6hBykU09fiNZXOGXmmx+otlihEHiRsf6R IuR+VxuwUwX9RP6vIuTzxdEXefOZBuxyQIymQNa8tscumVGWiSaCLdTg/oBQj07Y/3nk 1ypfAJsMRe/X6DOunTKVyVRgKctHBH9RAubVbmG3G/YM28Y/UpvAXyszlGmypZcd2TSN TxVQFOBUbCbpXkI4If34X4C60nFWWrUrTfcnl0yuKd7ALzeOXmsJbY/yXqme8ugi7gxS DTlV7WjFZLsX/52oinIG9V2tjMD+8Xa1PFAnEKojYxspJA+5HYzdVDkmNsR3Dyp8QarV tAlg== 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 :message-id:references:to; bh=lZqDl9GZvhY4PA9tstQ92emonXm8upYjE47vJwYAJlk=; b=InA+xOg6UX1hxNv4tw3WMtom4vqXEW7GX3GpF6R6jlbaw3OzO7W1NxbKd8Q5c+azAg niP0gAgYSq+1xQzSX541vz6O6Z/uf9D3yJOCXNBkLdRPgoM9B+8oAQM04MLioFdJgh8/ M/8/Ujffda0+McMx3fOOb2tzEqmWW+/E0jphNRmYrS7iuPJufB7kTQcKlWwFVJHTXohp sE3umRKeLAiLDLgSJKKaykjwGWcKcjT9ppFvT/vDUNIBokf0fy7Asl9Og/AhoO9VHXeN VCkvXcwpXnuj2xXrcOigmfUKednpxONg7rUuiJVEVLSEqWlmXCmLKkoroFakvzu9XkGq sWRA== X-Gm-Message-State: AJaThX6L3uhEqsZE079tBXg6CB7YM7T644vF/nmC7eLFjuCsRpwDrpR/ axCHrtwWRGydA5ZyEs0RcB0= X-Google-Smtp-Source: AGs4zMZaZa1ua2py/PxJDVew5vcSErNy8nyvLNIwW25jbpktFXHmMgccZwMgRUS7npjIZbeBfeq3dw== X-Received: by 10.223.152.234 with SMTP id w97mr27601728wrb.215.1511819387832; Mon, 27 Nov 2017 13:49:47 -0800 (PST) Received: from [10.72.0.130] (h-1169.lbcfree.net. [185.99.119.68]) by smtp.gmail.com with ESMTPSA id 25sm20507871wrv.8.2017.11.27.13.49.46 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 27 Nov 2017 13:49:47 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_7EB9B231-8437-428C-B2FE-82A5539A5E6B" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Pete Heist In-Reply-To: Date: Mon, 27 Nov 2017 22:49:45 +0100 Cc: Sebastian Moeller , Cake List Message-Id: <9F1487EC-5300-4349-AC6B-7B9F7626F08F@gmail.com> 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> To: Jonathan Morton X-Mailer: Apple Mail (2.3124) Subject: Re: [Cake] Recomended HW to run cake and fq_codel? 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: Mon, 27 Nov 2017 21:49:49 -0000 --Apple-Mail=_7EB9B231-8437-428C-B2FE-82A5539A5E6B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 27, 2017, at 7:28 PM, Jonathan Morton = wrote: > 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. 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. > 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). DNS is an interesting possibility. On the one hand all you get is RTT, = but on the other hand your server infrastructure is already available. I = use the dslreports speedtest pretty routinely as it=E2=80=99s decent, = although results can vary significantly between runs. If they=E2=80=99re = using DNS to measure latency, I hadn=E2=80=99t realized it.= --Apple-Mail=_7EB9B231-8437-428C-B2FE-82A5539A5E6B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Nov 27, 2017, at 7:28 PM, Jonathan Morton <chromatix99@gmail.com> wrote:

An important factor when designing the test is = the difference between intra-flow and inter-flow induced latencies, as = well as the baseline latency.

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.

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.

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.

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.

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.

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.

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).

DNS is an interesting possibility. On the one hand all you = get is RTT, but on the other hand your server infrastructure is already = available. I use the dslreports speedtest pretty routinely as it=E2=80=99s= decent, although results can vary significantly between runs. If = they=E2=80=99re using DNS to measure latency, I hadn=E2=80=99t realized = it.
= --Apple-Mail=_7EB9B231-8437-428C-B2FE-82A5539A5E6B--