1

I have a question about the increasing rate of TCP sender's congestion window during the slow start phase. Traditionally, the size of cwnd exponentially increases for every RTT. For instance, if the initial cwnd value is 1, it increases 2->4->8->16->.... .

In my case, since the sender uses linux kernel 3.5, the initial cwnd is 10. I expected the cwnd increases as 10->20->40->... without delayed ACK (I turned it off at the receiver). However, when the receiver downloads a large size (over 1MB) of object from the sender over HTTP, cwnd increases as 10->12->19->29->.... I cannot understand this sequence.

I set RTT to 100ms and the link bandwidth is high enough. There is no loss during a session. I estimated the sender's cwnd by counting the number of packet the receiver received within one RTT.

Does anyone have idea for this behavior? Thanks.

user1695882
  • 11
  • 2

1 Answers1

1

The dafault congestion control algorithm in kernel 3.5 is not TCP Reno, but CUBIC. CUBIC has different behavior. It stems from BIC, and I know that CUBIC share slow start phase of BIC. Just see codes of BIC and CUBIC at /usr/src/yourkernelname/net/ipv4/tcp_cubic.c.

Moreover, delayed ack MAY result in such sequences. You know, 'traditional' TCP congestion control behavior is TCP reno without DACK nor SACK. Know that even current TCP reno in Linux is not reno but new reno (reno with SACK).

Check the options of Delayed ack and Seletive ack using sysctl command.

Skycrawlers
  • 11
  • 2
  • new reno is not really a different congestion control. it is a different loss recovery mechanism, and it has no affect on slow start. Also new reno is not reno with sack, sack is yet another form of loss recovery. – Effie Dec 15 '21 at 07:28