Editing FAST TCP

{{Short description|TCP congestion avoidance algorithm}}
{{Use American English|date=January 2019}}
{{Use mdy dates|date=January 2019}}
'''FAST TCP''' (also written '''FastTCP''') is a [[TCP congestion avoidance algorithm]] especially targeted at long-distance, high latency links, developed at the Netlab, [[California Institute of Technology]] and now being commercialized by FastSoft. FastSoft was acquired by [[Akamai Technologies]] in 2012.<ref>{{cite web
 | last = Young
 | first = Jeff
 | title = Akamai Acquires FastSoft
 | agency = PR Newswire
 | date = 2012-09-13
 | url = http://www.prnewswire.com/news-releases/akamai-acquires-fastsoft-169678966.html
 | accessdate = 2012-09-13 }}</ref>

FastTCP is compatible with existing TCP algorithms, requiring modification only to the [[computer]] which is sending [[data]].

==Name==
The name '''FAST''' is a [[recursive acronym]] for '''F'''AST '''A'''QM '''S'''calable '''T'''CP, where '''AQM''' stands for '''A'''ctive '''Q'''ueue '''M'''anagement, and '''TCP''' stands for '''T'''ransmission '''C'''ontrol '''P'''rotocol.

==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.

==Strengths and weaknesses==
Delay-based algorithms can, in principle, maintain a constant window size, avoiding the oscillations inherent in loss-based algorithms.  However, they also detect congestion earlier than loss-based algorithms, since delay corresponds to partially filled [[Buffer (telecommunication)|buffers]], while loss results from totally filled buffers.  This can be either a strength or a weakness.  If the only protocol used in a network is delay-based, then the inefficiency of loss can be avoided; however, if loss-based and delay-based protocols share the network,<ref>{{cite web
 | last = Tang
 | first = Ao
 | author2 = Wang, Jiantao
 | author3 = Low, Steven H.
 | author4 = Chiang, Mung
 | name-list-style = amp
 |date= March 2005
 | title = Network Equilibrium of heterogeneous congestion control protocols
 | work = IEEE INFOCOM
 | location = Miami, FL
 | url = http://www.sisl.caltech.edu/pubs/controlprotocol.pdf
 }}
</ref> then delay-based algorithms tend to be less aggressive.  This can be overcome by suitable choice of parameters, leading to complex interactions studied by Tang et al.

Delay measurements are also subject to jitter as a result of [[operating system]] scheduling, or [[Computer bus|bus]] contention.

Whether the strengths or weaknesses prevail is not clear, and depends in large part on the particular scenario.

Propagation delay is used in the FAST window control algorithm. In a clean network, the queueing delay maintained by existing FAST flows may be mistaken as part of the propagation delay by new flows that join later, as shown in ns-2 simulations in.<ref name=":0">L. Tan, C. Yuan, and M. Zukerman, “FAST TCP: fairness and queuing issues,” IEEE Commun. Lett., vol. 9, no. 8, pp. 762–764, Aug. 2005.</ref> The effect of this estimation error is equivalent to modifying the underlying utility functions to favor new flows over existing flows. Method to eliminate this error is suggested in.<ref name=":0" />

==Generalized FAST TCP==
FAST TCP has been shown to be promising in terms of system stability, throughput and fairness. However,
it requires buffering which increases linearly with the number of flows bottlenecked at a link. The paper <ref>{{cite journal|last1=Yuan|first1=Cao|last2=Tan|first2=Liansheng|last3=Andrew|first3=Lachlan L.H.|last4=Zhang|first4=Wei|last5=Zukerman|first5=Moshe|title=A Generalized FAST TCP scheme|journal=Computer Communications|date=2008|volume=31|issue=14|pages=3242–3249|doi=10.1016/j.comcom.2008.05.028|hdl=1959.3/44051|hdl-access=free}}</ref>
proposes a new TCP algorithm that extends FAST TCP to achieve (''α'', ''n'')-proportional fairness in steady
state, yielding buffer requirements which grow only as the nth power of the number of flows. The authors call
the new algorithm Generalized FAST TCP. They prove stability for the case of a single bottleneck link with
homogeneous sources in the absence of feedback delay. Simulation results verify that the new scheme is
stable in the presence of feedback delay, and that its buffering requirements can be made to scale significantly
better than standard FAST TCP.

==Intellectual property==
Unlike most TCP congestion avoidance algorithms, FAST TCP is protected by several patents.<ref>{{cite web
 |last=Jin 
 |first=Cheng 
 |author2=Low, Steven H. 
 |author3=Wei, Xiaoliang 
 |title=Method and apparatus for network congestion control 
 |publisher=[[United States Patent & Trademark Office]] 
 |date=2005-01-27 
 |url=http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=2&f=G&l=50&co1=AND&d=PG01&s1=jin.IN.&s2=low.IN.&OS=IN/jin+AND+IN/low&RS=IN/jin+AND+IN/low
 |archive-url=https://archive.today/20121214082726/http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=/netahtml/PTO/search-bool.html&r=2&f=G&l=50&co1=AND&d=PG01&s1=jin.IN.&s2=low.IN.&OS=IN/jin+AND+IN/low&RS=IN/jin+AND+IN/low
 |url-status=dead
 |archive-date=2012-12-14
 |access-date=2006-11-05 
}}</ref><ref>{{cite web
 |last=Jin 
 |first=Cheng 
 |author2=Low, Steven H. 
 |author3=Wei, David X. 
 |author4=Wydrowski, Bartek 
 |author5=Tang, Ao 
 |author6=Choe, Hyojeong 
 |title=Method and apparatus for network congestion control using queue control and one-way delay measurements 
 |publisher=[[United States Patent & Trademark Office]] 
 |date=2006-03-09 
 |url=http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&co1=AND&d=PG01&s1=jin.IN.&s2=low.IN.&OS=IN/jin+AND+IN/low&RS=IN/jin+AND+IN/low
 |archive-url=https://archive.today/20121214071939/http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=/netahtml/PTO/search-bool.html&r=1&f=G&l=50&co1=AND&d=PG01&s1=jin.IN.&s2=low.IN.&OS=IN/jin+AND+IN/low&RS=IN/jin+AND+IN/low
 |url-status=dead
 |archive-date=2012-12-14
 |access-date=2006-11-05 
}}</ref> Instead of seeking standardization by the [[IETF]], the inventors of FAST, notably [[Steven H. Low]] and Cheng Jin, are seeking to commercialize it through the company FastSoft. Currently FastSoft sells a 1-Unit rack appliance which can be deployed at the sender-side with no other software or hardware modifications needed on either end.

==See also==
* [[TCP congestion avoidance algorithm]]
* [[Transmission Control Protocol#Development|Transmission Control Protocol, Development]]

==References==
{{Reflist}}

==External links==
*[http://netlab.caltech.edu/FAST/ FAST] Home Page.
*[https://web.archive.org/web/20051126034627/http://ultralight.caltech.edu/web-site/sc05/html/index.html Supercomputing 2005 Bandwidth Challenge]
*[https://web.archive.org/web/20061215111552/http://www.fastsoft.com/ FastSoft home page]

{{DEFAULTSORT:Fast Tcp}}
[[Category:Internet Standards]]
[[Category:TCP congestion control]]