Linear TCP Cwnd increase during Slow-Start phase

[Raymond]

Dear ns-3 community,

  I am currently running a basic TCP script similar to that of exampe/tutorial/fifth.cc. I notice that during the slow-start phase, the congestion window size Cwnd actually increases (as far as I can see) linearly rather than exponentially. My understanding is that if we delay the maximum number of receipt packets between sending an ACK to more than 1, it would slow down the Cwnd.

  However, I have set the above parameter e.g. DelAckCount in tcp-socket.cc to various values, including 0, 1, 2, ..., etc., but the Cwnd still seems to increase linearly. Some basic parameters I used are

• ns3::TcpL4Protocol::SocketType = TcpReno
• channel data rate = 1Mbps
• Source rate = 10Mbps
• channel error rate = 1e-8
• ns3::TcpSocket::DelAckCount = 0, or 1, or 2
• point-to-point device (tutorial/fifth.cc)
  

  For your convenience, I have plot a figure to illustrate this. It might just be something basic about TCP which I have missed. I would very much appreciate your help on this.

Many thanks,

Raymond 

[Nat P]

Il giorno lunedì 9 novembre 2015 13:28:27 UTC+1, Raymond ha scritto:

Dear ns-3 community,

  I am currently running a basic TCP script similar to that of exampe/tutorial/fifth.cc. I notice that during the slow-start phase, the congestion window size Cwnd actually increases (as far as I can see) linearly rather than exponentially. My understanding is that if we delay the maximum number of receipt packets between sending an ACK to more than 1, it would slow down the Cwnd.

  However, I have set the above parameter e.g. DelAckCount in tcp-socket.cc to various values, including 0, 1, 2, ..., etc., but the Cwnd still seems to increase linearly. Some basic parameters I used are

• ns3::TcpL4Protocol::SocketType = TcpReno
• channel data rate = 1Mbps
• Source rate = 10Mbps
• channel error rate = 1e-8
• ns3::TcpSocket::DelAckCount = 0, or 1, or 2
• point-to-point device (tutorial/fifth.cc)
  

Can you please post an image with DelAckCount set to 1 and set to 2, to see differencies?

Thanks
Hi, 

[Raymond]

Hi Nat,

  Many thanks for your reply. I have set ns3::TcpSocket::DelAckCount = 1 (Case 18) and ns3::TcpSocket::DelAckCount = 2 (Case 19), and the figures are attached respectively. As delAckCount increases, it seems that the rate of growth of the TCP CWND is reduced as expected. However, the growth is still linear.

  As an aside, I noticed that the Trace Source HighestRxSequence, i.e. (TcpSocketBase::m_highRxMark), does not have any value updated (other than the origianl one value). Is it something normal?

  Thank you very much for your help.

Raymond 

[Raymond]

Hello,

  Regarding my second question concerning 'HighestRxSequence', I believe it should have been 'HighestRxAck'. Sorry for the confusion.

  Regarding the original issue on the observed linearity of the TCP CWND, the question still remains.

Thanks,
Raymond 

[Nat P]

Il giorno mercoledì 11 novembre 2015 15:39:25 UTC+1, Raymond ha scritto:

Hi Nat,

  Many thanks for your reply. I have set ns3::TcpSocket::DelAckCount = 1 (Case 18) and ns3::TcpSocket::DelAckCount = 2 (Case 19), and the figures are attached respectively. As delAckCount increases, it seems that the rate of growth of the TCP CWND is reduced as expected. However, the growth is still linear.

It seems..also for me. Step by step:

Assuming that it is congestion avoidance over all simulation, and no slow start is involved, there are differencies on the growth (visible through different grade angle), which I assume are due to an RTT change. Is it possible on your environment?
However the absence of slow start is strange. Initial slow start threshold is 0 ? Can you try your scripts on ns-3-dev, which includes a number of (hopefully) improvements on the TCP side? If, yes, that would be great.

Nat

[Raymond]

Hi Nat,

  Thanks for the reply. I might be possible that the the absence of the slow start is due to the possibility of having a 0 slow start threshold. However, I have some doubt about this based on the default parameter, as well as the values shown in the figure. The RWND is also very high as well. Another observation is that, as an example in Case 19, at 4 sec, a RTO occurs, and the CWND drop back to 1. At this time, the SsThrd is still much higher than CWND. Thus, my feeling is that the TCP should enter  the slow start region.

  As for the different growth rate, the channel delay is 2ms, and so the RTT should be fixed at 4ms. However, the RTT could be affected by the retransmission delay? Is there other possibilities? I am replotting Case 19 - this time, I am including the Highest Rx Ack. It seems the next Tx seq number and the Highest Rx Ack number are consistent.

