From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 7CDFD3BA8E for ; Sun, 8 Jul 2018 22:20:58 -0400 (EDT) Received: by mail-wr1-x430.google.com with SMTP id p1-v6so9272214wrs.9 for ; Sun, 08 Jul 2018 19:20:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8G3irtqcRTlegsLlPOYPSxeXxGMstOmzNEj9fo6ti6k=; b=q5NuGoTmTQzPwUDPXYWxsXZ2tN3pCuUKfy+eZLSlIQxgzPapCmy5PnffNKy3GswMKH HI+3x7vh7yyq79NLLAdC9wuZkkpDf3A3IWtPv3MQwjOi01dkUVHkvtMjQP5hdnU1BGSn iWHK9jgGOlPNJnj3Zpvyz4rD0+qcWHQIm/uuc1mkq8EBel/lJTcK0Uitd3XUGou7OxJ9 MPavGG/JBEKmu0rD2NtYauEjTszWTTxLOFBtvVDlDFdutNHj5adP2HIikr40xK/AhN2V dHyrQQT4KsIjbQjiMsu66Tm1AS2uScpfv6kDH+Ea3mAZSWaJaHxgrnf6iyQHUWVBw9wC i/ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8G3irtqcRTlegsLlPOYPSxeXxGMstOmzNEj9fo6ti6k=; b=gwzpdC+hPH/+BdcqlX2xfWV4H4kSY03VbSaZU0N2Ar/rIhXre8xtmqJgd66GWGMU/u NiVuXploX8k5B9LEpzcnhgzFX1ACtWpTIvtQkOtn3xQjCjSNP+R7qDdjIDKyX0XXDv7+ ovWg+iE6TIWYmRV6CcpW+RmImo6ordO5wQ3tFRT5D+i5ajUeixVZcb8HrzCBTMd4+rrj IwdyfVVSBAnuBRbTW8fX8ZxJpZ41MA7xQUMQIyLqSggwsrhf1B2CN4lJP48XBXs7KoKM NjIYeudgoNfsr9iMb5F0YmT0ljxmcvsQKzHAT1QXHDzkBahwZ1R5WL0kd69GrT7ZyQmY pjxA== X-Gm-Message-State: APt69E2BcjE+l5ZhmJ6Lq32eckaX6qaayb8eOLtomGaY0Y9EyLQVk0/Y hZz7MMShONiTIzlpokm222sfN/hc+MWGggMMgXg= X-Google-Smtp-Source: AAOMgpeCjhat7+dNydKcuDn7t/mPy57RvyINu4Zf5En+zl1ZzwFs9mXjse8kB76nlz3/6jLvzGCQZs1zVR/3pkBfehw= X-Received: by 2002:a5d:41c1:: with SMTP id e1-v6mr13447240wrq.25.1531102857473; Sun, 08 Jul 2018 19:20:57 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a1c:7d03:0:0:0:0:0 with HTTP; Sun, 8 Jul 2018 19:20:56 -0700 (PDT) In-Reply-To: References: <9E7E043B-2373-46ED-B122-38A287422999@eventide.io> <87d0wu7rbg.fsf@toke.dk> <8A44F1D4-1EB8-4D46-85F9-00C7307FF2D4@heistp.net> <2EC1279B-76C6-48C0-AED4-E9C4A7D0F004@heistp.net> <874lhdeso1.fsf@toke.dk> <87fu0xd1o9.fsf@toke.dk> <663D9F58-3202-42CD-9BD5-3B415E77EE97@heistp.net> From: Aaron Wood Date: Sun, 8 Jul 2018 19:20:56 -0700 Message-ID: To: Jonathan Morton Cc: Pete Heist , Make-Wifi-fast Content-Type: multipart/alternative; boundary="000000000000ef3327057087a93b" Subject: Re: [Make-wifi-fast] mesh deployment with ath9k driver changes 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: Mon, 09 Jul 2018 02:20:58 -0000 --000000000000ef3327057087a93b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Do the AP-to-AP links use the same packet scheduling as the AP-to-STA links? (especially the prohibition on aggregation for VO, which seems counter-productive on a backhaul link). On Thu, Jul 5, 2018 at 1:17 PM, Jonathan Morton wrote: > > On 5 Jul, 2018, at 9:02 pm, Pete Heist wrote: > > > >> Wouldn't be surprised. Note that packets will be dropped from the > >> longest queue, though, so unresponsive flows just hurt themselves... > > > > Probably not before they=E2=80=99ve wasted airtime though and and impac= ted > everyone else... > > Would it be worth extending the principle of airtime fairness to the QoS > queues? Clearly traffic in the VO queue consumes airtime out of all > proportion to its actual volume, due to the prohibition on aggregation; > this provokes a similar argument to the impact of slow clients on faster > ones. > > I wouldn't worry too much about the links between leaf APs and their > clients. Those are probably relatively strong and fast, so BE traffic ca= n > get through reasonably well in between the VO traffic. > > But the AP-to-AP links cover a significant distance and are that much mor= e > susceptible to airtime congestion, which VO traffic exacerbates > considerably. These APs are also running open-source firmware where we c= an > actually tackle this problem. So there must be a case for deprioritising > VO if it's using more than some reasonable share of the available airtime= . > > Oh, and if I find out which BT client has selected a VO-category DSCP by > default... >:-( > > - Jonathan Morton > > _______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast > --000000000000ef3327057087a93b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Do the AP-to-AP links use the same packet scheduling as th= e AP-to-STA links? (especially the prohibition on aggregation for VO, which= seems counter-productive on a backhaul link).

On Thu, Jul 5, 2018 at 1:17 PM, Jonathan= Morton <chromatix99@gmail.com> wrote:
> On 5 Jul, 2018, at 9:02 pm, Pete Hei= st <pete@heistp.net> wrote: >
>> Wouldn't be surprised. Note that packets will be dropped from = the
>> longest queue, though, so unresponsive flows just hurt themselves.= ..
>
> Probably not before they=E2=80=99ve wasted airtime though and and impa= cted everyone else...

Would it be worth extending the principle of airtime fairness to the= QoS queues?=C2=A0 Clearly traffic in the VO queue consumes airtime out of = all proportion to its actual volume, due to the prohibition on aggregation;= this provokes a similar argument to the impact of slow clients on faster o= nes.

I wouldn't worry too much about the links between leaf APs and their cl= ients.=C2=A0 Those are probably relatively strong and fast, so BE traffic c= an get through reasonably well in between the VO traffic.

But the AP-to-AP links cover a significant distance and are that much more = susceptible to airtime congestion, which VO traffic exacerbates considerabl= y.=C2=A0 These APs are also running open-source firmware where we can actua= lly tackle this problem.=C2=A0 So there must be a case for deprioritising V= O if it's using more than some reasonable share of the available airtim= e.

Oh, and if I find out which BT client has selected a VO-category DSCP by de= fault...=C2=A0 >:-(

=C2=A0- Jonathan Morton

_______________________________________________
Make-wifi-fast mailing list
Make-wifi-fast@list= s.bufferbloat.net
https://lists.bufferbloat.net/listinfo/mak= e-wifi-fast

--000000000000ef3327057087a93b--