FAST TCP
FAST TCP (auch FastTCP) ist ein Algorithmus zur Überlastungssteuerung für das Transmission Control Protocol (TCP). FAST TCP ist speziell auf Hochgeschwindigkeits-Netzwerke mit großer Übertragungslatenz ausgerichtet und wurde am Netlab des California Institute of Technology entwickelt. Es wird zurzeit von FastSoft kommerziell vertrieben. FastSoft wurde 2012 von Akamai Technologies übernommen.[1]
FastTCP ist kompatibel mit bestehenden TCP-Algorithmen und benötigt nur Modifikationen am Daten sendenden Computer.
Bezeichnung
Die Bezeichnung FAST ist ein rekursives Akronym für FAST AQM Scalable TCP, wobei AQM für Active Queue Management und TCP für Transmission Control Protocol steht.
Funktionsweise
Die Überlastkontrolle (engl. Congestion Control) versucht, die Bandbreite eines Netzwerks optimal auszunutzen und dabei gleichzeitig Überlastungen zu vermeiden, indem sie die Übertragungsgeschwindigkeit der angeschlossenen Netzwerkkomponenten reguliert. Im Gegensatz zu anderen Algorithmen wie beispielsweise TCP Reno, welche die Verlustwahrscheinlichkeit von Datenpaketen im Netzwerk als Signal für eine Überlastung verwenden (loss probability), nutzt FAST TCP[2][3] wie TCP Vegas dafür die Verzögerung in der Abarbeitung des Paketpuffers (queueing delay).
Die meisten modernen Algorithmen zur Überlastkontrolle verringern den Datenfluss, sobald sie feststellen, dass Pakete im Netzwerk verloren gehen. Damit hängt die durchschnittliche Übertragungsrate von der Paketverlustrate ab. Dieser Ansatz hat zwei Nachteile. Zunächst sind niedrige Verlustwahrscheinlichkeiten erforderlich, um hohe Übertragungsraten zu erhalten. Im Fall von TCP Reno ist eine sehr niedrige loss probability notwendig, aber auch neuere Algorithmen wie H-TCP, BIC TCP und HSTCP benötigen geringere Verlustraten als die der meisten kabellosen Wide Area Networks. Außerdem erzeugt ein Paketverlust nur kurzzeitig eine geringe Menge an Information über die Netzauslastung, wohingegen die Verzögerung ein kontinuierlicher Wert ist und generell mehr Information über das Netzwerk preisgibt.
FAST TCP versucht die Paketanzahl in Warteschlangen (engl. queue) über das ganze Netzwerk hinweg konstant zu halten. Die Anzahl der gespeicherten Pakete wird über den gemessenen Unterschied zwischen der beobachteten Paketumlaufzeit (RTT) und der base RTT abgeschätzt. Die base RTT ist definiert als die Paketumlaufzeit im Netzwerk ohne Paketpufferung und wird mit der geringsten beobachteten Paketumlaufzeit der Verbindung abgeschätzt. Sind zu wenige Pakete in den Warteschlangen, wird die Senderate erhöht, und bei zu vielen Paketen wird die Senderate verringert. In dieser Hinsicht ist FAST TCP ein direkter Nachfolger von TCP Vegas.
Der Unterschied zwischen TCP Vegas und FAST TCP liegt in der Art, wie die Senderate angepasst wird, wenn die Anzahl an gespeicherten Paketen zu hoch oder zu niedrig ist. TCP Vegas verwendet eine fixe Schrittweite, unabhängig davon wie weit die momentane Senderate von der Zielrate entfernt ist. FAST TCP passt hingegen die Korrektur-Schrittweite an die Entfernung des Netzwerksystems vom Gleichgewicht (Äquilibration, engl. equilibrium) an. Das heißt, die Senderate wird in größeren Schritten angepasst, wenn das System weiter vom Gleichgewicht entfernt ist, und in kleineren, wenn es sich nah an der Äquilibration befindet. Dieses Vorgehen verbessert die Konvergenzgeschwindigkeit und die Stabilität.
Stärken und Schwächen
Verzögerungsbasierte Algorithmen können prinzipiell eine konstante Fenstergröße behalten und damit die Oszillationen paketverlustratenbasierter Algorithmen vermeiden. Außerdem erkennen sie eine Überlastung des Netzwerks früher, da sich die Verzögerungszeit schon bei teilweise gefüllten Puffern ändert, Paketverluste aber erst bei vollständig gefüllten Puffern entstehen. Das kann sowohl eine Stärke, aber auch eine Schwäche sein. Wenn in einem Netzwerk nur verzögerungsbasierte Algorithmen verwendet werden, kann die Ineffizienz verlustratenbasierter Algorithmen vermieden werden. Werden aber beide Algorithmentypen in einem Netzwerk verwendet, tendieren verzögerungsbasierte Algorithmen dazu, sich vergleichsweise weniger aggressiv zu verhalten.[4] Dies kann jedoch durch geeignete Parameter vermieden werden, was zu den komplexen Interaktionen führt, die von Tang et al.[4] beschrieben wurden.
Die Messung der Verzögerungszeiten kann durch Jitter verfälscht werden, der durch Betriebssystem-Scheduling oder die Bus-Verbindungen verursacht wird.
Eine ns-2-Simulation[5] hat gezeigt, dass existierende FAST TCP Flows die Näherung der base RTT über die Basis-Netzwerklaufzeit (engl. round-trip propagation delay oder RTPD) nachfolgender FAST TCP Flows verfälschen können. Diese Fehleinschätzung der Netzwerklaufzeit hat den Effekt, dass neuere FAST TCP Flows aggressiver handeln und einen höheren Datendurchsatz erreichen, was aber existierende Flows benachteiligt. Die Autoren der Simulation schlagen eine Lösung für dieses Problem vor.[5]
Ob die Stärken oder die Schwächen von FAST TCP überwiegen, ist nicht eindeutig und sehr vom Einsatzszenario abhängig.
Generalized FAST TCP
FAST TCP hat sich als vielversprechend in Hinsicht von Systemstabilität, Datendurchsatz und Fairness herausgestellt. Allerdings wird ein Datenpuffer benötigt, dessen Größe linear mit der Anzahl von überlasteter Flows in einer Verbindung wächst. Der von Yuan et al. als Erweiterung von FAST TCP vorgeschlagene Algorithmus Generalized FAST TCP[6] erreicht eine (α, n)-proportionale Fairness im stabilen Verbindungszustand. Außerdem werden die Anforderungen an die Puffergröße auf die n-te Potenz der Flowanzahl verringert.
Geistiges Eigentum
Im Gegensatz zu den meisten anderen Algorithmen zur TCP-Überlastungssteuerung ist FAST TCP über mehrere Patente geschützt.[7][8] Anstatt eine Standardisierung über die IETF anzustreben, versuchen die Erfinder von FAST TCP, Steven H. Low und Cheng Jin, den Algorithmus über das Unternehmen FastSoft zu kommerzialisieren.
Siehe auch
Weblinks
Einzelnachweise
- ↑ Jeff Young: Akamai Acquires FastSoft. 13. September 2012. Abgerufen am 13. September 2012.
- ↑ Barone Nick, Jin, Cheng; Low, Steven H. and Hegde, Sanjay: FAST TCP: motivation, architecture, algorithms, performance Archiviert vom Original am 6. September 2006. In: IEEE/ACM Trans. on Networking. 14, Nr. 6, 2006, S. 1246–1259. doi:10.1109/TNET.2006.886335.
- ↑ Cheng Jin, D. Wei, S.H. Low, J. Bunn, H.D. Choe, J.C. Doyle, H. Newman, S. Ravot, S. Singh, F. Paganini, G. Buhrmaster, L. Cottrell, O. Martin, Wu-Chun Feng: FAST TCP: from theory to experiments Archiviert vom Original am 12. Mai 2006. In: IEEE Network. 19, Nr. 1, 2005, S. 4–11. doi:10.1109/MNET.2005.1383434.
- ↑ a b Ao Tang, Wang, Jiantao; Low, Steven H. and Chiang, Mung: Network Equilibrium of heterogeneous congestion control protocols. In: IEEE INFOCOM. März 2005.
- ↑ a b 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.
- ↑ Cao Yuan, Liansheng Tan, Lachlan L.H. Andrew, Wei Zhang, Moshe Zukerman: A Generalized FAST TCP scheme. In: Computer Communications. 31, Nr. 14, 2008, S. 3242–3249.
- ↑ Patent US9253104: Dynamic Adjustment Of Receive Window Utilized By A Transmitting Device. Angemeldet am 14. August 2014, veröffentlicht am 18. April 2014, Anmelder: AKAMAI TECH INC, Erfinder: JIN CHENG [US]; LEE GEORGE S [US]; LOW STEVEN [US]; NG DARREN [US]; WITT RYAN [US].
- ↑ Patent US7974195: Method and apparatus for network congestion control. Angemeldet am 14. Mai 2004, veröffentlicht am 5. Juni 2011, Anmelder: CALIFORNIA INST OF TECHN [US], Erfinder: JIN CHENG [US]; LOW STEVEN [US]; WEI XIAOLIANG [US].
