Explicit Congestion Notification

Abkürzung: ECN

ECN nach RFC 3168 markiert IP-Pakete bei drohender Überlast, statt sie zu verwerfen, und ist die Signalbasis für DCQCN in RoCEv2-Fabrics.

Zweck

Ohne ECN erfährt ein Sender von Überlast nur indirekt: durch Paketverlust, der erst nach einem Timeout oder doppelten Bestätigungen erkannt wird. Bis dahin ist der Puffer im Switch bereits übergelaufen. ECN erlaubt einem Router oder Switch, ein Paket beim Anwachsen der Warteschlange zu markieren und unverändert weiterzuleiten. Der Empfänger meldet die Markierung an den Sender, der seine Sendedatenrate senkt, bevor Verluste auftreten.

ECN wurde 2001 in RFC 3168 für IP und TCP standardisiert. Im Rechenzentrum ist es heute vor allem als Signalgeber für RDMA-Stauregelung relevant, da RoCEv2 Paketverluste nur schlecht verkraftet.

Codierung im IP-Header

ECN belegt die beiden niederwertigsten Bits des Feldes Traffic Class (IPv6) bzw. des früheren Type-of-Service-Oktetts (IPv4), direkt hinter den sechs DSCP-Bits.

Ein Switch darf nur Pakete mit ECT-Markierung auf CE setzen. Pakete mit 00 werden bei Überlast wie bisher verworfen.

Markierung im Switch

Wann ein Switch markiert, legt nicht ECN fest, sondern das Active Queue Management der Warteschlange. Üblich ist RED (Random Early Detection) mit ECN-Modus: Unterhalb eines Minimum-Schwellwerts (Kmin) wird nicht markiert, oberhalb eines Maximum-Schwellwerts (Kmax) jedes Paket, dazwischen mit linear steigender Wahrscheinlichkeit bis Pmax. Die Schwellwerte beziehen sich auf die Füllung der Ausgangswarteschlange in Byte oder Zellen.

Die Wahl von Kmin, Kmax und Pmax bestimmt das Verhalten der gesamten Stauregelung. Zu niedrige Werte drosseln die Sender unnötig, zu hohe lassen die Warteschlange so weit wachsen, dass PFC auslöst. Für RoCEv2 müssen die ECN-Schwellwerte deutlich unter dem PFC-Xoff-Schwellwert liegen.

Rückmeldung an den Sender

ECN im IP-Header ist nur die halbe Signalstrecke. Wie die CE-Markierung zum Sender zurückgelangt, definiert das Transportprotokoll:

• TCP (RFC 3168): Der Empfänger setzt das ECE-Flag in seinen Bestätigungen, der Sender halbiert sein Congestion Window wie bei einem Verlust und quittiert mit CWR. RFC 8311 lockert diese Vorgabe für neuere Verfahren; DCTCP (RFC 8257) reagiert proportional zum Anteil markierter Pakete statt mit fester Halbierung.
• RoCEv2 (IBTA Annex A17): Der Empfänger sendet ein Congestion Notification Packet (CNP) an den Sender. Die Reaktion darauf regelt DCQCN.
• Ultra Ethernet: UET wertet CE-Markierungen zusammen mit weiteren Signalen (Packet Trimming, Round-Trip-Messung) in der Congestion Management Sublayer aus.

Konfiguration für RoCEv2

Der RDMA-Verkehr muss ECT-markiert gesendet werden; das erledigt die NIC. Auf jedem Switch im Pfad ist ECN-Markierung für die verlustfreie Warteschlange zu aktivieren, mit einheitlichen Schwellwerten in der gesamten Fabric. CNPs laufen in einer eigenen, höher priorisierten Klasse, damit sie nicht selbst im Stau hängen bleiben.

Herstellerangaben zu Kmin/Kmax für 100–400 GbE liegen typischerweise im Bereich weniger hundert bis weniger tausend KByte; die Werte hängen von Puffergröße, Anzahl der Ports und RTT ab und sind pro Plattform zu bestimmen.

Grenzen

ECN signalisiert nur binär pro Paket und nur die Warteschlange des markierenden Switches. Der Sender erfährt weder das Ausmaß der Überlast noch ihren Ort. In sehr großen Fabrics mit Packet Spraying über viele Pfade verliert das Signal zusätzlich an Aussagekraft, da markierte und unmarkierte Pakete derselben Nachricht über verschiedene Pfade laufen. Verfahren wie HPCC (In-band Network Telemetry) oder die UET-Stauregelung ergänzen ECN deshalb um genauere Messwerte.