From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x241.google.com (mail-lf0-x241.google.com [IPv6:2a00:1450:4010:c07::241]) (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 DEE9F3B29E; Thu, 16 Feb 2017 12:19:20 -0500 (EST) Received: by mail-lf0-x241.google.com with SMTP id x1so1991331lff.0; Thu, 16 Feb 2017 09:19:20 -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 :content-transfer-encoding:message-id:references:to; bh=/k7aIXtMjd9mzAldqAZMcfy7cj6dls4ajmjRXK6V4ew=; b=cEodVw8cpmhUNGib9bm7bQbNWQAXvVAYgPfKXaKcSP0ldUIEJsVvNm5HtVpYjcRzkw JmJFbeiLNp1i9+A3MvlFsN6LiCIc+PJy9+0osYCciSYwDTA5Hs/o4hHLjobiFik/ytSj fulTixwP+jnoq6EEtcyp6y4TgdBkfi/AuoXmX2dJf3YLhKiZ5Lp+rSYZODkIXbWjbTbN pRCFxpHUrHFR1bEK4knDsuPMHhfEGQQYiEzhZ/EGn+ypQSOleGDlvIZ3CMc//sTowsOy sjDf1m4ZXjACLPJKS8WVSquGUGox0KPIaIn0KpvY5XTaKvj1T28MQrYyMNmrrwmMKde5 hUcg== 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 :content-transfer-encoding:message-id:references:to; bh=/k7aIXtMjd9mzAldqAZMcfy7cj6dls4ajmjRXK6V4ew=; b=YTXZEMPuzQqT/ZTpVq+3ZkfAdhZjI2mkWsJPkbtbFnaGJmg77Ibk6SXKS7Z8ZlIEkK euIWsOPSbpA2u9BocZQTvu1cflDY5Dk7CtotY7T1gLF/AmSgLDPUe6RlzG+dxWBwKex9 i2RT+Hd5QhLU1WXp+4KoOCzeC8NWlN9ldqr67oMOYairDTTtcscQ1vScQuJ3TCrGBfys KkL/v/G0pzbXu602JMNYLPqmdBe+OAdvkhd4E8onHBxGMm6osIj4uFvV/QpbW5/Sc6KX 5zetJcIOezjszc//ZykCxVjlkZFRSMZePSax+Ccz/kluZHpW7JVqQa9PwWRxL8HUkFmu bd0w== X-Gm-Message-State: AMke39nNWypkSp8xRjp+NvAY3V7y/vCiBFetnZX+o68l5PhR/piLocg2qM8ZjmOPLhIAew== X-Received: by 10.25.22.78 with SMTP id m75mr1087932lfi.176.1487265559680; Thu, 16 Feb 2017 09:19:19 -0800 (PST) Received: from [192.168.100.16] (37-219-206-78.nat.bb.dnainternet.fi. [37.219.206.78]) by smtp.gmail.com with ESMTPSA id r134sm1876667lfr.43.2017.02.16.09.19.18 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 16 Feb 2017 09:19:18 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jonathan Morton In-Reply-To: Date: Thu, 16 Feb 2017 19:19:11 +0200 Cc: Sebastian Moeller , Aaron Wood , cake@lists.bufferbloat.net, make-wifi-fast@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <83F97E77-3CCD-44B2-B9EB-7F34DA3A3A50@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> To: Pete Heist 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 17:19:21 -0000 > 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. 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. >> 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. 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. - Jonathan Morton