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 91F5521F1D2; Mon, 18 May 2015 08:04:16 -0700 (PDT) Received: by lagv1 with SMTP id v1so224594620lag.3; Mon, 18 May 2015 08:04:10 -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=3ecdjlRKzYx1ZOjzLvSvHD6J4mkt7WIU3pH2sXA+njA=; b=iDtfsbwY0Tuy2No5Feflzd4jfoWK0m3iZKyoA9jewNmkFD2ZJF5SZX6uwW4Qog4EDX QqG3RxDCv957lFcwesrUmVxuNWI0qDnBKg1L4clZuMiimKh5n/iTlaqkI2UtTjwipKCV a0XdOtS38medHqqiI8YF5jiNpPQmCbcKeR9ZG76OUE114kkmYaXpvYWpQ2MNqxfoxNNg GHCuB5TgYWWGD7w8P2xHX/ibS0/EWqmRkTlbJ9Eu2MDFTq6uCw5AnuFuI18jaV6kXVh7 9Ir6TjIndhKJV+qXwqnRwlm4RXrFRg5DelylCbrjsiXtw4I9Q9hdhlAUzM9Z75Jak4bz ee7w== X-Received: by 10.152.4.72 with SMTP id i8mr18209662lai.32.1431961450072; Mon, 18 May 2015 08:04:10 -0700 (PDT) Received: from bass.home.chromatix.fi (37-136-63-124.rev.dnainternet.fi. [37.136.63.124]) by mx.google.com with ESMTPSA id 4sm2755739lai.36.2015.05.18.08.03.51 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 May 2015 08:04:09 -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: <14d67011de0.27f7.e972a4f4d859b00521b2b659602cb2f9@superduper.net> Date: Mon, 18 May 2015 18:03:45 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <73098C19-53F3-4638-BA7A-D335BF2D26A1@gmail.com> References: <8C015B1B-EFBA-4647-AD83-BAFDD16A4AF2@netapp.com> <14d5800ec08.27f7.e972a4f4d859b00521b2b659602cb2f9@superduper.net> <1431919815.385726792@apps.rackspace.com> <55597353.2010408@superduper.net> <14d67011de0.27f7.e972a4f4d859b00521b2b659602cb2f9@superduper.net> To: Simon Barber X-Mailer: Apple Mail (2.2098) Cc: "Klatsky, Carl" , cake@lists.bufferbloat.net, "Eggert, Lars" , cerowrt-devel@lists.bufferbloat.net, bloat Subject: Re: [Cerowrt-devel] [Bloat] heisenbug: dslreports 16 flow test vs cablemodems X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 15:05:10 -0000 X-List-Received-Date: Mon, 18 May 2015 15:05:10 -0000 X-List-Received-Date: Mon, 18 May 2015 15:05:10 -0000 X-List-Received-Date: Mon, 18 May 2015 15:05:10 -0000 X-List-Received-Date: Mon, 18 May 2015 15:05:10 -0000 > On 18 May, 2015, at 15:30, Simon Barber wrote: >=20 > implementing AQM without implementing a low priority traffic class = (such as DSCP 8 - CS1) will prevent solutions like LEDBAT from working I note that the LEDBAT RFC itself points out this fact, and also that an = AQM which successfully =E2=80=9Cdefeats=E2=80=9D LEDBAT in fact achieves = LEDBAT=E2=80=99s goal (it=E2=80=99s in the name: Low Extra Delay), just = in a different way. There=E2=80=99s a *different* reason for having a =E2=80=9Cbackground=E2=80= =9D traffic class, which is that certain applications use multiple = flows, and thus tend to outcompete conventional single-flow = applications. Some of these multiple-flow applications currently use = LEDBAT to mitigate this effect, but in an FQ environment (not with pure = AQM!) this particular effect of LEDBAT is frustrated and even reversed. That is the main reason why cake includes Diffserv support. It allows = multiple-flow LEDBAT applications to altruistically move themselves out = of the way; it also allows applications which are latency-sensitive to = request an appropriate boost over heavy best-effort traffic. The trick = is arrange such boosts so that requesting them doesn=E2=80=99t give an = overwhelming advantage to bulk applications; this is necessary to avoid = abuse of the Diffserv facility. I think Cake does achieve that, but some day I=E2=80=99d like some data = confirming it. A test I happened to run yesterday (involving 50 uploads = and 1 download, with available bandwidth heavily in the download=E2=80=99s= favour) does confirm that the Diffserv mechanism does its job properly = when asked to, but that doesn=E2=80=99t address the abuse angle. NB: the abuse angle is separate from the attack angle. It=E2=80=99s = always possible to flood the system in order to degrade service; = that=E2=80=99a an attack. Abuse, by contrast, is gaming the system to = gain an unfair advantage. The latter is what cake=E2=80=99s traffic = classes are intended to prevent, by limiting the advantage that = misrepresenting traffic classes can obtain. If abuse is inherently = discouraged by the system, then it becomes possible to *trust* DSCPs to = some extent, making them more useful in practice. For some reason, I haven=E2=80=99t actually subscribed to IETF AQM yet. = Perhaps I should catch up. - Jonathan Morton