From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 42DF63B25E for ; Wed, 21 Sep 2016 05:59:07 -0400 (EDT) Received: by mail-wm0-x236.google.com with SMTP id l132so81810104wmf.1 for ; Wed, 21 Sep 2016 02:59:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:message-id:date:to:mime-version; bh=jOeqhSAK15SpokoKmp+ojgCy3kZHkQIdT8GLA/J11CU=; b=M+dMmzabkIDynD0YOkHtSjlrq7QHGfFa/psMXc88OU5q6Zqm+a4Qlj20qZTiYLsNzq COuLl+PmwDuJkPedcWxz5q+ke1c4Cu9POPc+MZA++AhzexRppNGeV/i8dxX25Ffsl7uE WPywGK/h6S8rw8hj1HJi8ZVl3hMPYcf+Q7jDum6piGjXm0+8j8HOe117veVb2yDPE12l ndahUQ0amBSku8udC+yq1gYAwNDzyH5aLDQKxawwbAENBE9iwasUpsxSqRIO1UA4QnSz tTOQpD0HAxaLPBcLcySCpKCQVg0BYZ9Ot5fRUVPC6icazp/8XXEvRISYTe+L0zEtHBuL 55xA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:message-id:date:to:mime-version; bh=jOeqhSAK15SpokoKmp+ojgCy3kZHkQIdT8GLA/J11CU=; b=aEArVAbUt0dx9oI+gaCV3Dhs/LJ1LDxok51c9Q001AlU83sGLljecwcPtr97zCfeEI oHyCJFwGeUQBc9FFOBirL4G/uWVpXhzfWaSUOunbIc1KbdoNYM+KJ2a4JZHpKKld9cqx Nml0PEyJaaaglu4lsHZE6s3bkqpUmy8rZ7nvebTUiDUBV3ghQpPKg9caFF3maRmMSFV0 L/y+T7n5wsnKtZRi2HFjAcYkRNyb2sprMfjDWljh5hbgdMitovz8YVuw/gAJCdqCfCtM vL4XZCNImdVY3gjlF9II8hI/g/fxTcPuZJ8s8dG3nWdYp9UlPabe46I6FszlzzOn75gq 2CQg== X-Gm-Message-State: AE9vXwPIlyajNtXY20gSsgRGfW/Ip4StMYiwRnnJle2kZMJojHd1urLhE1yi/RckjC5abQ== X-Received: by 10.194.233.102 with SMTP id tv6mr32090341wjc.35.1474451946076; Wed, 21 Sep 2016 02:59:06 -0700 (PDT) Received: from [192.168.142.194] (209.203.broadband11.iol.cz. [90.178.203.209]) by smtp.gmail.com with ESMTPSA id ce6sm32720016wjc.27.2016.09.21.02.59.04 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 21 Sep 2016 02:59:05 -0700 (PDT) From: Phineas Gage Content-Type: multipart/alternative; boundary="Apple-Mail=_CE5B90E1-F991-4E47-AF3B-FCDC784950FB" Message-Id: <945ED215-49E0-4F56-8B9A-FA95C0A82ABE@gmail.com> Date: Wed, 21 Sep 2016 11:59:04 +0200 To: codel@lists.bufferbloat.net Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Subject: [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 09:59:07 -0000 --Apple-Mail=_CE5B90E1-F991-4E47-AF3B-FCDC784950FB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I have two questions about using fq_codel on an edge router when the = Internet uplink is through point-to-point WiFi: 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? 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? Background: I manage the network for a camp / conference center that = supports up to about 120 users (5-10 simultaneous, at times). For = Internet, we've been using ADSL with 5 Mbit download, 0.4 Mbit upload = (remote area, so it=E2=80=99s slow). The only thing that keeps it usable = is running fq_codel on a transparent Linux bridge that sits between the = LAN and ADSL modem. On this bridge, I restrict the upload and download = rate to about 85-90% of maximum, and use fq_codel, plus some HTB = prioritization rules. It=E2=80=99s extremely effective at providing = usable latency, so kudos to the fq_codel algorithm and implementation. = It looks like this: LAN <=3D> Linux bridge with fq_codel <=3D> ADSL Modem 0.4 / 5.0 Mbps <=3D>= DSLAM =E2=80=A6 But now, we have a chance to improve our throughput problem by switching = to a point-to-point WiFi uplink that could hit speeds of 30-40 Mbit = symmetric (more on the speeds later). We have to decide on starting a = contract with them. At the same time, I=E2=80=99ll be switching the = bridge to a Ubiquiti EdgeRouter X, which has fq_codel in its kernel, but = should have the same effect. It would look something like: LAN <=3D> Ubiquiti EdgeRouter X <=3D> WiFi Client (Mikrotik 802.11n MIMO = 2x2) <=3D> WiFi AP from ISP =E2=80=A6 We already have a test setup in place. 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, with CCQ (connection quality) at 64% transmit / = 99% receive. First of all, I'll try to have them get that transmit CCQ = up to 99% like the receive, to make sure it's a stable link. But I also = know that the actual Internet throughput will be less than the link = rates, and speedtest.net results are currently around 30-40 Mbps = symmetric. Moreover, it's WiFi, and that led to my Question #1. I know that latency = and throughput can vary, and that there are more queues and more things = happening with packet aggregation, etc that I don=E2=80=99t understand. = Can this aspect of the variable latency, throughput and packet = transmission characteristics of WiFi make fq_codel less effective when = used in this way on an intermediate bridge or edge router, or does it = more depend on the quality of the WiFi link, where a high quality = point-to-point WiFi uplink to a good upstream network (there=E2=80=99s = another unknown) is indistinguishable from a cabled connection? My Question #2 came from the fact that I have two options from the ISP: 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. Option B: We can get a guaranteed bandwidth, but it costs more, so the = maximum throughput we can pay for would be less. We would probably = choose around 6/6 Mbit off-season, and 20/20 Mbit on-season, as the camp = is a seasonal business. My feeling, assuming that the answer to Question #1 is "yes" and I can = effectively use fq_codel with WiFi at all, is to go with Option B, the = guaranteed bandwidth. That way, I could set fq_codel to a little less = than this bandwidth, and hopefully manage buffer bloat and do HTB = prioritization in the same way I do now. But it depends on the answers = to my two questions, is fq_codel still effective when using a WiFi = uplink in general, and if so, is it better to go with a guaranteed = bandwidth. Thanks for any thoughts on this.= --Apple-Mail=_CE5B90E1-F991-4E47-AF3B-FCDC784950FB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I have two questions about using fq_codel on an edge router = when the Internet uplink is through point-to-point WiFi:

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?

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?

Background: I manage the network for a = camp / conference center that supports up to about 120 users (5-10 = simultaneous, at times). For Internet, we've been using ADSL with 5 = Mbit download, 0.4 Mbit upload (remote area, so it=E2=80=99s slow). The = only thing that keeps it usable is running fq_codel on a = transparent Linux bridge that sits between the LAN and ADSL modem. On = this bridge, I restrict the upload and download rate to about = 85-90% of maximum, and use fq_codel, plus some HTB prioritization = rules. It=E2=80=99s extremely effective at providing usable latency, so = kudos to the fq_codel algorithm and implementation. It looks like = this:

LAN <=3D> Linux bridge = with fq_codel <=3D> ADSL Modem 0.4 / 5.0 Mbps <=3D> DSLAM = =E2=80=A6

But now, we = have a chance to improve our throughput problem by switching to a = point-to-point WiFi uplink that could hit speeds of 30-40 Mbit = symmetric (more on the speeds later). We have to decide on starting a = contract with them. At the same time, I=E2=80=99ll be switching the = bridge to a Ubiquiti EdgeRouter X, which has fq_codel in its kernel, but = should have the same effect. It would look something like:

LAN <=3D> Ubiquiti = EdgeRouter X <=3D> WiFi Client (Mikrotik 802.11n MIMO 2x2) = <=3D> WiFi AP from ISP =E2=80=A6

We already have a test setup in place. = 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, with CCQ = (connection quality) at 64% transmit / 99% receive. First of all, I'll = try to have them get that transmit CCQ up to 99% like the receive, = to make sure it's a stable link. But I also know that the actual = Internet throughput will be less than the link rates, and speedtest.net results are = currently around 30-40 Mbps symmetric.

Moreover, it's WiFi, and that led to my Question #1. I know = that latency and throughput can vary, and that there are = more queues and more things happening with packet aggregation, etc = that I don=E2=80=99t understand. Can this aspect of the = variable latency, throughput and packet transmission = characteristics of WiFi make fq_codel less effective when used in this = way on an intermediate bridge or edge router, or does it more = depend on the quality of the WiFi link, where a high quality = point-to-point WiFi uplink to a good upstream network (there=E2=80=99s = another unknown) is indistinguishable from a cabled = connection?

My Question #2 came from = the fact that I have two options from the ISP:

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.

Option B: We can = get a guaranteed bandwidth, but it costs more, so the maximum throughput = we can pay for would be less. We would probably choose around 6/6 = Mbit off-season, and 20/20 Mbit on-season, as the camp is a seasonal = business.

My feeling, assuming that = the answer to Question #1 is "yes" and I can effectively use fq_codel = with WiFi at all, is to go with Option B, the guaranteed bandwidth. = That way, I could set fq_codel to a little less than this bandwidth, = and hopefully manage buffer bloat and do HTB prioritization in the = same way I do now. But it depends on the answers to my = two questions, is fq_codel still effective when using a WiFi uplink = in general, and if so, is it better to go with a guaranteed = bandwidth.

Thanks for any thoughts = on this.
= --Apple-Mail=_CE5B90E1-F991-4E47-AF3B-FCDC784950FB--