From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::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 EDD4321F29F for ; Mon, 4 May 2015 04:33:38 -0700 (PDT) Received: by labbd9 with SMTP id bd9so101893574lab.2 for ; Mon, 04 May 2015 04:33:36 -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=rE1bKCJ5Ht9lFa8CR4oS+OrxGt6EkGrS3HKZ5HGWFH0=; b=FY5xmtT4sun7F3qE9bp/ebnGirOhjBUMd7e/yOZ8nNirhZ6Zh8aOfm2IrPzzoNwQ1d c/XwOLtvBPXuBqZtoNpVrOOYbwMwUDwrvdA1C2iD+wGbKTpx0hy7TyasnyDQs6JCwka/ h7aW/nAjC7P/qoqPtNjHqwlhh2RYjnlSNX/nPPtPiSyfKclbMyxOvT/AzWZsOL0MZU22 oV5ptYm3ATRyKgkp9E679TRu2on5L+DYZlwtjYUSbP0RJGCwikYu/Rx25r3h/8ay47ns OPicXNF/TVRr4ISSdqeYP/prJwO3xlj3xyXjfjDEocjw9/hD09LEB2yHfqqY2D92HQ5T MakA== X-Received: by 10.152.3.97 with SMTP id b1mr19643935lab.54.1430739216204; Mon, 04 May 2015 04:33:36 -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 at2sm3301110lbc.12.2015.05.04.04.33.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 May 2015 04:33:35 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Jonathan Morton In-Reply-To: <5D20E7F1-37D0-4CD3-8793-C29149695C97@pnsol.com> Date: Mon, 4 May 2015 14:33:26 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <48540B54-B7B0-428C-BA71-0BA5E40C6FB6@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> 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 11:34:08 -0000 X-List-Received-Date: Mon, 04 May 2015 11:34:08 -0000 > 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 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. 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. 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. 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. Of course, loss can also be caused by poor link quality, but that=E2=80=99= s an entirely separate problem. - Jonathan Morton