From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-f97.google.com (mail-la0-f97.google.com [209.85.215.97]) (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 2419521F29F for ; Mon, 4 May 2015 04:38:03 -0700 (PDT) Received: by labmn9 with SMTP id mn9so2870837lab.0 for ; Mon, 04 May 2015 04:38:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=BlvWYcxJYQwGIgEaJ3Z2LT4URzePtipyvInVUfzcsak=; b=b+oBtVewhU+gGxF3gVUE6lRKwtobkkxsuAmjGqHwIs7MJSCNCsClnYll9QHJ8mkloI DtrsvCOF1PIwdanDMjHLBjiC7fkCAHkIHUbrpt8L23ymu0BZWmNbits7zF01SaSSHsIG nETfHrxOWR3McGINsSRe/uYO1GlZxFKCqvMWM644WhPn8iVyEbFOzQytsuvMlN6SjBS7 O5pQhEVhTH6i6zUVSLQ3Obyp8FnTa2pI9fIRx4+OTVBdkgRr8BlSqXJd+pqoQHFuscY1 lM4k2HvSdQkinJQ93rX1W9a5JuDN8+aDzwXEjEjA7qzVP+OOyB3UFkUVPa4/GcuyaLlq LDMA== X-Gm-Message-State: ALoCoQkbLBe++ooSMpq/0NU/hdPpzerW/wx/+G1QBs4H2HtmDdyhHyEGztCgl7RuWyOmYPWEb/b+UpeBsqKiPgxEGoY6EsBjSA== X-Received: by 10.180.109.136 with SMTP id hs8mr18551201wib.73.1430739481625; Mon, 04 May 2015 04:38:01 -0700 (PDT) Received: from mail.la.pnsol.com (eu1sys200aog128.obsmtp.com. [207.126.144.178]) by mx.google.com with SMTPS id bl4sm657056wjb.4.2015.05.04.04.38.00 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 04 May 2015 04:38:01 -0700 (PDT) X-Relaying-Domain: pnsol.com Received: from mail.la.pnsol.com ([89.145.213.110]) (using TLSv1) by eu1sys200aob128.postini.com ([207.126.147.11]) with SMTP ID DSNKVUdaF+92ewoUflQ5Hnff34dp4SefcYGO@postini.com; Mon, 04 May 2015 11:38:00 UTC Received: from ba6-office.pnsol.com ([172.20.5.199]) by mail.la.pnsol.com with esmtp (Exim 4.76) (envelope-from ) id 1YpEh3-00071T-UP; Mon, 04 May 2015 12:37:49 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Neil Davies In-Reply-To: <48540B54-B7B0-428C-BA71-0BA5E40C6FB6@gmail.com> Date: Mon, 4 May 2015 12:39:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5716B8D7-E2E7-4267-B8F1-9385329222B2@pnsol.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> To: Jonathan Morton X-Mailer: Apple Mail (2.1878.6) 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 11:38:32 -0000 On 4 May 2015, at 12:33, Jonathan Morton wrote: >=20 >> On 4 May, 2015, at 13:42, 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. 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 >=20 > You can have just as much delay and loss in a single flow on a = dedicated, point-to-point, full-duplex link (in other words, one that is = *not* a shared medium) as on the same link with multiple flows = contending for it. A single flow can contend the medium just as much as a multiple ones - = it is the total arrival pattern that is important, which may be related = to the number of flows (in that there is more freedom in the system). >=20 > Conversely, we can demonstrate almost zero flow-to-flow induced delay = and zero loss by adding AQM, FQ and ECN, even in a fairly heavy = multi-flow, multi-host scenario. >=20 > AQM with ECN solves the oversubscription problem (send rates will = oscillate around the true link rate instead of exceeding it), without = causing packet loss (because ECN can signal congestion instead), and FQ = further reduces the most easily perceived delay (ie. flow-to-flow = induced) as well as improving fairness. >=20 > Of course, loss can also be caused by poor link quality, but that=92s = an entirely separate problem. It is a separate cause, agreed, but it has a similar effect... >=20 > - Jonathan Morton >=20