From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (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 29FB83B25E for ; Sat, 27 Aug 2016 08:16:17 -0400 (EDT) Received: by mail-lf0-x22b.google.com with SMTP id b199so73163359lfe.0 for ; Sat, 27 Aug 2016 05:16:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZHcH1qbNS/g3RdxVS+YS4VODp9jJ96P0dP6ZusgtUUQ=; b=iqyjHoL9q4sDMtsStAI7/mv8pMHb//9BeXZFdIuN45HDmuuJMyvy2AJQrg/KqEQFMB cnw+YPFVaZqQiCUl5FvZOAZoWPwvZH+x0XezJqyXHbWsQBZKcaJgzhEnLYpRZ0E3GQti mxE+bxQIrcXCev1yQavZmeOi1fNsfcRF+mrAmN5BKurGFkb+0tcYp8ujh1iBkNT4raiS pifYHMmWj4pOAb9SyY08kRBF4gXp1ybMtcSJXN0qzrryoKlVySSzPb0m31FKK9eRTDNV 9WjXp8tLGBogYXtLGsT0xiiUiOA/9MEGXY0vjPF5DDiKMeXHfDwu3cGU19c/+wwHZeZ3 4TIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZHcH1qbNS/g3RdxVS+YS4VODp9jJ96P0dP6ZusgtUUQ=; b=TYCaGihi6VxoOiz+mkQgEIQ9k4+tk787bZNOLesr80Tibu0Thf+C6Qhdt78GS4aLMN yABGrJd3MxF+UXCdoQfxcQ6dTh4I2pQV5qjkOqC8vBLz8+Lz5V9Ed57DaC9Tb2uaTPLN hDmXWzizbMT6hqNUdzqlLPEWlWPWrBrQhSB4VtWuU9P/GNbqIW/0Vxrfs2WJs3msK13k woPaBwrgqLsYAfEV8I//o/d2WYjxHgLlj0QBcTKae/GrSPGEhhuo3yorJdsAjghCWUz2 XQTDdBsKjRNpJH4Ym8u/ylAsNwIQAcdVrVjT5JxBtp/8Wlldaz9DTOzGeKzxvFHElXcU 0Oyw== X-Gm-Message-State: AE9vXwOsWuiVoSetPsPwXOVxV2ZxmVDlCQmgeYUUn/UoLw9m+hsRTlnx3Is5mLasDYY8EA== X-Received: by 10.25.15.167 with SMTP id 39mr2545058lfp.196.1472300175727; Sat, 27 Aug 2016 05:16:15 -0700 (PDT) Received: from [192.168.100.13] (37-33-90-35.bb.dnainternet.fi. [37.33.90.35]) by smtp.gmail.com with ESMTPSA id i5sm4743267lfe.40.2016.08.27.05.16.14 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 27 Aug 2016 05:16:14 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jonathan Morton In-Reply-To: Date: Sat, 27 Aug 2016 15:16:08 +0300 Cc: Kathleen Nichols , bloat Content-Transfer-Encoding: quoted-printable Message-Id: <69C777F5-0776-452D-8AE0-4954948FDC2F@gmail.com> References: <0B9BB2F0-611E-4388-8784-0AC71556AB4B@cable.comcast.com> <20160824090847.4e77ce8f@xeon-e3> <1C99BD90-7688-4168-814D-57DA12F0F08C@cable.comcast.com> <90667e99-1334-af36-5879-3b4ed362ed68@pollere.com> To: David Lang X-Mailer: Apple Mail (2.3124) Subject: Re: [Bloat] Open Source Speed Test (was fast.com - Netflix's speed monitoring) 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: Sat, 27 Aug 2016 12:16:17 -0000 > On 27 Aug, 2016, at 04:06, David Lang wrote: >=20 >>> so you can call it large queues instead of large buffers, but the = result >>> is that packets end up being 'in transit' for a long time. >>=20 >> No, a large queue is a bunch of packets waiting in a queue (which is = contained in a buffer). A large buffer with zero or a small number of = packets in it is not going to result in packets being in transit for a = long time. >=20 > Is a large buffer that is never used really a large buffer? or does = whatever prevents it from being used really turn it into a small buffer? > I don't understand what you are trying to call out by trying to change = the terminology. If we=E2=80=99re talking terminology, I think we have to make better = distinctions to avoid confusion. There is a qualitative difference = between a managed queue and both a large and small unmanaged queue; none = of them behave similarly to each other. A managed queue tries to keep itself empty, but does so by means of = congestion signalling (marking or dropping a relatively small proportion = of traffic), rather than placing a hard limit on queue length. It *can* = therefore fill up in various circumstances, including where the traffic = simply ignores those signals, so its *peak* induced delay can be large; = this is true of both flow-isolating and flow-blind queues. However, the = managed queue can achieve lower *average* induced delay than the large = queue, and lower packet loss and higher link utilisation than the small = queue, when given the buffer space of the large queue to work with. Flow-isolation is an orthogonal property here; both managed and = unmanaged implementations exist. A flow-isolating queue aims to keep = the induced delay to sparse flows, which use less than their fair share = of the link, lower than to bulk flows; also to minimise the impact of = unresponsive flows on responsive traffic. The peak induced latency to = any given bulk flow thus becomes less important than the peak induced = latency to sparse flows. With a flow-blind queue, all traffic suffers = the same induced delay at any given moment, so the overall peak induced = latency remains important. Where I think the confusion arises here is between the *capacity* of the = queue, which is static and often large for a managed queue, and the = dynamic *backlog* of that queue, which is what a managed queue attempts = to actively control. In the case of a flow-isolating queue, there is = also a distinction between the overall backlog of the queue, and the = backlog of an individual subqueue. I have noticed that some bufferbloat tests employ an unresponsive = traffic burst as the latency measurement stream - particularly = Netalyzr=E2=80=99s. This does capture the difference between a large = and small capacity queue, but is incapable of detecting AQM or = flow-isolation, which are the preferred solutions to bufferbloat, unless = the AQM is extremely aggressive when faced with unresponsive traffic. A = sufficiently aggressive response to satisfy such a test would however = hurt goodput and packet loss on normal traffic, and would thus be = counterproductive. - Jonathan Morton=