TCPNewReno too passive implemented in NS3? Or too aggressive in Omnet++?

[Kurt Erikson]

Hi everyone,

I'm working on a project which explores new AQMs.


I wanted to reproduce my results I got using Omnet++ a couple of years ago but this time using NS3.
Tthe results looked in some key features a lot different.

Thus i set up a Simulation on NS3 and Omnet++ and tried to make it as equal as possible changing as little as possible default values.

My Setup:
TCPNewReno (I would prefer a version which is more up-to-date, but I think neither Omnet++ or NS3 provide a better version)

client -----100Mbps 0.1ms-----> router -----10Mbps 5ms-----> server

Router: DropTailQueue, 20pkts
Link: PPP
MaximalSegmentSize= 533byte
Sack: Off (required by Omnetpp)
AdvertisedWindow: 65535  (this is a NS3 Default which i gave it omnet++, otherwise omnet++s results look terrible)
I'm using "inet" on Omnet++
Version: NS3-dev;  Omnet++ 5.1



My Results:
I attached both congestion window plots.


Note that the NS3(purple) simulation has a simulation-time of 250 seconds and Omnet++(blue) only 4seconds -> y-Axis
The x-axis show byte


A view different i noticed the most and many questions:

NS3 Drops down to 0 and requires 80seconds to get up to ca 70000bytes
Is this drop too much and the 80seconds to get up to0 long? (Since Omnet++ drops only once down to 0 and requires only 0.4 seconds to get up)

Another big difference are the spikes Omnet++ has. Is this normal behavior?


Does anybody know which one is more realistic?
Do i have to change something at the ns3 to make it more aggressive?
Do i want it more aggressive or is this normal behavior and Omnet++ is totally off?
 
The last question is very important since i think this is the difference which changes my result. If i make NS3 more aggressive i think will get the same results as i got using Omnet++, but do i want to do this?
I talked with a colleague a lot about the "passive" TCPNewReno which is implemented in NS3, since it changes both our experiment results in a way which confuses us. (He works on something else)


With kind regards
Kurt

[Tom Henderson]

Kurt, would you mind retrying your experiment on the latest release
(ns-3.26)? ns-3-dev has an open bug that NewReno is not actually
enabled correctly at the moment:
https://www.nsnam.org/bugzilla/show_bug.cgi?id=2649

But with respect to ns-3.26, ns-3 should be performing NewReno-compliant
congestion control by default. We have verified this by having ns-3
interoperate with a Linux kernel implementation and examine the recovery
process in detail. The Network Simulation Cradle was used for this
testing, and the ns3-tcp-cwnd test suite contains the test code for this.

- Tom

[Kurt Erikson]

Hi,
Thank you for this quick response,
It's 0 o'clock where I live, I thought I would get a response when I get up tomorrow.
I will do what you said the first thing tomorrow!
Thank you very much! What you wrote sounds legit.

With kind regards,
Kurt

[Kurt Erikson]

Hi,
I did what you asked for and attached the file.

The results look much better now .

But the CongestionWindow needs 60seconds to reach another Spike, this feels way too long?

Furthermore am I still able to use the ECN-Implementation from Shravya Kudki Srinivas?
https://codereview.appspot.com/314790043/

Thank you for your response it already helped to clear some things out,


With Kind regards
Kurt

[Tom Henderson]

On 04/25/2017 12:23 AM, 'Kurt Erikson' via ns-3-users wrote:
> Hi,
> I did what you asked for and attached the file.
>
> The results look much better now .
>
> But the CongestionWindow needs 60seconds to reach another Spike, this
> feels way too long?

It seems like your round trip time must be very large for some reason
(slow link or lots of propagation delay).

>
> Furthermore am I still able to use the ECN-Implementation from Shravya
> Kudki Srinivas?
> https://codereview.appspot.com/314790043/

> <https://codereview.appspot.com/314790043/>

If you patch your ns-3 installation, then yes, you can use this (this
ECN patch is in final review for merging to ns-3-dev). However, this
ECN TCP patch will not apply properly to the ns-3.26 release.

[Kurt Erikson]

Hi Tom,

You are right, I set the Channel router -> server channel only to 1Mbit/s
The results look with 10Mbit/s much better  I attached both). Im surprised of how much of an impact this has.

Thank you very much for your help! I'm glad i switched from Omnet++ to NS3

With kind Regards
Kurt

[Kurt Erikson]

Hi Tom,

Sorry if i'm a little annoying but I am a little scared that I spend the last 3 months working and that I can't finish my project now.

The only working TCP is on NS3.26 BUT the ECN-Version ( which i already used in the dev Version ) is only for the Dev version. Thus I can't use it in NS3.26. Thus I can't use the correct TCP-NewReno together with ECN?

I spend some hours trying to include the ECN- patch into my NS3.26 Version but I failed. Is it worth to keep trying or are there larger changes required ( which will maybe resurrect the TCP-Bug ) ?

Or will the NS3-dev TCP-Bug patched in the next day / weeks, are there any informations about this bug?


With kind regards,

Kurt


Am Mittwoch, 26. April 2017 05:51:34 UTC+2 schrieb Tom Henderson: