| Hi,
Removing the TEB code altogether was fine. However, the diagram that you see is nonsense - a cwnd of up to 4 * 10^7 ? It should not exceed the BDP + queue, altogether it shouldn’t ever become much more than 137077 bytes (as per the calculation below). That’s exactly the nonsense I’m talking about - you’re seeing the bug. Or, no, in fact, you’re probably experiencing *two* bugs :-) if you run this in plain ns-3 without fixing anything:
I documented this at:
"To get the correct output, you need to comment some stuff in the IPv4AddressHelper, as explained here. Alternatively, you can just take my ipv4-address-helper.cc file and put it in your ns-3.27/src/internet/helper directory (overwriting the one that's there)." (there’s a link to the file on the page)
and “here” in the first sentence points here:
This is super awkward: unless you do this trick to the IPv4AddressHelper, you get what seems to be an endless queue installed.
So, first make that queue a normal one by commenting a few lines as described at stackoverflow, and then you can should be able to experience the other bug - again endless cwnd growth, but probably only in the case of buffer = 29 packets.
Cheers, Michael
On Jan 20, 2018, at 9:49 PM, Francesco Gringoli <
" class="">
> wrote:
Hi Michael,
I’m trying to replicate the simulation but I am not sure about where to find the TEB code. So I disabled it completely and this is what I get when running a simulation with 28 packet in the queue (blue line) or 29 (red line). They match. By the way, should I expect losses in this configuration? The cwnd increases forever meaning that there are no losses (and cwnd - always in CA - is limited by the receiver window before sending I guess).
-Francesco On 20 Jan 2018, at 18:31, Michael Welzl <
" class="">
> wrote:
Dear all, + Francesco because he has experience with ns-3, and this is 100% an ns-3 thing, not related to our code at all: I’m seeing some problems with my evaluations because of a strange bug in ns-3. This bug prevents the congestion window from growing above a value of approximately 137k bytes, it seems. I’m attaching an example script. Here TEB (my code) is disabled, and the setup is plain and simple: init cwnd = 3 8 Mbit/s bottleneck capacity 100 ms RTT queue length: 28 packets From the parameters above, the BDP should be 100000 bytes, i.e. 66.66 packets (packets are of size 1500). Add to this the queue length of 28 packets, and we get a max. cwnd of 94.66 packets. Expressed in segments (of size 1448), this is 137077.33. This is the “good case” plotted below. Now, add ONE packet to the queue, making it 29 packets long => and you get the other plot (“bad case”). I repeat, this is not my own code or anything - just normal ns-3, and I think it happens whenever the cwnd exceeds a certain length. This gets really disturbing in my testbed experiments, I have to tune them to limit the max cwnd :( Does ANYBODY have a solution? I’d be happy! And the ns-3 people should be happy too ! Cheers, Michael <michaelssim.cc><good_case.png><bad_case.png>
— — Francesco Gringoli, PhD Assistant Professor Dept. of Information Engineering University of Brescia via Branze, 38 25123 Brescia ITALY Ph: ++39.030.3715843 FAX: ++39.030.380014 WWW: http://netweb.ing.unibs.it/~gringoli
|