DCTCP vs. CUBIC – welcher TCP-Algorithmus passt zu welchem Netzwerk?
Ein technischer Tiefgang – und warum die Wahl des Congestion-Algorithmus deine Latenz um bis zu 40% beeinflusst.
Wenn Windows Daten über ein Netzwerk sendet, stellt sich ständig die gleiche Frage: Wie schnell darf ich senden, ohne das Netzwerk zu überlasten? Die Antwort darauf gibt der Congestion-Control-Algorithmus. Windows verwendet standardmäßig CUBIC – und das ist in vielen Szenarien die falsche Wahl.
In diesem Artikel erkläre ich wie CUBIC und DCTCP intern funktionieren, wo jeder Algorithmus seine Stärken hat – und für welchen Use Case welcher Algorithmus besser geeignet ist.
Was ist Congestion Control überhaupt?
TCP ist zuverlässig – jedes Paket wird bestätigt. Aber wenn alle Verbindungen gleichzeitig so schnell senden wie möglich, bricht das Netzwerk zusammen. Congestion Control regelt die Senderate so, dass das Netzwerk nicht überlastet wird.
Das Grundprinzip ist immer gleich: Die Senderate wird erhöht solange alles gut geht, und reduziert wenn Überlastung erkannt wird. Der entscheidende Unterschied liegt darin, wie Überlastung erkannt wird – und genau hier unterscheiden sich CUBIC und DCTCP fundamental.
Das Congestion Window bestimmt wie viele Bytes maximal gleichzeitig “in flight” sein dürfen – also gesendet aber noch nicht bestätigt. Je größer das CWND, desto höher der Durchsatz.
CUBIC – der Windows-Standard
CUBIC ist seit Windows 8 der Standard-Congestion-Algorithmus in Windows. Er wurde entwickelt um in Hochgeschwindigkeitsnetzwerken mit langer Round-Trip-Zeit (RTT) gut zu funktionieren – also auf Transatlantikverbindungen, Backbone-Verbindungen und im WAN.
Wie CUBIC Überlastung erkennt
CUBIC erkennt Netzwerküberlastung ausschließlich an Paketverlusten. Das bedeutet:
Das Problem: Um Paketverlust zu erzeugen, müssen Puffer in Routern und Switches komplett vollaufen und überlaufen. Erst dann werden Pakete verworfen. Bis dahin hat CUBIC die Senderate bereits weit über das verträgliche Maß erhöht.
Das Ergebnis ist das typische „Sägezahn”-Muster: Senderate steigt → Puffer läuft voll → Latenz steigt → Paketverlust → CWND halbiert → Latenz sinkt kurz → Zyklus beginnt von vorne. Im LAN passiert das alle paar Millisekunden.
Auf kurzen Verbindungen (LAN, RZ) ist die RTT so klein, dass das Sägezahn-Muster sehr schnell oscilliert. Die Puffer laufen ständig voll und wieder leer. Latenzspitzen von 5–50 ms im LAN sind bei aktivem CUBIC keine Seltenheit.
DCTCP – Data Center TCP
DCTCP wurde 2010 von Microsoft Research, Facebook und anderen entwickelt – speziell für Rechenzentrumsumgebungen mit niedrigen RTTs. Der entscheidende Unterschied: DCTCP reagiert nicht auf Paketverlust, sondern auf ECN-Markierungen.
Wie DCTCP Überlastung erkennt
ECN (Explicit Congestion Notification, RFC 3168) ermöglicht es Routern und Switches, Pakete zu markieren wenn ihre Puffer einen Schwellwert überschreiten – bevor Pakete verworfen werden.
1. Puffer im Switch erreicht ECN-Schwellwert → Switch markiert Pakete mit CE-Flag (Congestion Experienced)
2. Empfänger sieht markierte Pakete → meldet zurück wie viele Pakete markiert waren (als Anteil)
3. Sender berechnet α = Anteil markierter Pakete (0.0 bis 1.0)
4. CWND wird proportional reduziert: CWND = CWND × (1 – α/2) – je mehr markiert, desto stärker die Reduktion
Das Resultat: DCTCP reguliert die Senderate kontinuierlich und graduell anstatt abrupt zu halbieren. Die Puffer bleiben auf einem niedrigen, stabilen Füllstand – was direkt zu niedrigerer und konstanterer Latenz führt.
Direkter Vergleich
| Kriterium | CUBIC | DCTCP |
|---|---|---|
| Überlastungs-Signal | Paketverlust | ECN-Markierung |
| Reaktion | CWND halbieren (abrupt) | CWND graduell reduzieren |
| Pufferfüllstand | Hoch (Sägezahn) | Niedrig und stabil |
| Latenz im LAN | Hoch, schwankend | Niedrig, konstant |
| Latenz im WAN (hohe RTT) | Gut (optimiert dafür) | Eingeschränkt |
| Benötigt ECN | Nein | Ja (fällt ohne ECN auf CUBIC-Verhalten zurück) |
| Ideal für | Internet, WAN, hohe RTT | LAN, RZ, Gaming, RDP |
Wann DCTCP, wann CUBIC?
- Gaming (niedrige Latenz entscheidend)
- RDP / VNC / SSH (interaktive Verbindungen)
- LAN-Verbindungen (RTT <1 ms)
- Rechenzentrum / Server-zu-Server
- VoIP und Videokonferenzen im LAN
- Netzwerk mit ECN-fähigen Switches
- Transatlantik-Verbindungen (RTT >50 ms)
- Switches/Router ohne ECN-Unterstützung
- Maximaler Rohdurchsatz über WAN
- Ältere Netzwerkinfrastruktur
- Unbekannte Netzwerktopologie
DCTCP ohne aktives ECN fällt intern auf ein CUBIC-ähnliches Verhalten zurück. Beide Einstellungen müssen zusammen aktiviert werden:
congestionprovider=DCTCP und ECN=Enabled.DCTCP + ECN in Windows aktivieren
Entweder manuell per PowerShell (als Administrator):
Oder vollautomatisch mit dem ISW TCP Optimizer Pro – der aktiviert DCTCP + ECN zusammen mit allen anderen Latenz-Optimierungen, erstellt vorher ein Registry-Backup und dokumentiert alle Änderungen im Delta-Report.
- CUBIC erkennt Überlastung durch Paketverlust – zu spät und zu abrupt
- DCTCP erkennt Überlastung durch ECN-Markierungen – früh und graduell
- Im LAN (RTT <5 ms): DCTCP + ECN ist fast immer besser
- Im WAN mit hoher RTT: CUBIC bleibt die zuverlässigere Wahl
- Für Workstations, Gaming-PCs und Server im eigenen Netz: DCTCP aktivieren