Editing FAST TCP (section)

==Principles of operation==
The role of congestion control is to moderate the rate at which data is transmitted, "congestion", according to the capacity of the [[telecommunications network|network]] and the rate at which other users are transmitting.  Like [[TCP Vegas]], FAST TCP<ref>{{cite journal
 |last        = Nick
 |first       = Barone
 |author2     = Jin, Cheng
 |author3     = Low, Steven H.
 |author4     = Hegde, Sanjay
 |name-list-style     = amp
 |year        = 2006
 |title       = FAST TCP: motivation, architecture, algorithms, performance
 |journal     = IEEE/ACM Transactions on Networking
 |volume      = 14
 |issue       = 6
 |pages       = 1246–1259
 |url         = http://netlab.caltech.edu/pub/papers/FAST-ToN-final-060209.pdf
 |doi         = 10.1109/TNET.2006.886335
 |url-status     = dead
 |archive-url  = https://web.archive.org/web/20060906104225/http://netlab.caltech.edu/pub/papers/FAST-ToN-final-060209.pdf
 |archive-date = 2006-09-06
 |df          = 
}}</ref><ref>{{cite journal
 |last        = Jin
 |first       = Cheng
 |year        = 2005
 |title       = FAST TCP: from theory to experiments
 |journal     = IEEE Network
 |volume      = 19
 |issue       = 1
 |pages       = 4–11
 |url         = http://netlab.caltech.edu/pub/papers/fast-network05.pdf
 |doi         = 10.1109/MNET.2005.1383434
 |last2       = Wei
 |first2      = D.
 |last3       = Low
 |first3      = S.H.
 |last4       = Bunn
 |first4      = J.
 |last5       = Choe
 |first5      = H.D.
 |last6       = Doyle
 |first6      = J.C.
 |last7       = Newman
 |first7      = H.
 |last8       = Ravot
 |first8      = S.
 |last9       = Singh
 |first9      = S.
 |last10      = Paganini
 |first10     = F.
 |last11      = Buhrmaster
 |first11     = G.
 |last12      = Cottrell
 |first12     = L.
 |last13      = Martin
 |first13     = O.
 |last14      = Wu-Chun Feng
 |url-status     = dead
 |archive-url  = https://web.archive.org/web/20060512134100/http://netlab.caltech.edu/pub/papers/fast-network05.pdf
 |archive-date = 2006-05-12
 |df          = 
}}</ref> uses [[queueing delay]] instead of [[packet loss|loss probability]] as a congestion signal.

Most current congestion control algorithms detect congestion and slow down when they discover that packets are being dropped, so that the average sending rate depends on the loss probability.  This has two drawbacks.  First, low loss probabilities are required to sustain high data rates; in the case of TCP Reno, very low loss probabilities are required, but even new congestion avoidance algorithms such as [[H-TCP]], [[BIC TCP]] and [[HSTCP]] require loss rates lower than those provided by most wireless [[wide area network]]s.  Moreover, packet loss only provides a single bit of information about the congestion level, whereas delay is a continuous quantity and in principle provides more information about the network.

A FAST TCP flow seeks to maintain a constant number of packets in queues throughout the network.  The number of packets in queues is estimated by measuring the difference between the observed [[round-trip delay time|round trip time]] (RTT) and the ''base RTT'', defined as the round trip time when there is no queueing.  The base RTT is estimated as the minimum observed RTT for the connection.  If too few packets are queued, the sending rate is increased, while if too many are queued, the rate is decreased.  In this respect, it is a direct descendant of TCP Vegas.

The difference between TCP Vegas and FAST TCP lies in the way in which the rate is adjusted when the number of packets stored is too small or large.  TCP Vegas makes fixed size adjustments to the rate, independent of how far the current rate is from the target rate.  FAST TCP makes larger steps when the system is further from equilibrium and smaller steps near equilibrium.  This improves the speed of convergence and the stability.