From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (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 D77323B2A0 for ; Wed, 21 Sep 2016 07:38:29 -0400 (EDT) Received: by mail-lf0-x22d.google.com with SMTP id l131so38224011lfl.2 for ; Wed, 21 Sep 2016 04:38:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=u8/ItqpjkUp3GZoT1ev9J49EKM9+w3IDxrg/GqEBs2M=; b=IJeRnaHsbQyP0fJkcd+oGsgqlR1O0Lpb8EPABOC/q9MXZTjVxVNa0AcEcJji9K4MI8 rvwJ6j7dqmsE+dRhKOjFqJV+Ei/EybK2duclQcqVcz/543SCGVVPFrbp+Ur8suZt1O0L 8+MfOmcGluel27EeXGNQg6JQDcp2CtDzu9zgPvG3thKuRejc2KbgtB0dWO6vZQMQhHMb ZmZCz03EdooCTG07ZHbUK5uO5cNvo/aEpqpUaC3V2/fFkSSmKFX7+Tf6TrNrwLzdPsPF Dt32nq13vMZtFLZk4wFHWrbr4xbpyCkiGqjhaKOW5yDzF4Wk94b8jF1xOCGP27rwOG68 mr1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=u8/ItqpjkUp3GZoT1ev9J49EKM9+w3IDxrg/GqEBs2M=; b=BxK730DsMvHr2ZqDEMNmLfRRlzkNPppp80me+zspd2C+qKkrTbe3Uc6wHWLu1zNJuD ldmff3UcpiOIQTDoLLMSuRMkUhXT0+xV4HtWJAZUjqSvSiBLhfeaWzu+xZlUBTaRAerU c0s5dajrXSXSWcDvoDWXdfTm53UX7ID7xuhhFVrv1ka7ba08eN/ibXH3xtZt523KDAqo QwYXoKvizQEbyHdgQC9/gWO91jYKkSUx29uQHhSziSyqwUOr9uAGGZlWDbzZfqUvojlv nC10daiPchBcwX6u+kyuVgdApCqyRks76344kRDHl9AbQXVc2FGdcxG5yCdPzK7PXgVy MoNw== X-Gm-Message-State: AE9vXwPksTYLYzb496Xye9egaXcYyR6rc0a4wjRoDREo8qohmPuX7MfxPApoVQP7SzAJ8Q== X-Received: by 10.46.69.214 with SMTP id s205mr5757260lja.7.1474457908519; Wed, 21 Sep 2016 04:38:28 -0700 (PDT) Received: from [192.168.100.13] (37-33-90-35.bb.dnainternet.fi. [37.33.90.35]) by smtp.gmail.com with ESMTPSA id 1sm6666932ljf.48.2016.09.21.04.38.27 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 21 Sep 2016 04:38:27 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jonathan Morton In-Reply-To: <945ED215-49E0-4F56-8B9A-FA95C0A82ABE@gmail.com> Date: Wed, 21 Sep 2016 14:38:25 +0300 Cc: codel@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <75B6F546-894B-4257-95F6-5329273B07D1@gmail.com> References: <945ED215-49E0-4F56-8B9A-FA95C0A82ABE@gmail.com> To: Phineas Gage X-Mailer: Apple Mail (2.3124) Subject: Re: [Codel] Using fq_codel with a WiFi uplink to the Internet X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Sep 2016 11:38:30 -0000 > On 21 Sep, 2016, at 12:59, Phineas Gage wrote: >=20 > Question #1: Is it still effective to run fq_codel on our edge router = when I have a WiFi uplink to the Internet, instead of a cabled = connection like ADSL? And related to that, is a high quality = point-to-point WiFi connection indistinguishable from a cabled = connection as far as fq_codel is concerned? >=20 > Question #2: Assuming the answer to Question #1 is an overall "yes", = is it then better to have a guaranteed speed from the ISP, instead of = having a variable but potentially higher speed, so that I can control = the queue and have fq_codel and HTB prioritization work effectively? This is actually a pretty interesting pair of questions. We=E2=80=99ve = just been doing quite a lot of work related to integrating fq_codel (or = something very like it) into the Linux wifi stack, where it has more = information about aggregation and other things, and can therefore make = smarter queuing decisions. The very best solution would be for your WISP to integrate this work = into their hardware at each end of the link. It may take a little more = time until that can happen, as the code is very very fresh and still a = little raw. Until then, I think something like what you=E2=80=99re already doing = should work well. Normally, fq_codel interacts badly with = high-performsnce wifi because it tends to distribute packets alternately = to different stations, which tends to prevent effective aggregation, but = this is not a concern for a point-to-point link where all your traffic = goes to and from one station to another. > The link rate to the ISP's AP, as reported by Mikrotik's admin = console, is currently 86.6 Mbps transmit and 144.4 Mbps receive=E2=80=A6 > Option A: We can choose a maximum of 40/40 Mbit with 1:5 aggregation, = meaning we could get 40 Mbit, but we could also get a lot less at times = (8 Mbit I assume), depending on other network load. The raw link rates are sufficiently above the service provisioning that, = bar significant changes in geography between you and the access point, = antenna faults, or really bad weather, you can probably count on getting = 40/40 reliably at the link level. The 1:5 aggregation is worth exploring a bit more deeply. Usually this = refers to the ratio between the total bandwidth provisioned across all = customers (in some region and some service class) and the minimum = backhaul capacity within and at the far edge of the ISP=E2=80=99s = network. The theory is that customers tend not to use all of their = bandwidth all of the time, though they do tend to use all of it some of = the time. This theory works fairly well in practice as long as the = traffic patterns are not too correlated and are distributed over a = sufficient number of customers. In order to be dragged down to 8Mbps, you would have to see all the = other customers sharing your backhaul trying to use 8Mbps or more (on = average) at the same time. This is unlikely to occur often; consider = major sportsball championship final matches, or national disasters such = as one we recently had an anniversary of, as the most likely triggers. = Under such circumstances, you=E2=80=99ll need to step in and manually = experiment to find out what works, but shaping at 8Mbps would be a = reasonable default reaction. Of more concern to you is how much external load is needed to pull your = share of the backhaul significantly below 40Mbps - or, alternatively, = below the 20Mbps you can get with the more expensive uncontended = service. This will vary depending on how many customers the 5:1 average = is spread over - you can=E2=80=99t actually calculate it from the = information given. So the question is whether they have a 40/40 backhaul shared among 5 = customers, or a 1G/1G backhaul which they plan to share among up to 125 = customers, each with 40/40 service. I think the latter is a perfectly = reasonable possibility, and would be much more robust than the former = option which would give you a reduction in throughput as soon as *any* = of the other customers on the same backhaul segment did *anything*. It=E2=80=99s a question worth asking your WISP. Be ready to point out = that you don=E2=80=99t plan to actually *use* 40Mbps full-time, but that = your AQM solution depends on knowing how much bandwidth is available for = when *your* customers randomly demand it. - Jonathan Morton