CoDel AQM?
-
Much has been made about this lately, and it definitely looks like something that would be great to have in BSD/pfSense.
Here's the white paper: http://queue.acm.org/detail.cfm?id=2209336
And a quote from the article:
In the decade since, many researchers have made strides in AQM, but no one has produced an AQM that has the following characteristics:
It is parameterless—it has no knobs for operators, users, or implementers to adjust.
It treats good queue and bad queue differently—that is, it keeps the delays low while permitting bursts of traffic.
It controls delay, while insensitive to round-trip delays, link rates, and traffic loads.
It adapts to dynamically changing link rates with no negative impact on utilization.
It is simple and efficient—it can easily span the spectrum low-end, Linux-based access points and home routers up to high-end commercial router silicon.and:
CoDel’s algorithm is not based on queue size, queue-size averages, queue-size thresholds, rate measurements, link utilization, drop rate or queue occupancy time.
It's just been put in the Linux mainline and OpenWRT mainline. Anyone know any more, or if this is destined for BSD/pfSense?
-
It does not seem hard to implement though not on my priorities.
-
This is a big problem in my installation. If you want to hear from users about priority I'd vote to move this up near the top of the list!
-
This is a big problem in my installation. If you want to hear from users about priority I'd vote to move this up near the top of the list!
Make a bounty and then you should have better priority
-
I'd like to vote for this to be implemented ASAP.
-
I'd like to vote for this also. I'm sure this is a problem in most all environments that have a smaller pipe to the internet than they have internally. Please address this issue as most likely everyone has it they just don't know it!!!
Thanks!
-
I'm very curious why this isn't seen as a higher priority? It would seem to completely eliminate the need for traditional traffic shaping for a lot of use cases (and all the negatives that come with it)? At least according to the ipfire guys here: http://planet.ipfire.org/post/ipfire-2-13-tech-preview-fighting-bufferbloat
and here: http://planet.ipfire.org/post/ipfire-2-13-beta-2-part-4-bufferbloat
Isn't this the biggest innovation with the largest impact on actual performance in a very long time?
-
so is anything happening about this?
-
FYI there are some efforts.
http://permalink.gmane.org/gmane.os.openbsd.tech/29745Still not gotten to it yet
-
This is in 2.1 snapshots.