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

[Phineas Gage]

> On Sep 21, 2016, at 1:38 PM, Jonathan Morton <chromatix99 at gmail.com> wrote:
>> 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.

So, for example, if one runs fq_codel on a regular AP accessed by multiple stations (using “tc”, above the driver level), this is not necessarily a good idea? And once the driver work is done and the queues are managed at a lower level, will this no longer be the case?

>> 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 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.

Thanks a lot for this great information, I’ll ask them more about what’s behind their aggregation ratio. As I mentioned in one reply earlier, I may ask for flexibility in our contract, try the aggregated service, then switch to guaranteed service depending on the actual performance of their network. If I can rate limit to 30/30 and fq_codel, and it’s 99% effective, I’d rather take that than settle for a guaranteed 20/20 on-season and 6/6 off-season to get to the same annual contract price.

I see that this is a great place for helpful info about fq_codel. I probably should have “aggregated” (word of the day) my replies to reduce list traffic, so will do so next time if needed.