Hello all,
I have recreated this problem with another script: I took examples/tcp/tcp-variants-comparison.cc and made a few minor changes:
1. Increased the bandwidth to 100Mbps
2. Delay is now ~20ms instead of ~45ms
3. mtu_bytes increased to 1000 bytes (it was quite low before, only 400 bytes)
4. TCP variant tested is H-TCP (because I am very familiar with the dynamics and know what the cwnd should look like)
5. Changed the queue size to a constant 1500 bytes (in the original script, it's a function of bandwidth and delay)
6. And finally, and this is what caused the cwnd to grow without bound again (I know this because I made each change one by one): I uncommented the lines that specify the buffer sizes, as follows:
//Config::SetDefault ("ns3::TcpSocket::RcvBufSize", UintegerValue (1 << 21));
//Config::SetDefault ("ns3::TcpSocket::SndBufSize", UintegerValue (1 << 21));
I left everything else untouched. I am attaching the script and its cwnd output file here. I also plotted the cwnd file, in cwnd_output.pdf. Observe the bizarre growth of cwnd over the 100 secs: it grows linearly with no upper bound, no losses, all the way up to about 1.25Gbits by simulation's end. This looks like a (serious) bug to me, i.e. this sort of cwnd growth should not be observed under any circumstances, even if you don't specify the buffer sizes. After doing some searching, I saw that there is an old bug that for some reason caused buffer sizes to be infinite in some cases. It was fixed a few years ago, but perhaps it's somehow made a comeback?
Anyone have thoughts on this?
Thanks,
-NS3 user