Die Namenskonvention für Überlastungssteuerungsalgorithmen (CCAs) stammt möglicherweise aus einem Artikel von Kevin Fall und Sally Floyd aus dem Jahr 1996.

Das Folgende ist eine mögliche Klassifizierung nach den folgenden Eigenschaften:

1. die Art und Menge des vom Netzwerk empfangenen Feedbacks
2. inkrementelle Bereitstellbarkeit im aktuellen Internet
3. der Aspekt der Leistung, den es verbessern soll: Produktnetzwerke mit hoher Bandbreitenverzögerung (B); verlustbehaftete Links (L); Fairness (F); Vorteil für kurze Flüsse (S); Links mit variabler Rate (V); konvergenzgeschwindigkeit (C)
4. das verwendete Fairnesskriterium

Einige bekannte Mechanismen zur Vermeidung von Staus werden von diesem Schema wie folgt klassifiziert:

Variant	Feedback	Required changes	Benefits	Fairness
(New) Reno	Loss	—	—	Delay
Vegas	Delay	Sender	Less loss	Proportional
High Speed	Loss	Sender	High bandwidth
BIC	Loss	Sender	High bandwidth
CUBIC	Loss	Sender	High bandwidth
C2TCP	Loss/Delay	Sender	Ultra-low latency and high bandwidth
NATCP	Multi-bit signal	Sender	Near Optimal Performance
Elastic-TCP	Loss/Delay	Sender	High bandwidth/short & long-distance
Agile-TCP	Loss	Sender	High bandwidth/short-distance
H-TCP	Loss	Sender	High bandwidth
FAST	Delay	Sender	High bandwidth	Proportional
Compound TCP	Loss/Delay	Sender	High bandwidth	Proportional
Westwood	Loss/Delay	Sender	L
Jersey	Loss/Delay	Sender	L
BBR	Delay	Sender	BLVC, Bufferbloat
CLAMP	Multi-bit signal	Receiver, Router	V	Max-min
TFRC	Loss	Sender, Receiver	No Retransmission	Minimum delay
XCP	Multi-bit signal	Sender, Receiver, Router	BLFC	Max-min
VCP	2-bit signal	Sender, Receiver, Router	BLF	Proportional
MaxNet	Multi-bit signal	Sender, Receiver, Router	BLFSC	Max-min
JetMax	Multi-bit signal	Sender, Receiver, Router	High bandbreite	Max-min
ROT	Verlust	Router	Reduzierte Verzögerung
ECN	Einzelbitsignal	Sender, Empfänger, Router	Reduzierter Verlust

TCP Tahoe und RenoEdit

TCP Tahoe- und Reno-Algorithmen wurden nachträglich nach den Versionen oder Varianten des 4.3BSD-Betriebssystems benannt, in denen sie zum ersten Mal auftauchten (die selbst nach Lake Tahoe und der nahe gelegenen Stadt Reno, Nevada, benannt wurden). Der Tahoe-Algorithmus erschien zuerst in 4.3BSD-Tahoe (der zur Unterstützung des CCI Power 6/32 „Tahoe“ -Minicomputers entwickelt wurde) und wurde später Nicht-AT&T-Lizenznehmern als Teil der 4.3BSD-Netzwerkversion 1 zur Verfügung gestellt. Verbesserungen wurden in 4.3BSD-Reno vorgenommen und anschließend als Networking Release 2 und später 4.4BSD-Lite veröffentlicht.

Während beide Retransmission Timeout (RTO) und doppelte ACKs als Paketverlustereignisse betrachten, unterscheiden sich das Verhalten von Tahoe und Reno hauptsächlich darin, wie sie auf doppelte ACKs reagieren:

• Tahoe: Wenn drei doppelte ACKs empfangen werden (dh vier ACKs, die dasselbe Paket bestätigen, die nicht auf Daten Huckepack sind und das Überlastungsfenster des Empfängers nicht ändern), führt Tahoe eine schnelle erneute Übertragung durch, setzt den Schwellenwert für den langsamen Start auf die Hälfte des aktuellen Überlastungsfensters und reduziert die Überlastung fenster zu 1 MSS, und setzt zu langsam starten zustand.
• Reno: wenn drei doppelte ACKs empfangen werden, führt Reno eine schnelle erneute Übertragung durch und überspringt die langsame Startphase, indem es stattdessen das Überlastungsfenster halbiert (anstatt es wie Tahoe auf 1 MSS zu setzen), den Schwellenwert für den langsamen Start auf das neue Überlastungsfenster setzt und eine Phase namens Fast Recovery eingibt.

