Need Active Queue Management for Bufferbloat (fq_codel)


Peplink, will you please respond to my 5/17/18 posting to the existing BufferBloat topic in Product Discussion. My 5/17/18 post is reproduced below. Please note that my posting below refers to several posting by others in the existing BufferBloat topic, so you may want to read that thread first. For example, others have tried to front end Peplink routers in a multi-WAN environment with other routers which have fq_codel upon which I comment. Thank you!

So what about it Peplink? Is it time for Peplink to step up to the new ways of handling QoS and Bufferbloat? Do you want to continue forever with the old way where an expert has to tune QoS and then it is never right for all situations? Or should Peplink adopt fq_codel which automates tuning dynamically to the type of tcp/ip connections which are currently active and dynamically to the amount of bandwidth your DSL or cable provider is providing at different times of the day?

The new way with Fq_codel takes care of automatically adjusting the speed of each tcp/ip stream to make sure your broadband connection(s) is not overloaded and incurring bufferbloat based on measuring RTT, round trip time, keeping it low for each connection. And it does it “fairly” (the F in fq_codel), dynamically handling whatever types of tcp/ip connections are currently active. How many different product discussions are currently pending in the Peplink forums such as “Single Youtube upload killing Internet traffic” or “Limit download throughput per WAN” that are non-issues with fq_codel?

To date, Peplink has given us ways to set the number of buffers, which as commented on earlier in this thread doesn’t really work, fixing one problem while introducing another. And as you will find on the web if you research, “Quality of Service (QoS) settings will help, but won’t solve bufferbloat completely. Why not? Any prioritization scheme works by pushing certain packets to the head of the queue, so they’re transmitted first. Packets farther back in the queue still must be sent eventually. New traffic that hasn’t been prioritized gets added to the end of the queue, and waits behind those previously queued packets. QoS settings don’t have any way to inform the big senders that they’re sending too fast/too much, so packets from those flows simply accumulate, increasing delay for all. Furthermore, you can spend a lot of time updating priorities, setting up new filters, and checking to see whether VoIP, gaming, ssh, netflix, torrent, etc. are “balanced”. (There is a whole cottage industry in updating WonderShaper rule sets. They all have terrible flaws, and they don’t help a lot.) Worst of all, these rules create a maintenance hassle. Each new rule has to be adjusted in the face of new kinds of traffic. And if the router changes, or speed changes, or there’s new traffic in the mix, then they need to be adjusted again.”

The $50 router mentioned in the previous post is most likely the Ubiquiti Edgerouter X which has fq_codel and works GREAT on reducing bufferbloat. Fq_codel, a proven Active Queue Management (AQM) algorithm, is available in an increasing number of commercial routers. For example, besides the Edgerouters, it is a component of Qualcomm’s “streamboost” QoS system. It is in Netgear’s “Dynamic Qos” feature”. The Zyxel Armor Z2 AC2600 MU-MIMO Wireless Router offers StreamBoost. And of course LEDE (now back to being OpenWrt), etc.

The new DOCSIS 3.1 standard includes DOSIS-PIE Active Queue Management for all DOCSIS 3.1 cable modems (too bad many cable providers don’t enable it).

Peplink, we are ready for you to step up to the plate. Yes, you have a lot of QoS and prioritization code that users have tuned their existing installations with, so you can’t just replace it with fq_codel. You can give fq_codel to us as an option to enable however. Please do so!

------------------------- Notes to Peplink users struggling with Bufferbloat ------------------------

I have provided a number of customers as well as friends and relatives with a lot of routers. Here is what I use and why.

Decide whether or not Bufferbloat will be a problem. If you have enough broadband bandwidth, you can get away without fq_codel. I.e., Peplink is great. That said, I always recommend a router with fq_codel for DSL situations.

For a simple home situation that will experience bufferbloat, the IQrouter is great. Don’t plan on doing anything sophisticated like VLAN’s though.

The Ubiquiti Edgerouters are truly excellent if you can get them configured and are willing to use AP’s for Wi-Fi. They are great for situations which fall neatly into configurations for which they have Wizards to create and you need to do little else, especially CLI commands as opposed to GUI configuration. For example, they have a wizard for WAN plus two LAN subnets. On the other hand, you probably don’t want to do multiple WAN’s with VLAN’s for example, unless you have lots of time to become an EdgeOs expert.

Ubiquiti has recently introduced the new Edgerouter ER-4 and Edgerouter ER-6P. These can do 1GB at $200 and $300 respectively as long as you don’t enable fq_codel which takes additional cpu power and reduces the throughput. The Peplink Balance One is limited to 600mb.

To the individuals who have tried to add an outboard fq_codel router between the modem and a multi-wan router, I’ve tried this configuration with both Ubiquiti and Netgear fq_codel. Netgear wasn’t reliable enough for me. Ubiquiti always did its job reliably, but unfortunately the multi-wan router I was using at the time (not Peplink) sometimes would declare a WAN link out of service and never bring it back into service, so I didn’t stick with that setup.

Wrapping this up, I like the IQrouter for its simplicity. I like the power and reliability of Edgerouters. I love the Peplink for its easy configuration, reliability, and support. That’s why I am hoping Peplink adds fq_codel support soon.


Hi, we understood your concern and looking at it.


@Mark9, yea we understand your pain and actually this topic has been discussed within the team for a long time, may be I could share more information with you before we have some firmware for you to play with. From our internal test result quite some time ago, fq_codel alone is just not enough for a dynamic environment, like a cellular connection. That’s why we are still working on it. So far we already have some candidate to help improve the problem, but not finalized enough yet to build into the firmware, we will absolutely keep you posted once we have more information to share with you. :+1:t2:


Very glad to hear this is in the works! As you point out, dynamically adjusting to a changing environment is advantageous. IQrouter is making waves with their router doing this. These days, it isn’t just DSL bandwidth performance that sags at different times of day. So does cable. Fixed ingress and egress values for fq_codel doesn’t work very well in that environment.

Note to others: I can state my experiences upgrading to DOCSIS 3.0 cable modems with 24x8 or 32x8 channels is that it seems to be better statistically for maintaining low latency than older cable modems with lower channel counts. Of course new DOCSIS 3.1 modems are now available now too.

Thanks very much for the update!