Problems with tcp-bulk-send Wireless

[M.S. krishna deepak]

Hi,

Recently I have changed from ns-3.20 to ns-3.22. I have written an example for using tcp-bulk-send in wireless in ns 3.20 and I got a throughput of 23Mbps.

After changing to the latest version, the throughput has suddenly decreased. I am clueless. Please somebody help me. Here is the example

Thank You,

Krishna Deepak

[Konstantinos]

Hi,

There have been some changes in the TCP implementation introduced in ns3.22. Also, the default value of the `Speed` attribute of ConstantSpeedPropagationDelayModel was changed from 300,000,000 m/s to 299,792,458 m/s (speed of light in a vacuum), causing propagation delays using this model to vary slightly.

For more information, I would suggest you to look at the Changes (http://code.nsnam.org/ns-3.22/raw-file/7e569f59f476/CHANGES.html)

Regards,

K.

[Tommaso Pecorella]

Your script throws this assertion:

"Could not open trace file /home/mskd96/Downloads/ns-allinone-3.20/ns-3.20/scratch/wireless.ns_movements for reading, aborting here"

Please provide ALL the required files if you need assistance.

T.

[M.S. krishna deepak]

I am attaching that file

[M.S. krishna deepak]

Hi,

The throughput has decreased to something like 13 Mbps. There should be something happening other than the speed I think.

Thank You,

Krishna Deepak

[Tommaso Pecorella]

Hi

three words: you are right.

This is the RTT plot,showing that there is an evident difference between the two versions.

The good news is that we did not introduce the bug in 3.22.

The bad news is that we did something in 3.21.

We'll have to investigate and see if the bug is now or we did remove one.

Cheers,

T.

[Hajime Tazaki]

Hi Tommaso,

thanks and nice investigation !
is the legend 3.22 instead of 3.20 ?

plus, I would recommend to you (us ?) two things.

- bisect the first commit that introduces the RTT change
hg bisect is your friend ;)

- if the commit is a regression (introducing non-ideal
behavior), extending the bisect script to regression test
(of ns-3) with the ideal behavior would be helpful to
avoid future regressions.


-- Hajime

At Tue, 10 Feb 2015 00:12:08 -0800 (PST),
Tommaso Pecorella wrote:
>
> [1 <multipart/alternative (7bit)>]
> [1.1 <text/plain; UTF-8 (7bit)>]

> Hi
>
> three words: you are right.
>
> This is the RTT plot,showing that there is an evident difference between
> the two versions.
> The good news is that we did not introduce the bug in 3.22.
> The bad news is that we did something in 3.21.
>
> We'll have to investigate and see if the bug is now or we did remove one.
>
> Cheers,
>
> T.
>

> <https://lh3.googleusercontent.com/-8daFm58SE_E/VNm8sbM02WI/AAAAAAAAEoQ/tWzsDpZfBZ4/s1600/RTT.png>

> --
> You received this message because you are subscribed to the Google Groups "ns-3-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to ns-3-users+...@googlegroups.com.
> To post to this group, send email to ns-3-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/ns-3-users.
> For more options, visit https://groups.google.com/d/optout.
> [1.2 <text/html; UTF-8 (quoted-printable)>]
>

[Tommaso Pecorella]

Hi Hajime,

no, the legend is right. The change happened between 3.20 and 3.21. We did heavy changes in 3.22 in the RTT codebase, but they were all tested against existing (3.21) data. As a result, 3.22 and 3-dev are in line with 3.21.

About bisection, I totally agree. I'm trying to figure out what's the module responsible for these changes (could be wifi, could be internet, could be other). It turns out it's internet.

Now all we have to do is bisect the changes involving the internet module (I have a rough idea) and investigate.

Cheers,

T.

[Tommaso Pecorella]

Ok, I found a trail.

Place this line at the simulation start to revert to the old behaviour (more or less). Works in 3.21, 3,22 and 3-dev.

Config::SetDefault ("ns3::TcpSocketBase::WindowScaling", BooleanValue (false));

T.

[Tommaso Pecorella]

For the records, the problem (if it's a problem) is NOT in the RTT code or in the TimeStamp option. The RTT is just a way to show what's happening.

This is the plot of the RTT in 3.20 and 3-dev without the WindowScale option.

T.

[Nat P]

Il giorno martedì 10 febbraio 2015 10:19:32 UTC+1, Tommaso Pecorella ha scritto:

For the records, the problem (if it's a problem) is NOT in the RTT code or in the TimeStamp option. The RTT is just a way to show what's happening.

 Maybe, could it be a buffer-related issue? I.e. What happens if you set
the TcpRxBuffer equals to the buffer in wireless model used?

Because, you know, with window scaling you have more data in flight, and
with a very big buffer somewhere, you'll introduce a queuing delay,
which reflects over the RTT.

Nat

[Tommaso Pecorella]

For the records, this thread is going to be closed. I opened two bugs about this problem:

https://www.nsnam.org/bugzilla/show_bug.cgi?id=2067

https://www.nsnam.org/bugzilla/show_bug.cgi?id=2068

please check them periodically in order to see if they are closed (for sure I'm going to forget to update this thread).

Until (at least) the first one is fixed, the suggestion is to disable the TCP Window Scaling:

Config::SetDefault ("ns3::TcpSocketBase::WindowScaling", BooleanValue (false));

or to set the sender and receiver buffer sizes to something larger than the largest window size (i.e., a LOT thanks to the window scaling).

We hope to have a patch soon, but the bug is more elusive than one may think.

The bug affects ns-3.21 and ns-3.22.

Thanks,

T.