Thanks,
Raymond

[Nat P]

Il giorno giovedì 12 novembre 2015 17:08:34 UTC+1, Raymond ha scritto:

Hi Nat,

  Thanks for the reply. I might be possible that the the absence of the slow start is due to the possibility of having a 0 slow start threshold. However, I have some doubt about this based on the default parameter, as well as the values shown in the figure. The RWND is also very high as well. Another observation is that, as an example in Case 19, at 4 sec, a RTO occurs, and the CWND drop back to 1. At this time, the SsThrd is still much higher than CWND. Thus, my feeling is that the TCP should enter  the slow start region.

  As for the different growth rate, the channel delay is 2ms, and so the RTT should be fixed at 4ms. However, the RTT could be affected by the retransmission delay? Is there other possibilities? I am replotting Case 19 - this time, I am including the Highest Rx Ack. It seems the next Tx seq number and the Highest Rx Ack number are consistent.

At this point, I can only help you if you mind to share your code, or to try it under ns-3-dev ..

Thanks

[Raymond]

Hi Nat,

  Sure. Thank you very much for your help. I will try out using the ns-3-dev first and will update you on this. If there is still a problem, I will send you the code. ( Actually, it is based on ns-3/example/tutorial/fifth.cc. As I did not modify any TCP-related code, the same observation can be found in fifth.cc.    ) 

Thanks,
Raymond 

[Raymond]

Hi Nat,

  I have gave it a try in the ns-3-dev. Please see attached two figures for comparison. The left figure corresponds to the ns-3-3.24, and the right corresponds to ns-3-dev.

Notes:
1) When I tried ns-3-dev, I am not able to access TcpReno, which is the one I have used previously. I realized that it is possible to use TcpNewReno, and so I have done both using TcpNewReno. It seems that the results between ns-3-3.24 and ns-3-dev are differenet. I am running with the same script.
2) The linearity in the slow start still exists.
3) It seems that files corresponding to some flavours of TCP are missing. For example, I can only see tcp-westwood.cc as a separate file, but I do not see files from other flavours. However, the TcpNewReno still exists, which is in tcp-congestion-ops.cc. I am wondering if there is a systematic way to find out what flavours are available?

I am attaching the main script which I used. It would be great if you could provide some insights.

Many thanks,
Raymond 

[Raymond]

Here is the script.

[Nat P]

Il giorno venerdì 13 novembre 2015 16:47:38 UTC+1, Raymond ha scritto:

Here is the script.

Hi, as many script in ns-3, they aren't perfect. First of all, try to increase the queue size (droptail, by default, has 100 packets only). Increase it as, say, 200 000 packets. if you mind, try to put a NS_LOG_UNCOND statement inside tcp-congestion-ops.cc , in SlowStart function of NewReno, and see how many times is called.

By the way, please read the release notes. TCP in ns-3-dev is substantially different from ns-3.24.

Nat

[Raymond]

Hi Nat,

  I have modified the droptail to 200000, and the figure is attached. I have included a message inside tpc-congestino-ops.cc, and noticed that the congestion phase stops at 5.59 seconds. This observation suggests that the slow start is in the linearly (or what seems to be) rising region of the figure, before the SsThrd is reached. Any idea?



Thanks,
Raymond 

[Nat P]

Il giorno lunedì 16 novembre 2015 12:17:38 UTC+1, Raymond ha scritto:

Hi Nat,

  I have modified the droptail to 200000, and the figure is attached. I have included a message inside tpc-congestino-ops.cc, and noticed that the congestion phase stops at 5.59 seconds. This observation suggests that the slow start is in the linearly (or what seems to be) rising region of the figure, before the SsThrd is reached. Any idea?

Isn't it OK ?

I mean, after reaching ssth, it goes into congestion avoidance.
For linearity, I think it is a problem on the scale of the graph, since the code it reaches (SlowStart in tcp-congestion-ops.cc) does exactly that:

  if (segmentsAcked >= 1)
    {
      tcb->m_cWnd += tcb->m_segmentSize;
      NS_LOG_INFO ("In SlowStart, updated to cwnd " << tcb->m_cWnd << " ssthresh " << tcb->m_ssThresh);
      return segmentsAcked - 1;
    }

