This might be answered elsewhere, but I couldn’t really find a definite answer via the forum search function, so I figured I’d throw it out there.
Are there any pending plans to support CoDel in a coming version of RouterOS? I know many people are using RouterBoard boxes on only very high bandwidth backbone style connections, but there’s also a good number out there (myself included) that like using it for home and small office type connections, where CoDel can really make a big impact when congestion occurs.
(For those that have no idea what in the heck CoDel is, see this episode of Security Now for a more detailed explanation: http://twit.tv/show/security-now/359 )
That’s most certainly a good tip for anyone that only wants CoDel and doesn’t necessarily care about the OS, but I’m really wanting to see it specifically on RouterOS, and I don’t see a reason why they couldn’t squeeze it in to a future release. I’m sure I’m not alone there either.
Static queue techniques are great on fixed bandwidth links, but are useless on wifi and other type of links that have dynamic bandwidth.
Please correct me if I’m wrong, but AFAIK Mikrotik doesn’t support any active queue management techniques (AQM) [1], CoDel is AQM type of QoS.
Hope that clears a bit.
UPDATE:
Mikrotik supports one aqm qos type, that is RED [2]
Quote from wikipedia:
“Early AQM disciplines (notably RED and SRED) require careful tuning of their parameters in order to provide good performance. Modern AQM disciplines (ARED, Blue, PI) are self-tuning, and can be run with their default parameters in most or all circumstances.”
It would be such an improvement to have this sort of Active Queue Management (AQM).
Note: Codel and “percentage” based queues (changing on the Codel output answer), would be the ultimate win, and probably put your demand absolutely sky high.
Van Jacobson saves the Internet world again!
Regards
—EDIT:
Mikrotik replied and said they would investigate further, please post here if you understand the benefits of Codel and would like to see it implemented as well, watch the video and read the PDF to see how much and improvement to queueing it is.
Mikrotik, any news that this has been reviewed yet, etc?
It would be really nice if Mikrotik had a person whose sole job it was is to categorise and deduplicate feature requests and bugs, so we could monitor progress of those in a orderly fashion without having to bug you about it.
workflow steps might include
“Duplication - see xxxxxx”
“Not reviewed yet”
“Initial review, and accepted, in depth review set for yyyy/mm/dd”
“rejected after initial review with reason”
“Indepth completed, planned inclusion revision and date”
“completed”
“revised to include in revision and date”
I think perhaps I don’t fully understand what you are implying. But it seems you mean, its not necessary for them to explain themselves to us?
But from my point of view, with all the other suppliers whom we partner and resell their goods, the most successful ones, keep good track of their customers, and their customers’ customers requests.
it isn’t even necessary to share all steps, at all points, but whether a feature request has been reviewed, and a central “reviewer” deduplicating the list is a very good way to keep track of your customers interests.
Anyway, I don’t want to fill up this thread with unrelated info, so if you do reply, maybe we should move it do a different thread.
Please do … static limit-at and max-limit options are not the real solutions going forward when everyone (re)discovers bufferbloat. However, it seems work is being done to add CoDel to the Linux kernel itself.
Eagerly awaiting some indication that mikrotik will add fq_codel support as another AQM algorithm as it is in the Linux kernel and seems to be a great cpe solution (no manual tuning and fast response for variable wifi links).
http://gettys.wordpress.com/2012/10/01/tcp-small-queues/
From the last link:
“The combination of TSQ, fq_codel and BQL (Byte Queue Limits) gets us much of the way to solving bufferbloat on Ethernet in Linux. Unfortunately, wireless remains a challenge (the drivers need to have a bunch of packets for 802.11n aggregation, and this occurs below the level that fq_codel can work on), as do other device types. For example, a particular DSL device we looked at last week has a minimum ring buffer size of 16, again, occurring beneath Linux’s queue discipline layer. ”Smart” hardware has become a major headache. So there is much to be done yet in Linux, much less other operating systems.”
codel and fq_codel are not words for the same thing. codel is a drop strategy that keeps queue lengths shorter and overall latency lower. fq_codel combines drr-style packet scheduling with a few twists to give sparser flows (think dns, voip, and gaming packets) priority in the queue over flows (big downloads) that build a queue. It uses codel to keep the resulting flows shorter. In the general case on a home router, use fq_codel not codel.
You can think of it as a drop in sfq replacement that works well at higher bandwidths, or as a RED replacement that doesn’t require painful configuration, but it’s better than either or both, combined.
fq_codel is part of the linux wireless-backports package which has been backported as far back as linux 2.6.32. It’s my hope that’s far enough for more distros to pick it up. It’s been in the kernel since version 3.5 and continually improved since.
codel or fq_codel do NOT require BQL in it’s most common use case, which is in a rate limited ingres/egress qos system. Where something like htb or hfsc is used to control the available bandwidth, you attach fq_codel underneath instead of the default qdisc, pfifo_fast. A ton of products are using it now in their QoS systems.
BQL support is desirable if you attach it as a raw qdisc to an ethernet device. BQL doesn’t apply to wifi devices at all, and although you can attach fq_codel to the mq qdisc that most wifi devices use, work is still ongoing to make it work well with the excess buffering present in most wifi device drivers. Although openwrt has made fq_codel it’s default on everything, it’s a little premature to be shipping wifi AP products based on fq_codel without testing the behavior on contested links and a hard look at the device drivers involved. fq_codel works pretty well on clients with single wifi queue interfaces (think: android, or your laptop).
Lastly there are some new gear that bypass the qdisc structures in linux entirely, (octeon stuff) and I have NO data as to how well or even if fq_codel can apply there. I’m under the impression the octeons do RED in hardware, and if you can configure that, go for it… and I’d love it if fq_codel could be added to that firmware one day, too.
I’d be really happy if it showed up in microtik’s products where it could apply, and wish you all well on trying it. For questions about how it works, please ask the code or ietf "aqm"l mailing list, google for ‘bloat-videos’, read the bufferbloat website, see the ‘rrul rogues gallery’.
For status on the uptake into (for example) the cable industry, google for “active queue management algorithms for docsis 3.0”.
There’s far more to fix than just cable of course, and it will take a while for the industry and the ietf to settle on standards, but with the code generally available I’d hope you leap on it.
I also want to see CoDel-support. I have no experiences yet (because it is not implemented in all of our ~200 mikrotik routers ); but I read a article about it in German journal ct 20/2013 (page 184/189) and they had quite good experiences with it (on a DSL connection).
The basic principle of it is: it will observe the resting time of packet that are in the queue; once it detects that packets of a certain connection are longer than e.g. 100ms in the queue, it will drop all future packets of this connection (some additional conditions are a full queue and more…).
Same here. We have several hundreds of Mikrotiks (and growing) connected to dsl lines. Because of the non guaranteed nature of dsl we are desperately trying to all the time to modify queues as the growth of the dslam changes, but codel is going to allow dynamic queues for these lines. MT are you guys taking this seriously as a feature request yet?
If a MT is Connected to a dsl line would it require something with a very small buffer as well? (Since it would need to know the queue has run out, so unless the modem is in a MT, would this work?
I’ll ask them this question in person on next mum.