any need to consider buffer bloat with Asus fw of any origin?

[jeff_d]

Hello,
While doing a little light reading of comments related to Net Neutrality and Internet speeds/performance, I saw something that seems more technically germane to wonder about with our lovely little Asus routers and xxxWRT firmwares.

There is a page, https://www.bufferbloat.net/, describing an effort to improve network performance with one product being CeroWRT. A rudimentary search on these forums finds a few slight mentions of same, but none for months if not over a year.

I'm curious if the CeroWRT (currently only released for WNDR3x00 rtrs) has any future bearing on either Merlin or stock DD-WRT?

Also, if Merlin or any others of a similar technical level have a pointer or opinion to a good summary as the future of any such feature (refined buffer handling algorithms) and the possible need or a possible "never going to happen with our chips" for Asus routers (N66, AC66, AC68 as prime examples...roundly), I'm hoping to learn more and or benefit this group by bringing such info into this forum.

Thanks in advance,
Jeff

 

[dtaht]

I guess we're not doing a good job of SEO!?

The core bufferbloat-fighting innovations (notably "fq_codel") in cerowrt landed in openwrt last year, and have since landed in the linux mainline kernel and nearly every up to date distribution (such as RHEL 7, fedora 18 and later, and ubuntu 13.x). On the embedded front it's in the dd-wrt, ipfire, gentoo, arch, shorewall, and other firewall/home router soltuions and it (most recently) landed in ubiquiti's "edgerouter" devices. It is remarketed as part of "streamboost", and probably part of multiple buffalo and tp-link products by now.

Along the way, the docsis 3.1 standard got written with support for the pie AQM for cablemodems, the ietf formed an "aqm" working group, and there are multiple internet drafts in progress for standardization.

If the router you are talking about is based on a linux 3.6 or later kernel, or uses the "wireless-backports" patchset (most do) it probably has support for fq_codel. A decent qos script may or may not exist for it, but plenty of examples exist on the intertubes.

Most of the activity on cerowrt takes place on the mailing lists, not the web site, (with the exception of bug tracking), the same goes the the ietf aqm mailing list.

An example of what cerowrt's "SQM" qos system can do is here:

http://snapon.lab.bufferbloat.net/~cero2/jimreisert/results.html

See multiple howtos on the bufferbloat website for "smart queue management" or look over openwrt's qos-scripts, or the more recent stuff over at dd-wrt...

Some internet drafts:

https://datatracker.ietf.org/doc/draft-nichols-tsvwg-codel/
http://tools.ietf.org/html/draft-hoeiland-joergensen-aqm-fq-codel-00
https://datatracker.ietf.org/doc/draft-white-aqm-docsis-pie/

So, development on cerowrt on it's one platform continues, (we are close to a stable release, now that openwrt barrier breaker is freezing), but the core technologies we have worked on are now nearly everywhere and available on nearly everything.

I'd certainly like to know if the asus on the merlin is capable of fq_codel.

 

[RMerlin]

Anything that modifies the skbuf structure (such as the IMQ packet classifier just to mention one example) is out of the question for Asuswrt or Asuswrt-Merlin, as it would prevent loading closed source modules such as ctf.ko or wl.ko.

Same goes for a lot of things which modifies the core Linux networking.

 

[jeff_d]

generously helpful (& so maybe not SEO issue )

Well, I am suitably impressed. Thank you both Merlin and Dave Taht for replying.

@Dave: I will followup more with the links you provided (some followed already) and learn what I can and see how much QoS settings can help in what manner they may.

I was going to have to dig to learn (my limitation, no other) about what kernel level AsusWRT and MerlinWRT currently include, but obviously to an extent Merlin's answer pre-empt's some of the urgency and answers your question.

@Merlin: Are the mentioned closed source dependencies (ctf.ko, wl.ko) permanent as your brevity may imply? Or is there a longer (within reason) range plan worth mentioning that implies things may change?

To heck w/Netflix, Youtube and such, your knowledgeable replies are the kind of real value and power for which I value the Internet over the decades!

-Jeff

 

[RMerlin]

@Merlin: Are the mentioned closed source dependencies (ctf.ko, wl.ko) permanent as your brevity may imply? Or is there a longer (within reason) range plan worth mentioning that implies things may change?

The only real solution would be if Broadcom and/or Asus were to also include these kernel-level changes in their Kernel, and start compiling ctf (that's the HW acceleration kernel module) and wl (that's the wireless driver) with these kernel changes applied. Otherwise, nothing that can be done from my end.

Tomato recently ran into that issue - the IMQ module they used for their QoS isn't enabled in the kernel used for ARM devices, so they can no longer use the same module for handling QoS on ARM-based routers. And myself I had a similar issue when I started merging the new DPI modules into the firmware - they didn't like that I was enabling certain kernel options such as IPSec support, forcing me to disable these to go back to a set of kernel options that was closer to what is used by both Broadcom and Asus.

 

[dtaht]

it's not clear

what kernel are they using?

All the innovations over the last couple years on the qos/aqm/packet scheduling front are part of the bog standard linux kernel now. Rather than imq, openwrt and cerowrt's qos mechanisms are built around the linux standard ifb module (not imq) for inbound management, and the rest uses the tc and iptables mechanisms for classification and qdiscs on both inbound and outbound qos.

If the relevant modules are built, you are mostly done.

It helps to have driver support for BQL on the ethernet side, which is usually about a 7 line patch to that driver. It is necessary to have a non-buggy htb, which arrived in linux 3.11 and was backported to multiple stable releases. fq_codel, as I already mentioned, became part of the mainline as of linux 3.6 and was provided as part of the compat-wireless tree and backported as far as 2.6.32.

so, does the current merlin firmware have this stuff? what kernel is it on?

 

[RMerlin]

what kernel are they using?

All the innovations over the last couple years on the qos/aqm/packet scheduling front are part of the bog standard linux kernel now. Rather than imq, openwrt and cerowrt's qos mechanisms are built around the linux standard ifb module (not imq) for inbound management, and the rest uses the tc and iptables mechanisms for classification and qdiscs on both inbound and outbound qos.

If the relevant modules are built, you are mostly done.

It helps to have driver support for BQL on the ethernet side, which is usually about a 7 line patch to that driver. It is necessary to have a non-buggy htb, which arrived in linux 3.11 and was backported to multiple stable releases. fq_codel, as I already mentioned, became part of the mainline as of linux 3.6 and was provided as part of the compat-wireless tree and backported as far as 2.6.32.

so, does the current merlin firmware have this stuff? what kernel is it on?

IFB is not enabled in Asus's kernel. Chances are that enabling it will cause the same symbol mismatch/struct incompatibilities as enabling IMQ.

MIPS devices are on 2.6.22.19, and ARM are on 2.6.36.

The kernel is chosen by Broadcom, so it's not something Asus (or myself) have any control over.

 

[dtaht]

sigh

That's too bad. It otherwise looks like good hardware. I sure hope that they've, or you've handled the hundreds of CVEs against older kernels and software.

https://www.schneier.com/blog/archives/2014/01/security_risks_9.html

 

[drawz]

It is remarketed as part of "streamboost", and probably part of multiple buffalo and tp-link products by now.

Unfortunately, Streamboost is the only current commercial implementation with fq_codel that I'm aware of. Everybody else is stuck on much older kernels and probably hasn't even heard of the terms "bufferbloat" or "fq_codel." Buffalo *might* have support in their DD-WRT equipped routers if they're using current versions, but given that DD-WRT hasn't had a "stable" release in years, I'd be surprised.