Wenn in Tahoe und Reno ein ACK-Timeout (RTO-Timeout) auftritt, wird ein langsamer Start verwendet, und beide Algorithmen reduzieren das Überlastungsfenster auf 1 MSS.

TCP VegasEdit

Bis Mitte der 1990er Jahre basierten alle von TCP festgelegten Timeouts und gemessenen Roundtrip-Verzögerungen nur auf dem letzten übertragenen Paket im Sendepuffer. Die Forscher der University of Arizona, Larry Peterson und Lawrence Brakmo, führten TCP Vegas (benannt nach Las Vegas, der größten Stadt in Nevada) ein, in dem Zeitüberschreitungen festgelegt und Roundtrip-Verzögerungen für jedes Paket im Sendepuffer gemessen wurden. Darüber hinaus verwendet TCP Vegas additive Erhöhungen des Überlastungsfensters. In einer Vergleichsstudie verschiedener TCP-CCAs schien TCP Vegas am glattesten zu sein, gefolgt von TCP CUBIC.

TCP Vegas wurde außerhalb von Petersons Labor nicht weit verbreitet eingesetzt, wurde jedoch als Standardmethode zur Überlastungskontrolle für die DD-WRT-Firmware v24 SP2 ausgewählt.

TCP New RenoEdit

TCP New Reno, definiert durch RFC 6582 (der frühere Definitionen in RFC 3782 und RFC 2582 veraltet), verbessert die erneute Übertragung während der schnellen Wiederherstellungsphase von TCP Reno. Um das Sendefenster während der schnellen Wiederherstellung voll zu halten, wird für jede doppelte ACK, die zurückgegeben wird, ein neues nicht gesendetes Paket vom Ende des Sendefensters gesendet. Für jede ACK, die teilweise Fortschritte im Sequenzraum macht, geht der Absender davon aus, dass die ACK auf ein neues Loch zeigt, und das nächste Paket jenseits der ACK-Sequenznummer wird gesendet.

Da das Timeout bei jedem Fortschritt im Sendepuffer zurückgesetzt wird, kann New Reno große oder mehrere Löcher im Sequenzraum füllen – ähnlich wie TCP SACK. Da New Reno während der schnellen Wiederherstellung am Ende des Überlastungsfensters neue Pakete senden kann, wird während des Lochfüllvorgangs ein hoher Durchsatz von jeweils mehreren Paketen aufrechterhalten, selbst wenn mehrere Löcher vorhanden sind. Wenn TCP in die schnelle Wiederherstellung eintritt, zeichnet es die höchste ausstehende nicht bestätigte Paketsequenznummer auf. Wenn diese Sequenznummer bestätigt wird, kehrt TCP in den Überlastungsvermeidungszustand zurück.

Bei New Reno tritt ein Problem auf, wenn keine Paketverluste auftreten, sondern Pakete um mehr als 3 Paketsequenznummern neu angeordnet werden. In diesem Fall tritt New Reno fälschlicherweise in Fast Recovery ein. Wenn das neu geordnete Paket zugestellt wird, tritt ein ACK-Sequenznummernfortschritt auf, und von dort bis zum Ende der schnellen Wiederherstellung erzeugt jeder Sequenznummernfortschritt eine doppelte und unnötige erneute Übertragung, die sofort bestätigt wird.

New Reno schneidet bei niedrigen Paketfehlerraten genauso gut ab wie SACK und übertrifft Reno bei hohen Fehlerraten deutlich.

TCP HyblaEdit

TCP Hybla zielt darauf ab, Strafen für TCP-Verbindungen zu beseitigen, die eine hohe Latenz terrestrische oder Satellitenfunkverbindungen integrieren. Hybla-Verbesserungen basieren auf einer analytischen Auswertung der Staufensterdynamik.

TCP BICEdit

Binary Increase Congestion Control (BIC) ist eine TCP-Implementierung mit einem optimierten CCA für Hochgeschwindigkeitsnetze mit hoher Latenz, die als Long Fat-Netzwerke bezeichnet werden. BIC wird standardmäßig in den Linux-Kerneln 2.6.8 bis 2.6.18 verwendet.

TCP CUBICEdit

CUBIC ist eine weniger aggressive und systematischere Ableitung von BIC, bei der das Fenster eine kubische Funktion der Zeit seit dem letzten Überlastungsereignis ist, wobei der Wendepunkt auf das Fenster vor dem Ereignis gesetzt ist. CUBIC wird standardmäßig in Linux-Kerneln zwischen den Versionen 2.6.19 und 3.2 verwendet.

Agile-SD TCPEdit

Agile-SD ist ein Linux-basierter CCA, der für den echten Linux-Kernel entwickelt wurde. Es ist ein empfängerseitiger Algorithmus, der einen verlustbasierten Ansatz mit einem neuartigen Mechanismus namens Agility Factor (AF) verwendet. um die Bandbreitennutzung über Hochgeschwindigkeits- und Kurzstreckennetze (Low-BDP-Netzwerke) wie lokale Netzwerke oder Glasfasernetze zu erhöhen, insbesondere wenn die angewandte Puffergröße klein ist. Es wurde bewertet, indem seine Leistung mit Compound-TCP (dem Standard-CCA in MS Windows) und CUBIC (dem Standard von Linux) unter Verwendung des NS-2-Simulators verglichen wurde. Es verbessert die Gesamtleistung um bis zu 55% in Bezug auf den durchschnittlichen Durchsatz.

TCP Westwood+Bearbeiten

Westwood+ ist eine reine Absendermodifikation von TCP Reno, die die Leistung der TCP-Überlastungskontrolle über kabelgebundene und drahtlose Netzwerke optimiert. TCP Westwood + basiert auf einer End-to-End-Bandbreitenschätzung, um das Überlastungsfenster und den Schwellenwert für den langsamen Start nach einer Überlastungsepisode festzulegen, dh nach drei doppelten Bestätigungen oder einem Timeout. Die Bandbreite wird geschätzt, indem die Rate der zurückkehrenden Bestätigungspakete gemittelt wird. Im Gegensatz zu TCP Reno, das das Überlastungsfenster nach drei doppelten ACKs blind halbiert, legt TCP Westwood + adaptiv einen Schwellenwert für den langsamen Start und ein Überlastungsfenster fest, das eine Schätzung der zum Zeitpunkt der Überlastung verfügbaren Bandbreite berücksichtigt. Im Vergleich zu Reno und New Reno erhöht Westwood + den Durchsatz über drahtlose Verbindungen erheblich und verbessert die Fairness in kabelgebundenen Netzwerken.

Compound TCPEdit

Compound TCP ist eine Microsoft-Implementierung von TCP, die zwei verschiedene TCP-Fenster gleichzeitig verwaltet, mit dem Ziel, eine gute Leistung auf LFNs zu erzielen, ohne die Fairness zu beeinträchtigen. Es ist seit Microsoft Windows Vista und Windows Server 2008 in Windows-Versionen weit verbreitet und wurde sowohl auf ältere Microsoft Windows-Versionen als auch auf Linux portiert.

TCP Proportional Rate ReductionEdit

TCP Proportional Rate Reduction (PRR) ist ein Algorithmus, der die Genauigkeit der während der Wiederherstellung gesendeten Daten verbessert. Der Algorithmus stellt sicher, dass die Fenstergröße nach der Wiederherstellung so nahe wie möglich am Schwellenwert für den langsamen Start liegt. In von Google durchgeführten Tests führte PRR zu einer Verringerung der durchschnittlichen Latenz um 3-10%, und die Wiederherstellungs-Timeouts wurden um 5% reduziert. PRR ist in Linux-Kerneln seit Version 3.2 verfügbar.

TCP BBREdit

Bottleneck Bandwidth and Round-Trip Propagation Time (BBR) ist ein CCA, der 2016 von Google entwickelt wurde. Während die meisten CCAs verlustbasiert sind, da sie auf Paketverlust angewiesen sind, um Überlastung und niedrigere Übertragungsraten zu erkennen, ist BBR wie TCP Vegas modellbasiert. Der Algorithmus verwendet die maximale Bandbreite und die Roundtrip-Zeit, zu der das Netzwerk den letzten Flug ausgehender Datenpakete geliefert hat, um ein Modell des Netzwerks zu erstellen. Jede kumulative oder selektive Bestätigung der Paketzustellung erzeugt eine Ratenstichprobe, die die über das Zeitintervall zwischen der Übertragung eines Datenpakets und der Bestätigung dieses Pakets gelieferte Datenmenge aufzeichnet. Da sich Netzwerkschnittstellencontroller von Megabit pro Sekunde zu Gigabit pro Sekunde entwickeln, wird die Latenz, die mit Bufferbloat anstelle von Paketverlust verbunden ist, zu einem zuverlässigeren Marker für den maximalen Durchsatz, wodurch modellbasierte CCAs, die einen höheren Durchsatz und eine niedrigere Latenz bieten, wie z BBR, eine zuverlässigere Alternative zu populäreren verlustbasierten Algorithmen wie TCP CUBIC.

