Priority-based Flow Control

Abkürzung: PFC

PFC ist eine Ethernet-Flusskontrolle nach IEEE 802.1Q, die einzelne Prioritätsklassen eines Links pausiert und so verlustfreie Übertragung ermöglicht.

Zweck

Klassisches Ethernet verwirft Frames, wenn ein Switch-Puffer voll ist; höhere Schichten wie TCP gleichen das aus. Protokolle ohne diese Fähigkeit – RoCEv2, FCoE oder iSCSI in Storage-Netzen – reagieren auf Verlust mit drastischem Leistungseinbruch. PFC hält den Sender rechtzeitig an, bevor der Puffer überläuft, und macht so einzelne Verkehrsklassen auf einem Ethernet-Link verlustfrei.

PFC ist Teil von Data Center Bridging (DCB), zusammen mit Enhanced Transmission Selection (ETS) und dem Aushandlungsprotokoll DCBX. Ursprünglich als IEEE 802.1Qbb-2011 veröffentlicht, ist es heute Clause 36 der Basisnorm IEEE 802.1Q.

Abgrenzung zu IEEE 802.3x PAUSE

Die ältere Flusskontrolle nach IEEE 802.3x (Annex 31B) pausiert den gesamten Link. Ein einziger überlasteter Verkehrsstrom stoppt damit auch alle unbeteiligten. PFC arbeitet stattdessen pro Priorität: Der Link trägt acht Klassen (Priority Code Point im 802.1Q-Tag, 0–7), und jede kann unabhängig angehalten werden. Verlustfreier RDMA-Verkehr und verlustbehafteter TCP-Verkehr teilen sich so denselben Link, ohne dass ein PAUSE des einen den anderen trifft.

Funktionsweise

Der Empfänger überwacht die Pufferfüllung pro Priorität. Überschreitet sie den Xoff-Schwellwert, sendet er einen PFC-Frame an den direkten Nachbarn:

MAC-Control-Frame, EtherType 0x8808, Opcode 0x0101
Zieladresse 01-80-C2-00-00-01 (wird von Bridges nicht weitergeleitet, wirkt nur auf dem Link)
Bitmaske für die zu pausierenden Prioritäten
Pausendauer je Priorität in Quanta zu 512 Bit-Zeiten, maximal 65.535 Quanta

Der Sender stoppt die Übertragung der genannten Prioritäten für die angegebene Zeit oder bis ein Frame mit Dauer 0 (Xon) eintrifft. Sinkt die Pufferfüllung unter den Xon-Schwellwert, hebt der Empfänger die Pause auf.

PFC wirkt hop-by-hop. Staut sich der Verkehr an einem Switch, propagiert die Pause rückwärts durch die Fabric bis zum Ursprung – der Stau breitet sich also aus, statt an einem Punkt abgebaut zu werden.

Headroom

Zwischen dem Aussenden des PFC-Frames und dem tatsächlichen Stopp des Senders vergeht Zeit: Verarbeitung im Empfänger, Laufzeit des PFC-Frames, Fertigstellung des gerade gesendeten Frames beim Sender, Laufzeit der bereits unterwegs befindlichen Daten. Der Empfänger muss für diese Zeit Pufferplatz (Headroom) vorhalten, sonst gehen trotz PFC Frames verloren. Der Headroom wächst mit Datenrate und Kabellänge; bei 400 GbE und 100 m Glasfaser liegt er im Bereich mehrerer 100 KByte pro Port und Priorität. Falsch dimensionierter Headroom ist eine häufige Fehlerquelle bei RoCEv2-Fabrics.

Probleme im Betrieb

Head-of-Line-Blocking: Ein pausierter Port hält auch Frames zurück, die für nicht überlastete Ziele bestimmt sind.
PFC-Stürme: Ein defekter Endpunkt oder eine fehlerhafte NIC, die dauerhaft PFC sendet, kann eine ganze Fabric lahmlegen. Switches bieten dagegen einen PFC-Watchdog, der eine Priorität nach anhaltender Pause zwangsweise freigibt und Frames verwirft.
Deadlocks: Bei zyklischen Pufferabhängigkeiten über mehrere Switches können sich Pausen gegenseitig blockieren. In Clos-Topologien tritt das nur bei Fehlkonfiguration oder Umleitungen nach Linkausfall auf, ist dann aber schwer zu diagnostizieren.
Fairness: PFC unterscheidet nicht zwischen den Flows einer Priorität; ein aggressiver Sender bremst alle anderen mit.

Wegen dieser Probleme gilt PFC in RoCEv2-Fabrics als letzte Sicherung, nicht als primäre Stauregelung. Die Rate der Sender soll vorher über ECN und DCQCN so weit gedrosselt werden, dass PFC selten auslöst.

Konfiguration für RoCEv2

Üblich ist eine einzige verlustfreie Priorität (oft 3) für RDMA-Verkehr, ergänzt um eine weitere hochpriorisierte, verlustfreie oder strikt bevorzugte Klasse für Congestion Notification Packets (oft 6). Da RoCEv2 über IP geroutet wird, muss die Zuordnung auf beiden Ebenen konsistent sein: DSCP im IP-Header auf L3, PCP im VLAN-Tag auf L2. Switches im Trust-Modus DSCP leiten die Priorität aus dem IP-Header ab, sodass PFC auch auf ungetaggten Links funktioniert. NIC, Switch und Endpunkt müssen dieselben Zuordnungen verwenden; DCBX kann das aushandeln, wird in großen Fabrics aber meist durch statische Konfiguration ersetzt.

Normen und Quellen

IEEE 802.1Q-2022, Clause 36 (Priority-based Flow Control), Clause 37 (ETS), Clause 38 (DCBX); ursprünglich IEEE 802.1Qbb-2011
IEEE 802.3, Annex 31B (MAC Control PAUSE)
Guo et al.: RDMA over Commodity Ethernet at Scale, SIGCOMM 2016
Hu et al.: Deadlocks in Datacenter Networks: Why Do They Form, and How to Avoid Them, HotNets 2016
IBTA: InfiniBand Architecture Specification Vol. 1, Annex A17 (RoCEv2)