From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 087EF21F1E5 for ; Mon, 4 May 2015 05:18:04 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so103208679lbb.3 for ; Mon, 04 May 2015 05:18:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pdMpmLKGfdXeTWpNY850/EFRYpC2UxadaEQQEqwwGjo=; b=iGNmwsBirKDrAesdvmHo9JcUvcuku9reIoK/u8Ed3qcaeCarkwbM8Z9Tek7oJuZYDU aWzUTPvSmZe2ghQShsm3KaGALdHx6r1pg6jSsVyBRA2RRawMg2z0TluTKwRNtKULWUWR W9ybi1bhb3C2uKeVU0urGb3HjF93f860uJKUrW7dZWuzf1sMSApCI+kLg6f4Vs3w78YQ uCWI86vIbZm7pZHpCI6eef9C7jF8UlVK1Imgie3UJ0/CxlZfiV33fPHN+NTtzlmzDEWW T/9SZWw7FF2zX5W9Kx+BOmpZ5ygqdx7VAr2UI6uZV+m0tISYIiWUXeqOp2ZfIHtXdmCz 2Guw== X-Received: by 10.152.43.110 with SMTP id v14mr14766799lal.4.1430741882086; Mon, 04 May 2015 05:18:02 -0700 (PDT) Received: from bass.home.chromatix.fi (87-93-2-196.bb.dnainternet.fi. [87.93.2.196]) by mx.google.com with ESMTPSA id lh8sm3324142lab.30.2015.05.04.05.17.56 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 May 2015 05:18:01 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Jonathan Morton In-Reply-To: <5716B8D7-E2E7-4267-B8F1-9385329222B2@pnsol.com> Date: Mon, 4 May 2015 15:17:47 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <6DD94D01-DA3E-4099-A8CA-99A8C06567BC@gmail.com> References: <72DB0260-F0DF-426F-A3F3-ECF5D8AF228F@pnsol.com> <766042D4-0C90-4C77-9033-07B8E436C35B@pnsol.com> <2F4DCB53-1E46-4829-B2F8-F8131664D1FF@pnsol.com> <0F8CB21C-792F-4F95-BC49-BED3DF0A2100@unimore.it> <5D20E7F1-37D0-4CD3-8793-C29149695C97@pnsol.com> <48540B54-B7B0-428C-BA71-0BA5E40C6FB6@gmail.com> <5716B8D7-E2E7-4267-B8F1-9385329222B2@pnsol.com> To: Neil Davies X-Mailer: Apple Mail (2.2098) Cc: bloat Subject: Re: [Bloat] Detecting bufferbloat from outside a node X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 12:18:33 -0000 > On 4 May, 2015, at 14:39, Neil Davies wrote: >=20 >>> Noting that, delay and loss is, of course, a natural consequence of = having a shared medium >>=20 >> Not so. Delay and loss are inherent to link oversubscription, not to = contention. Without ECN, delay is traded off against loss by the size = of the buffer; a higher loss rate keeps the queue shorter and thus the = induced delay lower. >=20 > Sorry Jonathan - that=92s not what we=92ve observed. We=92ve measured = =93excessive=94 delay on links that are averagely loaded << 0.1% (as = measured over a 15 min period) - I can supply pointers to the graphs for = that.=20 Presumably those would involve oversubscription on short timescales, and = a lot of link idle time between those episodes. One ISP I know of charges by data volume per month, currently in units = of 75GB (minimum 2 per month, so 150GB). This is on ADSL lines where = the link rate might reasonably be 15Mbps or so in the relevant = direction. At that speed, it would take 100,000 seconds to exhaust the = first two units - which is not much more than 24 hours. There is = therefore roughly a 26-fold mismatch between the peak rate available to = the user and the average rate he must maintain to stay within the data = allowance. (I am ignoring small niceties in the calculations here, in favour of = revealing the big picture without too much heavy maths.) By your measure, that would mean that the link could only ever be 3.85% = utilised (1/26th) on month-long timescales, and is therefore = undersubscribed. But I can assure you that, during the small percentage = of time that the link is in active use, it will spend some time at 100% = utilisation on RTT timescales, with TCP/IP straining to achieve more = than that. That is link oversubscription which results in high induced = delay. More precisely, instantaneous link oversubscription results in either = *increasing* induced delay (as the buffer fills) or lost packets (which = *will* happen if the buffer becomes completely full), while = instantaneous link undersubscription results in either *decreasing* = induced delay (as the buffer drains) or link idle periods. = Long-timescale measures of link utilisation are simply averages of these = instantaneous measures. > A single flow can contend the medium just as much as a multiple ones I think here, again, we are using wildly different terminology. There is no contention for the medium on the dedicated full-duplex link = I described, only for queue space - and given a single flow, it cannot = contend with itself. The same goes for a full-duplex shared-access medium (such as DOCSIS = cable) with only one host active. There is no contention for the = medium, because it is always available when that single host requests = it, which it will as soon as it has at least one packet in its queue. = There is a more-or-less fixed latency for medium access, which becomes = part of what you call the structural delay. The rest is down to over- = or under-subscription on short timescales, as above. On a half-duplex medium, such as obsolete bus Ethernet or = not-so-obsolete wifi, then there can be some contention for the medium = between forward data and reverse ack packets. But I was *not* talking = about half-duplex. Full-duplex is an important enough subset of the = problem - covering at least ADSL, cable, VDSL, satellite, fibre - on = which most of the important effects can be observed, including the ones = we=92re talking about. - Jonathan Morton