BBR ist seit Linux 4.9 für Linux TCP verfügbar. Es ist auch für QUIC verfügbar.

BBR Version 1 (BBRv1) ist effizient und schnell, aber seine Fairness gegenüber Nicht-BBR-Streams ist umstritten. Bei der Implementierung bei YouTube erzielte BBRv1 einen durchschnittlich 4% höheren Netzwerkdurchsatz und in einigen Ländern bis zu 14%. Während die Präsentation von Google zeigt, dass BBRv1 gut mit CUBIC koexistiert, finden Forscher wie Geoff Huston und Hock, Bless und Zitterbart es unfair gegenüber anderen Streams und nicht skalierbar. Hock et al. fanden auch „einige schwerwiegende inhärente Probleme wie erhöhte Warteschlangenverzögerungen, Ungerechtigkeit und massiven Paketverlust“ in der BBR-Implementierung von Linux 4.9.

Soheil Abbasloo et al. (Autoren von C2TCP) zeigen, dass BBRv1 in dynamischen Umgebungen wie Mobilfunknetzen keine gute Leistung erbringt. Sie haben auch gezeigt, dass BBR ein Unfairness-Problem hat. Wenn beispielsweise ein KUBISCHER Flow (die standardmäßige TCP-Implementierung in Linux, Android und macOS) mit einem BBR-Flow im Netzwerk koexistiert, kann der BBR-Flow den KUBISCHEN Flow dominieren und die gesamte Linkbandbreite daraus beziehen (siehe Abbildung 18 in ).

Version 2 versucht, mit dem Problem der Ungerechtigkeit umzugehen, wenn es neben einem verlustbasierten Engpassmanagement wie CUBIC betrieben wird. In BBRv2 wird das von BBRv1 verwendete Modell um Informationen über Paketverlust und Informationen aus Explicit Congestion Notification (ECN) erweitert. Während BBRv2 manchmal einen geringeren Durchsatz als BBRv1 aufweisen kann, wird allgemein davon ausgegangen, dass es einen besseren Goodput aufweist.

C2TCPEdit

Cellular Controlled Delay TCP (C2TCP) wurde durch das Fehlen eines flexiblen End-to-End-TCP-Ansatzes motiviert, der verschiedene QoS-Anforderungen verschiedener Anwendungen erfüllen kann, ohne dass Änderungen an den Netzwerkgeräten erforderlich sind. C2TCP zielt darauf ab, die Anforderungen von Anwendungen wie Virtual Reality, Videokonferenzen, Online-Spielen, Fahrzeugkommunikationssystemen usw. mit extrem niedriger Latenz und hoher Bandbreite zu erfüllen. in einem hochdynamischen Umfeld wie aktuellen LTE- und zukünftigen 5G-Mobilfunknetzen. C2TCP arbeitet als Add-on auf verlustbasiertem TCP (z.B. Reno, NewReno, CUBIC, BIC, …) und macht die durchschnittliche Verzögerung von Paketen, die an die von den Anwendungen festgelegten gewünschten Verzögerungen gebunden sind.Forscher an der NYU zeigten, dass C2TCP die Delay / Jitter-Performance verschiedener State-of-the-art TCP-Schemata übertrifft. Zum Beispiel zeigten sie, dass C2TCP im Vergleich zu BBR, CUBIC und Westwood im Durchschnitt die durchschnittliche Verzögerung von Paketen in verschiedenen Mobilfunknetzumgebungen um etwa 250%, 900% bzw. 700% verringert.

C2TCP muss nur serverseitig installiert werden.

Elastic-TCPEdit

Elastic-TCP wurde im Februar 2019 von Mohamed A. Alrshah et al. um die Bandbreitennutzung über High-BDP-Netzwerke zu erhöhen, um aktuelle Anwendungen wie Cloud Computing, Big Data Transfer, IoT usw. zu unterstützen. Es ist ein Linux-basierter CCA, der für den Linux-Kernel entwickelt wurde. Es ist ein empfängerseitiger Algorithmus, der einen Loss-Delay-basierten Ansatz mit einem neuartigen Mechanismus namens Window-Correlated Weighting Function (WWF) verwendet. Es hat ein hohes Maß an Elastizität, um mit verschiedenen Netzwerkeigenschaften umzugehen, ohne dass eine menschliche Abstimmung erforderlich ist. Es wurde bewertet, indem seine Leistung mit TCP-TCP (dem Standard-CCA in MS Windows), CUBIC (dem Standard von Linux) und TCP-BBR (dem Standard von Linux 4.9 von Google) unter Verwendung des NS-2-Simulators und des Testbeds verglichen wurde. Elastic-TCP verbessert die Gesamtleistung in Bezug auf durchschnittlichen Durchsatz, Verlustquote und Verzögerung erheblich.

