From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 E21B53B29E; Fri, 17 Feb 2017 02:52:59 -0500 (EST) Received: by mail-wm0-x22f.google.com with SMTP id c85so6988077wmi.1; Thu, 16 Feb 2017 23:52:59 -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=ori4ktJkRGcAn0bX6mTdWphwbJ6TVzPAab/R7WCUAe0=; b=iYpYzZeIbnoMoI0A8fgQR0mH5Wno/Hot+XlVLAHUvhiHQXmKBBdBPHzGgQvdYL7M0J eTiuZxqGX9a6ATkENYWuuT20qpoMpFJUncGGx1RD8oEq/Nq+KNo0StBpiUaviXKmnUQo xYADtAfmhyW4RPpaObQFY4Zx36x58DMp31SqQYFkfVyaC/5VpTDZVuwqfCsVthkbOCy0 mtk2LkL5Zv5sH49OtFAeuzUxdWB2Ldq0408Rq2JOayjyX5GxH9P25CnCEpCeeUbDEeQx A9dVQLBwUL9yride4ogkXThvpupvWBwBmg88Z3nrLAPp2uLgehZZ7Nd+8UuodjzXT6Jp JxzA== 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=ori4ktJkRGcAn0bX6mTdWphwbJ6TVzPAab/R7WCUAe0=; b=QlCz1NTATbHfDMF/isE/9R8Dqd1mXGdMzfZwIlTyjtQwqEeb7SsEw6xR6/ob9drjiw ZeGAMlwOjWwOvVsDJBOvt+iSF8sL7IhgQYfIueWK2gT8sGl9Mlfzn+gBHgrZXwhksbNg 613CIZLxtc2/k2gYuPEKrttIfON1oxpAaChgwNYR+Jtfc31ZLY19MQYGqQN+6OtdykIH zebGGh3gfSekNFHwczrbjJUAEDJu4ImUnrPJoiO86iAacg6sZXC33sEz7qekxVbWqxZi WvCZW+AZ3WrGSaRtTzrZGUDLJMKXyRODwuHvptPztzjs+AQz7NJInBVKH7zEV50LsIVX uMBQ== X-Gm-Message-State: AMke39lnMQgnRT7/2AzWTt6mhvil626rLDHslfLpJu/Sp/F+s0CvAN0Nb5OFmOwUL6C9Lg== X-Received: by 10.28.136.68 with SMTP id k65mr1834524wmd.48.1487317979008; Thu, 16 Feb 2017 23:52:59 -0800 (PST) Received: from [10.72.0.34] (h-1169.lbcfree.net. [185.99.119.68]) by smtp.gmail.com with ESMTPSA id e71sm672438wma.8.2017.02.16.23.52.57 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 16 Feb 2017 23:52:58 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_CD143AEB-2F18-499A-A055-0ADA702D2D26" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Pete Heist In-Reply-To: Date: Fri, 17 Feb 2017 08:53:19 +0100 Cc: Jonathan Morton , Aaron Wood , cake@lists.bufferbloat.net, make-wifi-fast@lists.bufferbloat.net Message-Id: <09A27886-7088-4493-A262-3CC2FF4C6CE2@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: Sebastian Moeller 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: Fri, 17 Feb 2017 07:53:00 -0000 --Apple-Mail=_CD143AEB-2F18-499A-A055-0ADA702D2D26 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 16, 2017, at 10:03 PM, Sebastian Moeller = wrote: >>=20 >> On Feb 16, 2017, at 18:19, Jonathan Morton = wrote: >>=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 > Here is part of the problem: the more aggressive airtime access = of the VI and VO classes will massively cut down the actual achievable = bandwidth over all classes. And I might add this effect is not = restricted to the AP and station under one=E2=80=99s control, but all = other stations and APs using the same frequency that are in the close RF = neighborhood will affect the available airtime and hence achievable = bandwidth. If you look how wifi achieves its higher bandwidth it is by = using longer periods of airtime to make up for the rather fixed time = =E2=80=9Cpreamble=E2=80=9D that wastes time without transmission of user = data. VI users in the vicinity will drastically (IIRC) reduce the = ability to send those aggregates. In other words link saturation is = partly a function of which AC classes are used and not a nice and fixed = entity as for typical wired connections. Now if you can control both = sides of your transfer _and_ all other users of the same frequency that = are RF-visible to your endpoints, it might be possible to thnk of a wifi = link in similar terms as a wired one, but I would be cautious=E2=80=A6 Thanks for that info. In my testing I=E2=80=99m focusing on = point-to-point Wi-Fi, but I see the complexity that WMM presents, = especially when there's more than one station. It's perplexing that at least two concerns- packet retransmission and = prioritization, occur at multiple layers in the stack. 802.11 ack frames = are sent in response to every data frame (aggregation aside), and = retransmission occurs at this layer, but also higher up in the TCP = layer. Prioritization can occur at the IP layer, but then again in the = media layer with WMM. This seems to violate separation of concerns, and = makes it difficult to ascertain and control what=E2=80=99s going on in = the system as a whole. It feels like WMM went a step too far. There may have been (may still = be) valid performance reasons for Wi-Fi to take on such concerns, but as = the data rates get higher and processing power increases, it feels like = it would be better to have a wireless technology that just delivers = frames, and to push reliability, prioritization and aggregation back up = into the higher layers so that long-term innovation can take place in = software. The 802.11 spec is on my reading list so I might learn if and = where this goes off the tracks.= --Apple-Mail=_CD143AEB-2F18-499A-A055-0ADA702D2D26 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Feb 16, 2017, at 10:03 PM, Sebastian Moeller <moeller0@gmx.de> = wrote:

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

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.

