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 E9E5A3B29E; Thu, 16 Feb 2017 14:05:03 -0500 (EST) Received: by mail-wr0-x231.google.com with SMTP id z61so18158685wrc.1; Thu, 16 Feb 2017 11:05:03 -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=HKa2UcDsH9oOmPPoxaffAAiiwUCv6jaO7mCdPtFI4k8=; b=P2OuUF3AVrEhwZHeg6i3g700BM8Zk7DUb2AvSxHTOM4ZuS9PIg8kzJAXLM2wYc/gQG 2GZfPd7j85aIE9QfsNTZeHCEgWE9VFrNXMSnhWZqf7unDvhTGg0Wn/tnQ8mPYlznDGOH locUqv+FbaRgQV4H1yTw8VqcoPPvVemUnLZSJ4QWjV1d/pLHTIxCpy6FENmXXsOhShvf qz5g2u8xaclVfkMQUMJp45Jb2xaLolteqeoK2UF1y0oMeKuP1vNb2VAY5j1Imk+MGKmM Cp1kMfZdI0nHbMBGX9VlQU9War/UsknfoYYbtmPMnl+gjTYzSKRZN8MYl7zaWzXCwknD isNQ== 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=HKa2UcDsH9oOmPPoxaffAAiiwUCv6jaO7mCdPtFI4k8=; b=Ix1UxW3Gm50Pw08OdRUE7MhhWqpJjF1iViZ5U3ghTa5gYl0SXNOH8EBse7tkSlbiSz yQRDUfg3Y3iqfL/PXXlos2qiEySXhVKYP8B6Xk9Ibkcj0h4YON8a5CBm8J8YczcUPXBB 4mbgc90zGKL+kvGGjvyUYjUZxjQ5qe/ZnilVG++gZlWVVdbzqppYDZL8qxay8Evs1gfT F6YrbuqOU9lz4kR5eGKotdIrspBMLBHv/eHFOnOTdjiqHYZPWAgdAe7mUjjJvxei3q9n hEB2jQDRv465SZ2C6f88+BXjtKMleDD9UrW/94i7SYXEfsHK+n8HglAocpI200Re6tKm jguA== X-Gm-Message-State: AMke39nK4aGHZcc8ANPeqbWE+HnLOSG9Pl/KdLGCiL1WWLtaNiyJVtBI0lTBccmHmFi0wQ== X-Received: by 10.223.141.229 with SMTP id o92mr3926903wrb.22.1487271902133; Thu, 16 Feb 2017 11:05:02 -0800 (PST) Received: from [10.72.0.34] (h-1169.lbcfree.net. [185.99.119.68]) by smtp.gmail.com with ESMTPSA id x25sm10087624wrx.27.2017.02.16.11.05.00 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 16 Feb 2017 11:05:01 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_BDA4D8BA-DAFC-45BA-95E1-C7BC53E8825F" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Pete Heist In-Reply-To: <83F97E77-3CCD-44B2-B9EB-7F34DA3A3A50@gmail.com> Date: Thu, 16 Feb 2017 20:05:21 +0100 Cc: Sebastian Moeller , Aaron Wood , cake@lists.bufferbloat.net, make-wifi-fast@lists.bufferbloat.net Message-Id: <0695D23F-B286-4E5D-ABA5-78AB16FAA5DE@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> 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 19:05:04 -0000 --Apple-Mail=_BDA4D8BA-DAFC-45BA-95E1-C7BC53E8825F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > 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. 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?=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=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=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: - 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! --Apple-Mail=_BDA4D8BA-DAFC-45BA-95E1-C7BC53E8825F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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=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:

- 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!

= --Apple-Mail=_BDA4D8BA-DAFC-45BA-95E1-C7BC53E8825F--