NATCP/NACubicEdit

Kürzlich haben Soheil Abbasloo et. Al. vorgeschlagenes NATCP (Network-Assisted TCP) ein umstrittenes TCP-Design, das auf mobile Edge-Netzwerke wie MEC abzielt. Die Schlüsselidee von NATCP ist, dass TCP besser entwickelt worden wäre, wenn die Eigenschaften des Netzwerks im Voraus bekannt gewesen wären. Daher verwendet NATCP die verfügbaren Funktionen und Eigenschaften in den aktuellen MEC-basierten Mobilfunkarchitekturen, um die Leistung von TCP nahe an die optimale Leistung zu bringen. NATCP verwendet eine Out-of-Band-Rückmeldung vom Netzwerk an die in der Nähe befindlichen Server. Das Feedback aus dem Netzwerk, das die Kapazität der Mobilfunkverbindung und die minimale RTT des Netzwerks umfasst, leitet die Server an, ihre Senderaten anzupassen. Wie vorläufige Ergebnisse zeigen, übertrifft NATCP die State-of-the-Art TCP-Schemata durch mindestens 2x höhere Leistung (definiert als Durchsatz / Verzögerung). NATCP ersetzt das traditionelle TCP-Schema am Sender.

Um das Problem der Abwärtskompatibilität zu lösen, schlugen sie eine andere Version namens NACubic vor. NACubic ist ein abwärtskompatibles Design, das keine Änderung des TCP auf den verbundenen Knoten erfordert. NACubic verwendet das empfangene Feedback und erzwingt je nach Bedarf eine Begrenzung des Überlastungsfensters (CWND) und der Stimulationsrate.

Andere Algorithmen zur Vermeidung von TCP-Überlastungenbearbeiten

• SCHNELLES TCP
• Generalisiertes SCHNELLES TCP
• H-TCP
• Rechenzentrum-TCP
• Hochgeschwindigkeits-TCP
• HSTCP-LP
• TCP-Lp
• TCP-LP
• TCP-LP
• Skalierbares TCP
• TCP Veno
• Westwood
• XCP
• YeAH-TCP
• TCP-FIT
• Überlastungsvermeidung mit normalisiertem Zeitintervall (CANIT)
• Nichtlineare Überlastungskontrolle neuronaler Netze basierend auf einem genetischen Algorithmus für TCP/IP-Netzwerke

TCP New Reno war das am häufigsten implementierte Protokoll für die SACK-Unterstützung ist jedoch sehr verbreitet und eine Erweiterung von Reno / New Reno. Die meisten anderen sind konkurrierende Vorschläge, die noch evaluiert werden müssen. Ab 2.6.8 hat der Linux-Kernel die Standardimplementierung von New Reno auf BIC umgestellt. Die Standardimplementierung wurde in der Version 2.6.19 erneut in CUBIC geändert. FreeBSD verwendet New Reno als Standardalgorithmus. Es unterstützt jedoch eine Reihe anderer Optionen.

Wenn das Pro-Flow-Produkt aus Bandbreite und Latenz unabhängig vom Warteschlangenschema zunimmt, wird TCP ineffizient und anfällig für Instabilität. Dies wird immer wichtiger, da sich das Internet weiterentwickelt, um optische Verbindungen mit sehr hoher Bandbreite zu integrieren.TCP Interactive (iTCP) ermöglicht es Anwendungen, TCP-Ereignisse zu abonnieren und entsprechend zu reagieren, wodurch verschiedene funktionale Erweiterungen von TCP von außerhalb der TCP-Schicht ermöglicht werden. Die meisten TCP-Überlastungsschemata arbeiten intern. iTCP ermöglicht außerdem erweiterten Anwendungen, direkt an der Überlastungskontrolle teilzunehmen, z. B. um die Quellgenerierungsrate zu steuern.

Zeta-TCP erkennt die Überlastungen sowohl anhand der Latenz- als auch der Verlustratenmessung und wendet verschiedene Überlastungsfenster-Backoff-Strategien an, die auf der Wahrscheinlichkeit der Überlastungen basieren, um den Goodput zu maximieren. Es hat auch ein paar andere Verbesserungen, um die Paketverluste genau zu erkennen, die Vermeidung von Retransmission Timeout Retransmission; und beschleunigen / steuern den eingehenden (Download) Verkehr.