Set MSS to 500 (through Config), and then do

export NS_LOG = "TcpNewReno=level_all:prefix_func:prefix_time"

and re-run the experiment. You should see SlowStart until 5.59, and then CongestionAvoidance. If you see this, there is no problem, and again, the linearity is due to the scale of the graph. Maybe zooming in could help.

Nat

[Nat P]

Il giorno martedì 17 novembre 2015 10:41:48 UTC+1, Nat P ha scritto:

 If you see this, there is no problem, and again, the linearity is due to the scale of the graph. Maybe zooming in could help.

I mean, if you set the y as logscale, you'll see a linear line when your function is exponential.

Nat

[Raymond]

Hi Nat,

  Thanks again for your reply.

  I can understand that before 5.59 seconds, it was in slow-start phase, and after 5.59 it was in congestion avoidance phase. However, the linearity is still lurking around a bit. Let's take a look at the upper figure in the earlier post for case 26. Each unit is 50000 in the y-axis, and so it goes 0 -> 50000 -> 100000 -> 150000 -> 200000 -> 250000 etc. It seems to be a linear scale to me.

  I attached a zoom-in version of case 26. Perhaps you could give me some insight?

Thanks,
Raymond 

[Raymond]

Hi Nat,

  I have attached another figure using the same parameters except ns3::TcpSocket::DelAckCount = 1. The increase is more rapid as expected, but the growth is still linear to me. Do we have a similar view on this?

Thanks,
Raymond 

[Raymond]

Hi,

  I have included another case with the following parameters based primarily on example/tutorial/fifith.cc (with no modification to TCP-related codes).

# point-to-point channel rate = 1Mbps
# Source rate = 10Mbps
# ch_error_rate = 1e-8
# ns3::TcpL4Protocol::SocketType = TcpNewReno
# ns3::TcpSocket::DelAckCount = 1
# ns3::TcpSocket::SegmentSize = 1200 (bytes)
# ns3::DropTailQueue::MaxPackets = 100
# ns3::PointToPointChannel::Delay = 2ms
# ns3::TcpSocket::SegmentSize = 1200

The congestion window dynamic is shown in the following.




  As I am using TcpNewReno, whenever the 3 duplicated acks are received, I would expect the SsThrd to be half of the Cwnd, and the Cwnd is halved + 3 segments. However, when looking at the top part of the figure, it does not look like the Cwnd and Ssthrd is reduced by 1/2 (with the Cwnd halved plus 3). I am wondering if this behaviour is expected.  As I am not a TCP expert, it is very possible that I might have missed something.

Many thanks,
Raymond 

[Raymond]

Hi Nat,

  I have done a bit more investigations on this linearity issue. I am a bit more confident that it is not a problem now. The apparent linearity is due to the fact that there is a 'limited thickness' of the channel (i.e. the pipe). Thus, if the channel delay is larger, the exponential behaviour would last longer before the pipe starts to 'fill up'. Once the pipe is filled up, i.e. the rate of growth of the Cwnd depends on the inter-arrival time of the ACKs, which, in turn, is limited by the channel rate and the segment size. The figure below shows the same previous case except with a 100ms channel delay. We can clearly see the exponential nature at the start, which is good.




  In terms of the SsThrd reduction in the occurance of duplicate packets, it is reduced by 2 of the min(CWnd and Rwnd) anyway, and so the observation is reasonable.

  Thank you Nat for spending the time and efforts to provide comments earlier.

Raymond 

[Nat P]

Il giorno giovedì 19 novembre 2015 13:12:07 UTC+1, Raymond ha scritto:

Hi Nat,

  I have done a bit more investigations on this linearity issue. I am a bit more confident that it is not a problem now. The apparent linearity is due to the fact that there is a 'limited thickness' of the channel (i.e. the pipe). Thus, if the channel delay is larger, the exponential behaviour would last longer before the pipe starts to 'fill up'. Once the pipe is filled up, i.e. the rate of growth of the Cwnd depends on the inter-arrival time of the ACKs, which, in turn, is limited by the channel rate and the segment size. The figure below shows the same previous case except with a 100ms channel delay. We can clearly see the exponential nature at the start, which is good.

Hi Raymond, nice analysis.

Have a nice day

Nat