I am curious if those of you fiddling with RED have been setting q_weight in your simulations and papers, overriding the incorrect ns2 default?
Similarly, those of you testing ARED, making sure the adaptive parameter is really on? ... and if someone can come up with a way of a validating correct configurations for RED were used in every paper that used it in ns2 for the last 12 years, I would love to hear it. ---------- Forwarded message ---------- From: Tom Henderson <t...@tomh.org> Date: Sun, Dec 21, 2014 at 12:07 PM Subject: [Ns-developers] proposed changes to ns-2 RED code To: ns-developers list <ns-develop...@isi.edu>, "ns-us...@isi.edu" <ns-us...@isi.edu> Cc: "Mohit P. Tahiliani" <tahiliani.n...@gmail.com> If you are using ns-2 and RED queues, please help us to evaluate the following proposed change. Mohit Tahiliani has been working on Adaptive RED in ns-2, and has patched a few issues, including: - use of ARED in wireless networks leads to floating point exception - the default value of Queue/RED set q_weight_ -1 is incorrect - Queue/RED set adaptive_ 0: this must be set to 1, otherwise "max_p" parameter never adapts. While the default values of some parameters (such as thresh_, maxthresh_, q_weight_) were changed in 2001 to make ARED as the default RED mechanism in ns-2, those of others parameters were left unchanged. The resulting code defaults to something that is neither RED nor ARED; this patch will fix the default to ARED. The proposed patch is in a tracker issue here: http://sourceforge.net/p/nsnam/patches/25/ I'm testing release candidates for ns-2.36, which are described here: http://nsnam.isi.edu/nsnam/index.php/Roadmap Mohit's patch is _not_ part of the first release candidate. If we move forward with it, it will be merged as part of a later release candidate. So to test it yourself, I recommend to download the release candidate and apply the patch there. I've been through a couple of review cycles with Mohit on this patch. We'll use lazy consensus to try to decide on its inclusion. Unless we hear from the community that these changes should be reconsidered (let's set a date, such as by January 10), I plan to work with Mohit to evaluate the ns-2 validate trace changes and update the traces, and commit this to ns-2 prior to the ns-2.36 release. Of course, even if you support this, it would be nice to hear positive feedback if you read over this patch, test it, and like what you see. Thanks, Tom -- Dave Täht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks _______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm
