Talk:TCP congestion-avoidance algorithm

	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 articles
Low	This redirect has been rated as Low-importance on the project's importance scale.
	This redirect is supported by Networking task force (assessed as Mid-importance).

Internet Mid‑importance

	Internet portal 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 articles
Mid	This redirect has been rated as Mid-importance on the project's importance scale.

TCP Tahoe mistake[edit]

Also, upon further enquiry into this matter, I have noticed that in nearly all descriptions of TCP Tahoe that I have found, it DOES contain the fast re-transmit algorithm, activated after 3 dupacks. So that the most significant change from TCP Tahoe to TCP Reno is the fast recovery algorithm. One of the last places where I read this was: http://inst.eecs.berkeley.edu/~ee122/fa05/projects/Project2/proj2_spec_files/sacks.pdf

This is so goddamn confusing and frustrating, and it's been preventing me from writing my assignment for nearly 2 days now, I wish someone could clear this up!

[Nicolas] 81.82.21.18 (talk) 15:10, 2 May 2009 (UTC)[reply]

Somewhat true statement[edit]

In the text before I changed it, it said that the receiving of duplicate packets meant that a packet was lost. Although this is usually the case, this is not correct. It's possible that the stream just got reordered, prompting the receiver to send the same ACK again and again because it still _expects_ the next packet in line, not the ones that it's receiving all the time.

Wikipedia sure had me confused, as I read both this article and multiple other sources, and didn't know what to think. But I think I got it right now. Also I don't know how to insert my user info.

[Nicolas] —Preceding unsigned comment added by 81.82.21.18 (talk) 12:36, 2 May 2009 (UTC)[reply]

Disputed[edit]

At least the following errors need to be fixed:

Congestion Avoidance starts after cwnd exceeds ssthresh, not after packet loss
Triple dupacks are only used for Fast Retransmit.
Fast Retransmit should be distinguished from Fast Recovery.
ssthresh is not mentioned
In Reno cwnd is not halved. ssthresh is often set to cwnd/2, but RFC 2581 recommends setting it to FlightSize/2.

Herr Baum 20:31, 9 March 2007 (UTC)[reply]

full algorithm in tcp tahoe

graphs showing the characteristic 'shapes' of window size over time, for congestion avoidance and TCP slow-start. These are helpful for grokking what goes on.

When it says Reno: halve congestion window on triple-ACK I think it should be Reno: congestion window set to half FlightSize on triple-ACK where FlightSize is the amount of outstanding data in the network.

This is based on what it says RFC 2581 --200.122.102.147 02:19, 30 November 2005 (UTC)(German Kruszewski)[reply]

Interesting points, Herr Baum and German Kruszewski(?). But I think you need to explain in plain English- can you describe the issue a little more clearly and offer replacement text? --Treekids (talk) 18:26, 8 December 2007 (UTC)[reply]

OK, so I collected the following from the article since they are points of contention in the factual dispute...

A new approach to Internet congestion control that outperforms TCP in conventional environments, and remains efficient, fair, scalable, and stable as the bandwidth-delay product increases is proposed ‘eXplicit Control Protocol’ (XCP), it generalizes the Explicit Congestion Notification proposal (ECN). In addition to that, XCP introduces the new concept of decoupling utilization control from fairness control. This allows a more flexible and tractable protocol design and could be helpful for service differentiation.

XCP is modeled based on control theory framework and demonstrates that it is stable and efficient regardless of the link capacity, the number of sources, and the round trip delay. Simulations show that XCP outperforms TCP in both conventional and high bandwidth-delay environments. XCP achieves fair bandwidth allocation, high utilization, small standing queue size, and near-zero packet drops, with both steady and highly varying traffic.

This may be true for some academic cases. But in wireless network scenarios (WLAN, UMTS), for example, XCP has a lot of problems to reach the current pipe capacity. Other new approaches, e.g. Fuzzy XCP or Enhanced TCP (ETCP), reach much better performance.

TCP Tahoe and Reno[edit]

SlowStart

SlowStart exists to avoid congestion at startup, not to avoid wasting time. Otherwise you would start at a higher value (not 2MSS) to get things going.
You dont enter Congestion Avoidance after a packet loss, but after reaching a SlowStart Threshold.
Packet Loss is also detected by Timeout

Actually, packet loss is detected only by timeout. Triple duplicate ACKs (i.e. 4 ACKs with the same sequence number) are only used for Fast Retransmit. Herr Baum 19:40, 9 March 2007 (UTC)[reply]

XCP[edit]

XCP sounds good, but has some bad behavior, especially in dynamically changing network scenarios. The "mathematical" results in the XCP dissertation considering the scenarios in which XCP can be used are not worth to be read (I have to write this so hard). If five parameters can vary in a large range, it is absolutely nonsense to fix four of them in a middle range to show that XCP works over a wide range for the fith one. In most realistic scenarios at least two of the parameters are far away from their "middle value". —The preceding unsigned comment was added by 217.247.68.155 (talk) 03:34, 9 December 2006 (UTC).[reply]

The article only mentions XCP as an alternative to TCP congestion avoidance problem for high bandwidth-delay problems. In fact, there are more alternatives. The most comprehansive overiew I'm aware of can be found at http://www.gridforum.org/documents/GFD.55.pdf. MacFreek 15:21, 12 November 2007 (UTC)[reply]

triple-ack[edit]

What is triple-ack ? triple-ack currently redirects to TCP congestion avoidance algorithm, which doesn't even mention the word. Is the explanation of what it is supposed to be in this article, or should triple-ack redirect to some other article?

The article does mention "the missing packet that was signaled by 3 duplicate ACKs". Is that the same as a "triple-ack"? The explanation is too brief to make any sense. I thought the reciever only sent an ACK for a received (non-missing) packet. Why would a missing packet generate even 1 ACK, much less 3 ACKs ?

--68.0.120.35 00:57, 16 February 2007 (UTC)[reply]

See RFC 2581, section 3.2 (Fast Retransmit/Fast Recovery). Strictly speaking triple ACKs is wrong and triple duplicate ACKs is correct. The receiver will send an ACK for every packet he receives out of order. However, the acknowledgement-number field of the TCP-header will always contain the next expected sequence-number. So if the sender keeps sending packets with unexpected sequence-numbers he will get a duplicate ACK for each one. Herr Baum 20:00, 9 March 2007 (UTC)[reply]

BIC and CUBIC notability[edit]

Given it is now the default algorithm for Linux and Linux runs a plurality of internet sites, I think this algorithm now has the *notability* to get equal billing. --Treekids 22:23, 17 July 2007 (UTC)[reply]

No objections, so I promoted BIC (and the new default CUBIC) out of the ghetto --Treekids (talk) 18:58, 8 December 2007 (UTC)[reply]

Linux default version[edit]

http://netsrv.csc.ncsu.edu/twiki/bin/view/Main/BIC stats:

"Since Linux 2.6.13, BIC had been included in the standard Linux distribution and set to the default TCP. "

so either they are wrong or this one:

"BIC is used by default in Linux kernels 2.6.8 through 2.6.18." —Preceding unsigned comment added by 79.195.89.218 (talk) 06:58, 15 September 2008 (UTC)[reply]

TCP Fusion[edit]

Is anyone familiar enough to include a section on TCP Fusion [1]? It seems to be based on a combination of TCP Reno, TCP Vegas, and TCP Westwoord (also new to me). I haven't found too much on TCP Fusion however (probably because it's not implemented in the Linux kernel yet). SDNick484 (talk) 16:17, 23 July 2009 (UTC)[reply]

Initial window[edit]

Is the initial window for Tahoe and Reno really 2 MSS in size? In our class, we said it was 1 MSS. The French Wikipedia seems to say 1 MSS too (but my French isn't that great, so I might have misunderstood it). 131.246.161.187 (talk) 10:56, 25 June 2013 (UTC)[reply]

Grammatical error[edit]

There is a grammatical error with the use of plural in the sentence "The two algorithms were retrospectively named after the 4.3BSD operating system in which each first appeared (which were themselves named after Lake Tahoe and the nearby city of Reno, Nevada)." Should it be "...after releases of the 4.3BSD operating system..." instead of "...after the 4.3BSD operating system..."? I.e. are Tahoe and Reno releases of the 4.3BSD operating system and did TCP Tahoe first appear in 4.3BSD-Tahoe and TCP Reno in 4.3BSD-Reno?80.235.83.183 (talk) 14:25, 8 June 2015 (UTC)[reply]