Talk:Slow-start

Skip to table of contents

This is the talk page for discussing improvements to the Slow-start redirect.
This is not a forum for general discussion of the article's subject.

Put new text under old text. Click here to start a new topic.
New to Wikipedia? Welcome! Learn to edit; get help.

Article policies

Find sources: Google (books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL

Computing: Networking Low‑importance

	This redirect is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing
Low	This redirect has been rated as Low-importance on the project's importance scale.
	This redirect is supported by Networking task force.

Internet

This redirect is within the scope of WikiProject Internet, a collaborative effort to improve the coverage of the Internet on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.InternetWikipedia:WikiProject InternetTemplate:WikiProject InternetInternet

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?

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Merge Article size and scope would be better placed there. Widefox; talk 10:08, 17 February 2013 (UTC)[reply]
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)[reply]

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)[reply]

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)[reply]

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