What is DCQCN
DCQCN (Data Center Quantized Congestion Notification) is a hybrid congestion control algorithm designed for RoCEv2 networks, built to balance throughput and latency in lossless Ethernet fabrics. It combines two mechanisms that each fall short on their own — ECN (Explicit Congestion Notification) and PFC (Priority Flow Control) — into a single, layered strategy: ECN steps in early to throttle senders gradually, and PFC stands by as a fail-safe to prevent packet loss if congestion intensifies anyway.
To see why that combination matters, it helps to start with RDMA (Remote Direct Memory Access), widely used in HPC, AI training, and storage. RDMA originated on InfiniBand and later evolved onto Ethernet through iWARP and RoCE (RDMA over Converged Ethernet). RoCEv2 carries RDMA traffic over UDP, which has no built-in congestion control of its own — so the network itself has to provide end-to-end congestion management to keep performance lossless. A PFC-only approach risks head-of-line blocking, because it halts traffic too aggressively. An ECN-only approach reacts too slowly, so buffers can still overflow and packets can still be lost before senders slow down. Neither works well alone, which is exactly the gap DCQCN fills.
How DCQCN Works
DCQCN follows a structured, three-step hierarchy, with each step engaging only when the previous one isn't enough.
1. ECN first — proactive intervention. As a switch's egress queues begin to build up and breach configured WRED thresholds, the switch marks passing packets by setting their CE (Congestion Experienced) bits. The destination node, upon receiving these marked packets, generates CNPs (Congestion Notification Packets) and sends them back toward the sender. When the sender receives a CNP, it smoothly scales down its injection rate — easing pressure on the network without ever halting traffic entirely.
2. PFC second — reactive safeguard. If congestion keeps building despite ECN's rate reduction, and buffer occupancy reaches the xOFF threshold, the switch sends a PAUSE frame upstream. This temporarily halts transmission for the affected queue, guaranteeing zero packet loss — hop-by-hop backpressure acting as a last line of defense against buffer overflow.
3. Flow recovery. Once buffer occupancy drops back below the xON threshold, the switch sends a RESUME frame upstream, notifying the upstream device that transmission can safely continue.
The design logic is deliberate: ECN is the smooth, preferred response, shaving rate down gradually before things get critical; PFC is the blunt backstop, invoked only when ECN alone hasn't been fast enough. Tuning the WRED/ECN thresholds to trigger well before the PFC xOFF threshold is what keeps PFC from firing frequently — and is a key part of what makes a lossless fabric perform well rather than just technically avoid loss.
Why DCQCN is Beneficial
Balances throughput and latency: By letting ECN do the first, gentler round of rate reduction, DCQCN keeps links busy and queues short, rather than defaulting to the more disruptive stop-and-wait behavior of PFC alone.
Avoids PFC-only head-of-line blocking: Because PFC is a fallback rather than the primary response, DCQCN sidesteps the problem of PFC pausing traffic too aggressively and stalling flows that weren't part of the congestion.
Avoids ECN-only packet loss: PFC's backpressure covers the reaction-time gap ECN can leave open, so a burst that outpaces the sender's rate reduction still doesn't overflow a buffer and drop packets.
Fits the traffic patterns of AI training: AI backend fabrics carry bursty, high-bandwidth collective-communication traffic where a single congested link can stall an entire training job — exactly the environment where smooth, early congestion response and a hard zero-loss guarantee both matter.
Works end-to-end rather than per-link: Because the sender itself reduces its rate in response to CNPs, DCQCN addresses congestion at its source, not just at the point where it happens to show up.