"If something isn't broke, don't fix it"
Eh, the problem here is, something *is* broke—and CoDel fixes it. That something is TCP's queue management, and the problem stems from the fact that today's routers are equipped with tons of memory because it's so cheap. Meanwhile, the current active queue management systems are horrible at doing what they're supposed to do, and they allow very large queues to build up in memory. With so much memory for queues, and horrible active queue management systems, the router keeps adding to its queue, and it stays full, instead of doing what TCP was designed to do: drop packets.
This is not a problem with short downloads. Hell, it's not even a problem with long downloads… as long as you're doing nothing else. But if you start a long download and it's going continuously at full speed, try starting a second download and watch it struggle to do anything, because the first download is hogging the queue. It may or may not ever get up to a decent speed. Even try loading a simple web page while that file is downloading, and chances are it will load slower much slower than it should. This doesn't just affect downloads… uploads are affected, too.
Packets are meant to be dropped by design; it's the way TCP regulates data transfer rates. If you have a humungous, always-full buffer that never drops packets, you might be able to stream some HD video on your TV, but don't even dare try to use VoIP or play some game on Xbox Live at the same time… the bufferbloat will destroy your latency. And this is exactly what CoDel fixes.
Unfortunately… CoDel requires something like a 3.5 kernel, maybe at least 3.3, so unless Tomato eventually evolves to support it… well, we're shit out of luck. I tried the version of RAF tweaked for reduced bufferbloat at ordorica.org and the network performance when downloading one or more large files was very impressive. Unfortunately, it's based on an old version of Tomato, so I decided to upgrade a few days ago to the latest by Shibby, and it unfortunately doesn't have bufferbloat protection (the difference in network performance is like night and day… the ordorica version performed much better under heavy load).
On the other hand, the overall snappiness of the router itself (not its network capabilities; I mean its web UI and similar things) has been vastly improved in the switch, and I'm pretty sure the only reason why is because I'm using a k24-based version of Shibby, while the reduced-bufferbloat version was k26-based. And I'm running a weak router, a WRT54GL, overclocked at 250 MHz. An up-to-date Tomato with bufferbloat protection tweaks and a k24 version would be awesome. Too bad from what I can tell, Toastman didn't see any reason to add it (his testing methods seemed questionable to me; not sure he fully understands the problem), and I haven't found anything about it by Teaman or Shibby in various Google searches on the subject.