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. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
This redirect does not require a rating on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||
|
The contents of the Slow-start page were merged into TCP congestion-avoidance algorithm on 2016-03-13. For the contribution history and old versions of the merged article please see its history. |
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)
The article says:
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:
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.
Hamish.MacEwan ( talk) 06:43, 9 December 2012 (UTC)
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)
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)
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)
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)
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)
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. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
This redirect does not require a rating on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||
|
The contents of the Slow-start page were merged into TCP congestion-avoidance algorithm on 2016-03-13. For the contribution history and old versions of the merged article please see its history. |
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)
The article says:
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:
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.
Hamish.MacEwan ( talk) 06:43, 9 December 2012 (UTC)
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)
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)
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)
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)
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)