Data Center Quantized Congestion Notification

Abkürzung: DCQCN

DCQCN ist das verbreitete Stauregelungsverfahren für RoCEv2: Es kombiniert ECN-Markierung im Switch mit Ratenregelung in der Netzwerkkarte.

Herkunft

DCQCN wurde 2015 von Microsoft und Mellanox auf der SIGCOMM vorgestellt (Zhu et al.). Anlass war der Einsatz von RoCEv2 in Microsoft-Rechenzentren: PFC allein sorgte zwar für Verlustfreiheit, führte aber zu Head-of-Line-Blocking, Unfairness zwischen Flows und Ausbreitung von Staus durch die Fabric. DCQCN setzt eine Ebene darüber an und drosselt die Sender, bevor PFC auslösen muss.

Das Verfahren ist kein Standard. Die IBTA-Spezifikation (Annex A17) definiert nur das Format des Congestion Notification Packet (CNP) und verlangt, dass RoCEv2-Endpunkte auf CNPs reagieren; der Algorithmus selbst ist Sache der NIC-Firmware. DCQCN ist seit der ConnectX-4-Generation in Mellanox-/NVIDIA-NICs implementiert und wurde von anderen Herstellern übernommen, sodass es faktisch die Referenz für RoCEv2-Fabrics ist.

Beteiligte

DCQCN übernimmt das Rollenmodell von QCN (IEEE 802.1Qau), überträgt es aber von Layer 2 auf IP:

Congestion Point (CP): der Switch. Er markiert Pakete per ECN (RED-Verfahren mit Kmin, Kmax, Pmax) und tut sonst nichts.
Notification Point (NP): die empfangende NIC. Sie erkennt CE-markierte Pakete und sendet CNPs an den Absender.
Reaction Point (RP): die sendende NIC. Sie regelt die Senderate pro Queue Pair anhand der empfangenen CNPs.

Ablauf am Notification Point

Der NP sendet pro Queue Pair höchstens ein CNP je Zeitintervall (im Originalentwurf 50 µs), unabhängig davon, wie viele markierte Pakete in dieser Zeit ankommen. Das begrenzt die CNP-Last und glättet das Signal. CNPs laufen in einer eigenen, hoch priorisierten Verkehrsklasse, damit sie den Stau, den sie melden, nicht selbst durchqueren müssen.

Ablauf am Reaction Point

Der RP führt pro Queue Pair eine aktuelle Rate Rc, eine Zielrate Rt und eine Staustärke-Schätzung α.

Ratenreduktion bei Eintreffen eines CNP:

Rt = Rc (aktuelle Rate wird zur neuen Zielrate)
Rc = Rc · (1 − α/2)
α = (1 − g) · α + g

Der Faktor g (Standard 1/256) bestimmt, wie schnell α auf CNPs reagiert. α steigt mit jedem CNP und fällt über einen Timer wieder ab, wenn keine CNPs mehr eintreffen: α = (1 − g) · α.

Ratenerhöhung in drei Stufen, ausgelöst durch einen Timer und einen Bytezähler, wenn keine CNPs mehr eintreffen:

Fast Recovery: Rc nähert sich in mehreren Schritten der Zielrate Rt an, Rc = (Rt + Rc)/2.
Additive Increase: Rt wird um einen festen Betrag Rai erhöht, Rc folgt.
Hyper Increase: nach anhaltender Staufreiheit wird Rt um einen größeren Betrag Rhai erhöht.

Die Trennung von Rc und Rt sorgt dafür, dass sich ein Sender nach kurzer Drosselung schnell wieder seiner vorherigen Rate nähert, ohne sofort erneut den Stau auszulösen.

Zusammenspiel mit PFC und ECN

DCQCN funktioniert nur, wenn die Schwellwerte aufeinander abgestimmt sind: Die ECN-Markierung (Kmin, Kmax) muss deutlich früher greifen als der PFC-Xoff-Schwellwert, sonst pausiert PFC, bevor die Sender ihre Rate senken konnten. Umgekehrt darf Kmin nicht so niedrig liegen, dass Sender bei normaler Last gedrosselt werden. Die Originalarbeit leitet aus Puffergröße, Anzahl der Ports und Headroom eine obere Grenze für Kmax ab und zeigt, dass PFC in einer korrekt parametrierten Fabric nur noch als Ausnahme auslöst.

Die Parameter g, Rai, Rhai, Timer- und Bytezähler-Schwellen sind in der NIC-Firmware einstellbar. Herstellervorgaben sind ein Ausgangspunkt, für große Fabrics werden sie meist angepasst.

Grenzen

Parameterempfindlichkeit: Fehlabstimmung zwischen Switch-ECN und NIC-Parametern ist die häufigste Ursache für schlechte RoCEv2-Leistung.
Konvergenz: Bei vielen Flows auf einem Engpass (Incast) konvergiert DCQCN langsam und ungleichmäßig.
Signalqualität: ECN liefert nur ein Bit pro Paket vom letzten markierenden Switch; Ausmaß und Ort des Staus bleiben unbekannt.
Ein Pfad pro QP: DCQCN regelt pro Verbindung, nicht pro Pfad, und passt nicht zu Packet Spraying.

Nachfolgeverfahren setzen deshalb auf andere Signale: TIMELY (Google, 2015) und Swift (Google, 2020) messen die Round-Trip-Zeit, HPCC (Alibaba, 2019) nutzt In-band Network Telemetry mit exakten Warteschlangendaten. Ultra Ethernet definiert mit NSCC und RCCC eigene Stauregelung, die auf Packet Spraying ausgelegt ist.

Normen und Quellen

Zhu et al.: Congestion Control for Large-Scale RDMA Deployments, SIGCOMM 2015
IEEE 802.1Qau-2010 (Quantized Congestion Notification), heute IEEE 802.1Q Clause 30–33
IBTA: InfiniBand Architecture Specification Vol. 1, Annex A17 (RoCEv2, CNP-Format)
Mittal et al.: TIMELY: RTT-based Congestion Control for the Datacenter, SIGCOMM 2015
Li et al.: HPCC: High Precision Congestion Control, SIGCOMM 2019
Kumar et al.: Swift: Delay is Simple and Effective for Congestion Control in the Datacenter, SIGCOMM 2020