Talk:Slow-start

Proposed changes to slow start

code.google.com/speed/articles/tcp_initcwnd_paper.pdf states that google have proposed that the initial window gets increased by a factor of about 3 to take into account modern networks and effect of slow start on http latency. Perhaps it's worth adding something about this?

See also http://blog.benstrong.com/2010/11/google-and-microsoft-cheat-on-slow.html — Preceding unsigned comment added by 217.33.39.10 (talk) 10:14, 23 February 2012 (UTC)

Exponential Growth?

The article says:

• During the exponential growth phase, Slow-start works by increasing the TCP congestion window by one segment for each acknowledgement received.

Should it not be double the congestion window for each acknowledgement received? —Preceding unsigned comment added by 59.95.5.244 (talk) 22:59, 6 June 2007 (UTC)

No it should not say that because it does not double for each ACK. It increases 1 Segment Size for each ACK received. This results in an exponential increase:

Send 1 packet. Receive 1 ACK. Increase by 1 SS Send 2 packets. Receive 2 ACKS. Increase by 2 SS Send 4 packets. Receive 4 ACKS. Increase by 4 SS Send 8 Packets. Receive 8 ACKS. Increase by 8 SS and so on.

This is explained in RFC 2001. —Preceding unsigned comment added by 64.129.167.114 (talk) 16:12, 1 October 2007 (UTC)

The preceding explanation, which I believe is correct, means this sentence from the article is both misleading and incorrect:

"Since the receiver typically sends an ACK for every two segments, this behavior effectively doubles the window size each round trip of the network."

The implication is that it is the "ACK for every two segments" that "effectively doubles the window size." In fact if there are fewer ACKs than segments, doubling in RTT will not occur.

"If the receiver is sending an ACK for every packet, the effect of this algorithm is that the data rate of the sender doubles every round-trip time interval. If the receiver supports delayed ACKs, the rate of increase will be slightly lower, but nevertheless the rate will increase by a minimum of one SMSS each round-trip time."

http://www.cisco.com/web/about/ac123/ac147/ac174/ac196/about_cisco_ipj_archive_article09186a00800c8417.html

Hamish.MacEwan (talk) 06:43, 9 December 2012 (UTC)

Textual error?

If a loss event occurs, TCP assumes this it is due to network congestion and takes steps to reduce the offered load on the network -> If a loss event occurs, TCP assumes that this is due to network congestion and takes steps to reduce the offered load on the network ? —Preceding unsigned comment added by 145.120.15.174 (talk) 21:21, 1 November 2007 (UTC)

Big error

The article includes "congestion avoidance" in the "slow start" mechanism when in fact it is a totally different phase. Slow start has also a deeper motivation than congestion control: it is an algorithm which introduces information in the network gradually and it is inspired from electrical networks. —Preceding unsigned comment added by 193.50.44.104 (talk) 13:37, 14 March 2008 (UTC)

Merge with TCP Congestion Avoidance

This information is redundant of that in TCP Congestion Avoidance, and even contradicts it to some degree. Additionally, this article includes details from other elements of Congestion Avoidance besides its namesake. Please initiate a proposal to merge it with the article on TCP Congestion Avoidance. -143.215.108.82 (talk) 09:36, 19 October 2009 (UTC)

I've put up merge banners here and at TCP congestion avoidance algorithm. Looks some cleanup/reorganization is called for in this area. I am not personally decided on how to proceed. -—Kvng 03:16, 15 December 2012 (UTC)

• Merge Article size and scope would be better placed there. Widefox; talk 10:08, 17 February 2013 (UTC)
• Merge I have suggested a wider merge of all relevant stubs into a new comprehensive article. See Talk:TCP congestion control and please comment, then I'll proceed. — JFG ^talk 04:00, 29 April 2014 (UTC)

Name of the algorithm

Isn't the name of the algorithm "slow start" (not "slow-start", with dash)? This is how it is referenced in RFC 5681 and RFC 2001. Perhaps the name of the article should be changed. — Preceding unsigned comment added by 85.216.222.19 (talk) 09:37, 10 October 2012 (UTC)

Linear growth on loss event?

The article says under the introductory text of Algorithm: "Once a loss event has occurred or the threshold has been reached, TCP enters the linear growth (congestion avoidance) phase." Shouldn't it be: "Once the threshold has been reached, TCP enters the linear growth (congestion avoidance) phase."?

As per my understanding of the RFC and slow start behavior, when a loss event occurs, TCP does not enter the linear growth phase but instead adjusts ssthresh and restarts again from its initial cwnd. This explanation is also given under Basic slow-start and contradicts with the above introductory statement under Algorithm. 14.139.113.18 (talk) 06:28, 28 November 2012 (UTC)

Thanks for catching this. I have removed "a loss event has occurred or". -—Kvng 16:52, 30 November 2012 (UTC)