[Codel] Using fq_codel with a WiFi uplink to the Internet

[Jonathan Morton]

> On 21 Sep, 2016, at 12:59, Phineas Gage <phineas919 at gmail.com> wrote:
> 
> 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?

This is actually a pretty interesting pair of questions.  We’ve 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’re 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…

> 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’s 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’ll 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’t 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’s a question worth asking your WISP.  Be ready to point out that you don’t 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