Ugly stuff, this … but:
it seems the bug of ns-3’s ever-growing cwnd only happens with relatively large bandwidth*delay product values, or in particular with large delay (e.g. caused by a long queue). And, it always seems to be the same: slow start, followed by immediate reductions, and then after growing again in congestion avoidance, cwnd grows endlessly.
I decided to check, for my own test scenarios, if this happens - to be able to filter out the cases with the bug.
If, after reducing cwnd after reaching its max. value (which would be in slow start), it exceeds the max value again, something is really weird, and I call this a bug.
I made a minor change to my “michaelssim” script to make this check, which I’m attaching. I call it “bugfinder”.
I’m also attaching:
- wafrun.sh, which allows to call waf more easily in a loop (avoiding a problem due to the “ symbols in bash - good for bash beginners like me)
- a perl script that runs wafrun for all my parameters, just to show how that works
- bugfinder-plotcwnd, which is the same as bugfinder, but prints out the cwnd, so it helps for a quick check if a bug was real or not.
Note that getting neither an indication of a bug nor a comment like this one:
***
Reducing cwnd from 101138 to 48441 at s=24.967; no bug expected.
***
may mean that the simulation was too short, and it’s worth looking at the cwnd too
Maybe you want to run this for the fixed capacity and delay values of the evaluation suite tests too, just to see if everything is okay… but I guess when you add more traffic and more loss reactions then the behavior becomes normal anyway.
A lot of wild guessing here… but what else can we do, except really detecting and fixing this bug… :-(
Cheers,
Michael
<bugfinder-plotcwnd.cc><bugfinder.cc><run_bugchecker_loop.sh><wafrun.sh>