FAST TCP
# 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.
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 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. Dies kann jedoch durch geeignete Parameter vermieden werden, was zu den komplexen Interaktionen führt, die von Tang et al. 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 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.
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 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. 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.