These days, doing proper packet scheduling nowadays is probably a better alternative to AQM than approximated solutions such as RED and many many variants that appeared in academic papers.
RED was designed at a time when implementing packet schedulers was expensive (theory was not completely there yet, firewalls were not widespread, etc.). Now there are fast packet scheduler implementations available. Our own QFQ [1] is distributed with the official FreeBSD and Linux sources, and runs reasonably fast even on an OpenWRT device (remember that AQM needs to act at the bottleneck [2], which is mostly your DSL router for upstream traffic).
You could really try it out easily, and if you are willing to set up a few dummynet pipes [3] (FreeBSD/Linux/Windows) you don't even need to act on the DSL router.
References:
[1] http://info.iet.unipi.it/~luigi/qfq/ but the code is already part of recent FreeBSD and Linux distributions
(edited: and even on OSX you'll find an older but similar scheduler as part of ipfw+dummynet), you just need to load the relevant modules.
[2] there were, long ago, some proposals/products which did ack pacing on the reverse path to do cong.control on the forward path. I think it is tricky to make them work.
[3] http://info.iet.unipi.it/~luigi/dummynet/ .
You can set two pipes with a bandwdith slightly below that of the DSL link, so you can control the bottlenecks. How can you know what is the bottleneck bandwidth is a different story. You could look at the negotiated speed on the modem, often available through the web pages, but probably you'll have other bandwidth caps elsewhere. You could try to run some of the BW probing apps to some nearby host, hoping that
the bottleneck is your local DSL, and dynamically reconfigure the pipes accordingly. I have not tried this yet.
Shaping the link at the source works as long as you're the only computer along the bottleneck link. Once there are varying number of other sources competing for the bottleneck, determining the "rate" is hard (which is what congestion control algorithms do!)
RED was designed at a time when implementing packet schedulers was expensive (theory was not completely there yet, firewalls were not widespread, etc.). Now there are fast packet scheduler implementations available. Our own QFQ [1] is distributed with the official FreeBSD and Linux sources, and runs reasonably fast even on an OpenWRT device (remember that AQM needs to act at the bottleneck [2], which is mostly your DSL router for upstream traffic).
You could really try it out easily, and if you are willing to set up a few dummynet pipes [3] (FreeBSD/Linux/Windows) you don't even need to act on the DSL router.
References:
[1] http://info.iet.unipi.it/~luigi/qfq/ but the code is already part of recent FreeBSD and Linux distributions (edited: and even on OSX you'll find an older but similar scheduler as part of ipfw+dummynet), you just need to load the relevant modules.
[2] there were, long ago, some proposals/products which did ack pacing on the reverse path to do cong.control on the forward path. I think it is tricky to make them work.
[3] http://info.iet.unipi.it/~luigi/dummynet/ . You can set two pipes with a bandwdith slightly below that of the DSL link, so you can control the bottlenecks. How can you know what is the bottleneck bandwidth is a different story. You could look at the negotiated speed on the modem, often available through the web pages, but probably you'll have other bandwidth caps elsewhere. You could try to run some of the BW probing apps to some nearby host, hoping that the bottleneck is your local DSL, and dynamically reconfigure the pipes accordingly. I have not tried this yet.