From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (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 E10653B29E; Thu, 16 Feb 2017 15:54:00 -0500 (EST) Received: by mail-wr0-x231.google.com with SMTP id c4so19633356wrd.2; Thu, 16 Feb 2017 12:54:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=Xrx7RklqnbBwN2IBVwBR6NejwAUkd94ztLep8EVGrM4=; b=TkSBNMp9llxywoIM26/hhzGu8HQJ67yxWCPvQsdtVDafOeVSEliPgG2XW7p+osiRDR EMy0tomnQ3MlnHJYRz5Fd8bZIgXNW0/yMR3/uasakyQxYWYjA17rRNb0KYHa++/38LgV C8tELD1xiDOn4V3D8CaypwUASwGBjlup93F2JikUAdteZVyxNH/IUN3lgfBHQ4zStZNd 88PG1gY9ej3k/tj8jXqQfIkqXOeNpDDG8IZjtYCMnvhXatzBX+m5uqlqSIwNTdEocd5E 0fGJRT+sXrSlp5Dd/qcMb/SQyh1BSo1/GdO9Vs8d7JnCjvfRgxMFy2GIco/+vGln04Qy MAYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Xrx7RklqnbBwN2IBVwBR6NejwAUkd94ztLep8EVGrM4=; b=dx+QBrWG9KdO/ytrymhMWBFsGxTv+jSkqZmNBm0Bx8fn7PB9Aok+aTtkeElVu5y2Nj pKDvMhmmoDkvL79j0liy+8W55HSHAVpVXdoNiz4dwjuX5USPoOqO1ADWbrHXhDbIzsaG TiFbYnXAepek/WvUhUFGdMdltsTifwqF9f8raw6SiKxwvrUomuACzN5Nbh+gyqhRIeMM WDjbnpD8isxl453qIRHxGQ9tw7qAguweOOzw6yqpsnx8mB563eihgbwtb/Q08ENkstHZ mJTo42/bHXmT/pxMs/v0fmUCJIkyU2i/+CHIhgB6Wsj8Co63uJxR3K/VhDgN7z3BuDIB Lpag== X-Gm-Message-State: AMke39l9i8ZX+MvM6Rdu7fn7nUyH34lfxWI8tLE48f+GGfXsSN8IISfyvWwHtrKgA0j4TQ== X-Received: by 10.223.171.12 with SMTP id q12mr3805684wrc.74.1487278439881; Thu, 16 Feb 2017 12:53:59 -0800 (PST) Received: from [10.72.0.34] (h-1169.lbcfree.net. [185.99.119.68]) by smtp.gmail.com with ESMTPSA id c57sm3428173wra.47.2017.02.16.12.53.58 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 16 Feb 2017 12:53:59 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_C74EFB0B-17CB-4DC4-844F-F64DE1EF0CFE" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Pete Heist In-Reply-To: <0695D23F-B286-4E5D-ABA5-78AB16FAA5DE@gmail.com> Date: Thu, 16 Feb 2017 21:54:20 +0100 Cc: Sebastian Moeller , Aaron Wood , cake@lists.bufferbloat.net, make-wifi-fast@lists.bufferbloat.net Message-Id: <70D9E83A-CC7D-48C0-9D5F-B037B1CA7113@gmail.com> References: <32C42951-373F-4D90-8936-AA07039E5D73@gmail.com> <877f5c2pew.fsf@toke.dk> <42AC44CD-8C22-4EBC-B6AB-7786BA505D07@gmail.com> <35E83BE1-73D8-4FF9-B2E8-A49073E67EBA@gmail.com> <83F97E77-3CCD-44B2-B9EB-7F34DA3A3A50@gmail.com> <0695D23F-B286-4E5D-ABA5-78AB16FAA5DE@gmail.com> To: Jonathan Morton X-Mailer: Apple Mail (2.3124) Subject: Re: [Make-wifi-fast] [Cake] Flent results for point-to-point Wi-Fi on LEDE/OM2P-HS available X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 20:54:01 -0000 --Apple-Mail=_C74EFB0B-17CB-4DC4-844F-F64DE1EF0CFE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 16, 2017, at 8:05 PM, Pete Heist wrote: >=20 >>=20 >> On Feb 16, 2017, at 6:19 PM, Jonathan Morton > wrote: >>=20 >>> On 16 Feb, 2017, at 18:51, Pete Heist > wrote: >>>=20 >>> At first I was thinking to just remove diffserv markings entirely, = say with Cake=E2=80=99s besteffort flag, but I think that =E2=80=9Cgood=E2= =80=9D and =E2=80=9Cotherwise unknowing=E2=80=9D users would suffer, = which I think in FreeNet is a vast majority of users. >>=20 >> That=E2=80=99s not what the =E2=80=9Cbesteffort=E2=80=9D flag does. = It ignores DSCPs and puts all traffic into a single tin, but doesn=E2=80=99= t remove the DSCP marking. >=20 > Thanks, I had mixed this with =E2=80=9Csquash=E2=80=9D. >=20 >>>> In a sense if there are thresholds for permissible VO/VI traffic = fractions below which the AP will not escalate its own priority this = will come close to throttling the high priority senders, no?=20 >>>=20 >>> I thought Aaron=E2=80=99s suggestion sounds both sensible and not = difficult to implement. That way we wouldn=E2=80=99t even have to = regularly monitor it, and anyone who is marking all their packets = thinking they=E2=80=99re doing themselves a favor is just limiting their = max throughput. >>>=20 >>> Could there be another keyword in Cake to do this automatically, say = =E2=80=9Cfairdiffserv", or would this just be feature bloat for what is = already a sophisticated shaper? I don=E2=80=99t know if there are = sensible mappings from dscp value to max percentage throughput that = would work most of the time, or if there could also be an adjustable = curve parameter that controls the percentage backoff as you go up dscp = levels. >>=20 >> This is actually what Cake already does by default (the = =E2=80=9Cdiffserv3=E2=80=9D mode). If you look at the detailed = statistics (tc -s qdisc), you=E2=80=99ll see that each tin has a = =E2=80=9Cthreshold=E2=80=9D bandwidth. If there=E2=80=99s more traffic = than that threshold in that tin, the tin will be deprioritised - it can = still use all of the bandwidth left spare by other tins=E2=80=99 = traffic, but no more than that. >>=20 >> Additionally, diffserv3 mode uses more aggressive AQM settings on the = =E2=80=9Cvoice=E2=80=9D tin than the =E2=80=9Cbest effort=E2=80=9D tin, = on the grounds that the former is a request for minimum latency. This = should also discourage bulk traffic from using unnecessarily high DSCPs. >>=20 >> However, in both the =E2=80=9Cbesteffort=E2=80=9D and =E2=80=9Cdiffserv= 3=E2=80=9D cases, the DSCP may be interpreted independently by the NIC = as well as Cake. In the case of wifi, this affects the medium grant = latency and priority. If the link isn=E2=80=99t saturated, this = shouldn=E2=80=99t affect Cake=E2=80=99s prioritisation strategy much if = at all, but it does have implications for the effect of other stations = sharing the frequency. >=20 > Aha, that sounds like just what we need as far as diffserv is = concerned! I=E2=80=99ll punt on trying to understand what that means for = Wi-Fi just yet, but will come back to it. >=20 > Even though I=E2=80=99m sticking to point-to-point Wi-Fi, I would like = to use Cake if possible since we=E2=80=99re shaping on external routers, = so I=E2=80=99m testing it more extensively (especially vs sfq since = that=E2=80=99s what=E2=80=99s in use now) and will add to my tests: >=20 > - diffserv markings (=E2=80=98rrul=E2=80=99, where so far I=E2=80=99ve = done only =E2=80=98rrul_be=E2=80=99 for simplicity to get my test setup = verified) > - flow isolation (triple-isolate), by simulating P2P-like flows, maybe = with Flent=E2=80=99s rrul_torrent somehow, also on multiple IPs? Will = figure it out. > - VoIP (if I can get d-ITG working finally) >=20 > This reminds me, I found this location for the latest Cake man page = and finally read it in detail, as I should have earlier: >=20 > http://static.lochnair.net/bufferbloat/tc-cake.8.html = >=20 > 1) Should I be using the Ethernet keyword when running Cake on routers = connected to the AP (or station) via Ethernet? And overheads for Wi-Fi = also, is that even possible to get right, or if not, what=E2=80=99s = closest? >=20 > 2) Is there a more official link for the man page? The one installed = with the source from here (git://kau.toke.dk/cake/iproute2/ = ) seems older. >=20 > Thanks for taking the time to explain! 3) And a followup question from this statement on the man page: "CAKE can divide traffic into "tins" based on the Diffserv field. Each = tin has its own independent set of flow-isolation queues, and is = serviced based on a WRR algorithm. To avoid perverse Diffserv marking = incentives, tin weights have a "priority sharing" value when bandwidth = used by that tin is below a threshold, and a lower "bandwidth sharing" = value when above. =E2=80=9C If each diffserv tin has its own flow isolation queues, doesn=E2=80=99t = that mean (if this is run on a backhaul router) that if one host is = abusing the VoIP diffserv marking, for example, that they=E2=80=99ll = impact other users by using up the bandwidth in the tin?= --Apple-Mail=_C74EFB0B-17CB-4DC4-844F-F64DE1EF0CFE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Feb 16, 2017, at 8:05 PM, Pete Heist <peteheist@gmail.com>= wrote:


On = Feb 16, 2017, at 6:19 PM, Jonathan Morton <chromatix99@gmail.com> wrote:

On 16 = Feb, 2017, at 18:51, Pete Heist <peteheist@gmail.com> wrote:

At first I was thinking to just remove diffserv markings = entirely, say with Cake=E2=80=99s besteffort flag, but I think that = =E2=80=9Cgood=E2=80=9D and =E2=80=9Cotherwise unknowing=E2=80=9D users = would suffer, which I think in FreeNet is a vast majority of users.

That=E2=80=99s not what the = =E2=80=9Cbesteffort=E2=80=9D flag does.  It ignores DSCPs and puts = all traffic into a single tin, but doesn=E2=80=99t remove the DSCP = marking.

Thanks, I had mixed this with = =E2=80=9Csquash=E2=80=9D.

In a sense if there are = thresholds for permissible VO/VI traffic fractions below which the AP = will not escalate its own priority this will come close to throttling = the high priority senders, no? 

I thought Aaron=E2=80=99s = suggestion sounds both sensible and not difficult to implement. That way = we wouldn=E2=80=99t even have to regularly monitor it, and anyone who is = marking all their packets thinking they=E2=80=99re doing themselves a = favor is just limiting their max throughput.

Could there be another keyword in Cake to do this = automatically, say =E2=80=9Cfairdiffserv", or would this just be feature = bloat for what is already a sophisticated shaper? I don=E2=80=99t know = if there are sensible mappings from dscp value to max percentage = throughput that would work most of the time, or if there could also be = an adjustable curve parameter that controls the percentage backoff as = you go up dscp levels.

This is = actually what Cake already does by default (the =E2=80=9Cdiffserv3=E2=80=9D= mode).  If you look at the detailed statistics (tc -s qdisc), = you=E2=80=99ll see that each tin has a =E2=80=9Cthreshold=E2=80=9D = bandwidth.  If there=E2=80=99s more traffic than that threshold in = that tin, the tin will be deprioritised - it can still use all of the = bandwidth left spare by other tins=E2=80=99 traffic, but no more than = that.

Additionally, diffserv3 mode uses = more aggressive AQM settings on the =E2=80=9Cvoice=E2=80=9D tin than the = =E2=80=9Cbest effort=E2=80=9D tin, on the grounds that the former is a = request for minimum latency.  This should also discourage bulk = traffic from using unnecessarily high DSCPs.

However, in both the =E2=80=9Cbesteffort=E2=80=9D and = =E2=80=9Cdiffserv3=E2=80=9D cases, the DSCP may be interpreted = independently by the NIC as well as Cake.  In the case of wifi, = this affects the medium grant latency and priority.  If the link = isn=E2=80=99t saturated, this shouldn=E2=80=99t affect Cake=E2=80=99s = prioritisation strategy much if at all, but it does have implications = for the effect of other stations sharing the frequency.

Aha, that sounds like just what we need as far as diffserv is = concerned! I=E2=80=99ll punt on trying to understand what that means for = Wi-Fi just yet, but will come back to it.

Even though I=E2=80=99m sticking to = point-to-point Wi-Fi, I would like to use Cake if possible since we=E2=80=99= re shaping on external routers, so I=E2=80=99m testing it more = extensively (especially vs sfq since that=E2=80=99s what=E2=80=99s in = use now) and will add to my tests:

- diffserv markings (=E2=80=98rrul=E2=80=99= , where so far I=E2=80=99ve done only =E2=80=98rrul_be=E2=80=99 for = simplicity to get my test setup verified)
- flow isolation (triple-isolate), by = simulating P2P-like flows, maybe with Flent=E2=80=99s rrul_torrent = somehow, also on multiple IPs? Will figure it out.
- VoIP (if I can get d-ITG working = finally)

This = reminds me, I found this location for the latest Cake man page and = finally read it in detail, as I should have earlier:

http://static.lochnair.net/bufferbloat/tc-cake.8.html
=

1) = Should I be using the Ethernet keyword when running Cake on routers = connected to the AP (or station) via Ethernet? And overheads for Wi-Fi = also, is that even possible to get right, or if not, what=E2=80=99s = closest?

2) Is = there a more official link for the man page? The one installed with the = source from here (git://kau.toke.dk/cake/iproute2/) seems older.

Thanks for taking the time to = explain!

3) And a followup question from this = statement on the man page:

"CAKE can divide traffic into "tins" based on the Diffserv = field. Each tin has its own independent set of flow-isolation queues, = and is serviced based on a WRR algorithm. To avoid perverse = Diffserv marking incentives, tin weights have a "priority sharing" value = when bandwidth used by that tin is below a threshold, and a lower = "bandwidth sharing" value when above. =E2=80=9C

If each diffserv tin has its own flow = isolation queues, doesn=E2=80=99t that mean (if this is run on a = backhaul router) that if one host is abusing the VoIP diffserv marking, = for example, that they=E2=80=99ll impact other users by using up the = bandwidth in the tin?
= --Apple-Mail=_C74EFB0B-17CB-4DC4-844F-F64DE1EF0CFE--