TCP/ rrt-estimator implememntatation on NS-3.13

[Mauro Vidotto]

Hi,

I was using NS to test TCP congestion control variants. Since last week decided to migrate from NS-3.10 to NS-3.13.
On NS-3.13 I am having several problems with the evolution of the TCP's congestion window (the results are totally different in NS-3.10 and NS-3.13).
As far i could see when there is high delay (250 ms or more) on the simulated network TCP is not able to take RTT samples, and due to this is not able to calculate RTT estimation and the RTO (congestion window is restarted to 1MSS very often).

The network i have been simulating is simple:

n0  ============== n2 ----------------  n2 ==============  n1
              csma                       p2p                       csma

n0 is the source node (onoffapplication)
n2 and n3 acts as router and implements droptail queue , p2p delay is set to 250ms
n3 is the sink node (sink application)

Attached to the email are the graph of the congestion window on n0 for NS-3.10 and NS-3.13

Is there any bug related to RTT calculation for NS-3.13?

Regards
Mauro Viudotto

[Tom Henderson]

I created bug 1351 to track this issue:
https://www.nsnam.org/bugzilla/show_bug.cgi?id=1351
Thanks for reporting it.

[Tommaso Pecorella]

Hi,

have you tried to set the MinRTO attribute of the class
ns3::RttEstimator to something bigger than 200ms ?

I suspect that it's the reason why your RTO estimation is trashed.

Also, mind that ns-3.13 does implement 4 different TCP flavors:
http://www.nsnam.org/docs/doxygen/classns3_1_1_tcp_socket_base.html
I don't remember if this was supported in 3.10.


Cheers,

Tommaso

[Mauro Vidotto]

Hi Tommaso,

Today tested your suggestion, I set MinRTO to 1 second as a test. With this value the problem does not appear. But if the the delay of the network is increased again to a value higher that the MinRTO the issue is again back.
NS-310 and NS-3.13 have the same default value for MinRTO, 200ms. NS-3.10 can get the samples of the RTT, calculate the RTT estimate and the RTO correctly while NS-313 can not (at least this is what i could see ).

I simulated the same scenario using TcpReno and TcpNewReno, both of them have the same problem (the window does not increase in more than 2 MSS). The problem seems to be in a module used by any of TCP variants.

I was working in the implementation of TcpWestwood, so i had to modified part of the code. I realized that from NS-3.10 to NS3.13 the type of  the variable  est, variance minrto was changed from Time to int64x64_t, do you know the reason of this change?

I suspect that maybe the est variable is not being correctly initialized when the rtt-estimator is created (InitialEstimation attribute)

Regards
Mauro Vidotto

--
You received this message because you are subscribed to the Google Groups "ns-3-users" group.
To post to this group, send email to ns-3-...@googlegroups.com.
To unsubscribe from this group, send email to ns-3-users+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ns-3-users?hl=en.

[Mauro Vidotto]

Hi,

I check again the code of rtt-estimator and i think i found the problem:

The value of the variable est is initialized correctly. After the initialization the method Reset is called.
On NS-3.13 the est variable gets the value 1 (1 nano second), and on NS-3.10 gets the value 1 Second ( m_est=Seconds (1.0);) . The difference in the behavior of NS-3.10 and NS-3.13 is caused by the difference in this reset method.

When the delay of the network was lower than the MinRTO this problem was not evident as the RetranmitTimeout method returns the maximun between the calculated value and the MinRTO.

void RttEstimator::Reset ()
{ // Reset to initial state
  next = 1;
  est = 1; // XXX: we should go back to the 'initial value' here. Need to add support in Object for this.
   history.clear ();         // Remove all info from the history
  nSamples = 0;
  ResetMultiplier ();
  NS_LOG_LOGIC ("  RttEstimator:Reset");
}

Regards
Mauro Vidotto

[Tommaso Pecorella]

Hi Mauro,

Time does store its data into an int64_t. I suspect (but I'm not sure)
that the change to those variables is to allow a proper time
calculation. One usual mistake is to assume that, for example, one can
multiply two Time values, but this leads to overflow errors. The Time
class is not really made to operations on it beside simple sums and
subtractions. Plus people unaware of its underlying data type always
mess up.

It could even be that ns-3.10 was buggy and 3.13 is not :)

About the MinRTO, we misunderstood at it. MinRTO is the Minimum RTO
(i.e., the default one), used just in the
RttMeanDeviation::RetransmitTimeout () function. Now, why should we
bother about it then?

Simple: if you do NOT receive packets, you don't have any estimation,
so the estimate is the default value (very low) and the MinRTO kicks
in. All the packets will be retransmitted (you didn't receive any ack
in time, isn't it?) and your estimation will never be available
(because we don't calc the RTT on packets who have been
retransmitted).

It's all in the RttMeanDeviation class code.

Satellite links are a pain in the ***, isn't it? Ah, well, if it can
make you happier, they're even more a pain when you have to use them
for real :)

Anyway, take a closer look at the RttMeanDeviation class. I think that
in order to make a proper Westwood (or any other TCP flavor) you'll
have to modify heavily also the way to measure the RTO.

Cheers,

Tommaso

On Jan 31, 1:04 am, Mauro Vidotto <mauro.vido...@gmail.com> wrote:
> Hi Tommaso,
>
> Today tested your suggestion, I set MinRTO to 1 second as a test. With this
> value the problem does not appear. But if the the delay of the network is
> increased again to a value higher that the MinRTO the issue is again back.
> NS-310 and NS-3.13 have the same default value for MinRTO, 200ms. NS-3.10
> can get the samples of the RTT, calculate the RTT estimate and the RTO
> correctly while NS-313 can not (at least this is what i could see ).
>
> I simulated the same scenario using TcpReno and TcpNewReno, both of them
> have the same problem (the window does not increase in more than 2 MSS).
> The problem seems to be in a module used by any of TCP variants.
>
> I was working in the implementation of TcpWestwood, so i had to modified
> part of the code. I realized that from NS-3.10 to NS3.13 the type of  the
> variable  est, variance minrto was changed from Time to int64x64_t, do you
> know the reason of this change?
>
> I suspect that maybe the est variable is not being correctly initialized
> when the rtt-estimator is created (InitialEstimation attribute)
>
> Regards
> Mauro Vidotto
>

[Tommaso Pecorella]

For the records:

Mauro found a real bug, and it will be fixed soon in ns-3-dev.

Anyone having troubles with TCP and its performances should upgrade to
ns-3-dev or apply the fix to their environment.

Cheers,

T.