Here is part of the problem: the more aggressive = airtime access of the VI and VO classes will massively cut down the = actual achievable bandwidth over all classes. And I might add this = effect is not restricted to the AP and station under one=E2=80=99s = control, but all other stations and APs using the same frequency that = are in the close RF neighborhood will affect the available airtime and = hence achievable bandwidth. If you look how wifi achieves its higher = bandwidth it is by using longer periods of airtime to make up for the = rather fixed time =E2=80=9Cpreamble=E2=80=9D that wastes time without = transmission of user data. VI users in the vicinity will drastically = (IIRC) reduce the ability to send those aggregates. In other words link = saturation is partly a function of which AC classes are used and not a = nice and fixed entity as for typical wired connections. Now if you can = control both sides of your transfer _and_ all other users of the same = frequency that are RF-visible to your endpoints, it might be possible to = thnk of a wifi link in similar terms as a wired one, but I would be = cautious=E2=80=A6

Thanks = for that info. In my testing I=E2=80=99m focusing on point-to-point = Wi-Fi, but I see the complexity that WMM presents, especially when = there's more than one station.

It's perplexing that at least two = concerns- packet retransmission and prioritization, occur at multiple = layers in the stack. 802.11 ack frames are sent in response to every = data frame (aggregation aside), and retransmission occurs at this layer, = but also higher up in the TCP layer. Prioritization can occur at the IP = layer, but then again in the media layer with WMM. This seems to violate = separation of concerns, and makes it difficult to ascertain and control = what=E2=80=99s going on in the system as a whole.
It feels like WMM went a step too far. = There may have been (may still be) valid performance reasons for Wi-Fi = to take on such concerns, but as the data rates get higher and = processing power increases, it feels like it would be better to have a = wireless technology that just delivers frames, and to push reliability, = prioritization and aggregation back up into the higher layers so that = long-term innovation can take place in software. The 802.11 spec is on = my reading list so I might learn if and where this goes off the = tracks.
= --Apple-Mail=_CD143AEB-2F18-499A-A055-0ADA702D2D26--