Imagine you’ve just spent $500 million on a state-of-the-art GPU cluster. You have 32,000 NVIDIA H100s sitting in pristine racks, liquid cooling humming, and enough compute power to simulate the universe. You fire up a massive All-Reduce operation to sync gradients across the fleet for a trillion-parameter LLM.
Then, everything grinds to a halt.
The GPUs are sitting idle, waiting. Your $10,000-per-hour cluster is twitching because of a packet drop. Not a hardware failure, not a bug—just a simple case of traffic congestion.
In the world of standard web services, a 50ms delay is a minor annoyance. In a synchronous AI training job, that same delay creates a "tail latency" monster that can reduce your effective compute utilization by 30% or more. This is the billion-dollar problem of Congestion Control (CC) in data-center networks (DCNs).
Today, we’re going under the hood of how the industry is moving past traditional Ethernet to build the "lossless" fabrics required for the AI era.
The Anatomy of a Collision: Why Standard Networking Fails AI
In a typical web environment (think Netflix or Uber), traffic is "North-South"—from the data center to the user. If a packet drops, TCP handles the retransmission, the user’s buffer absorbs the jitter, and life goes on.
AI clusters are different. They are "East-West" heavy. During the "All-Reduce" or "All-to-All" phases of distributed training, every GPU tries to talk to every other GPU simultaneously. This leads to the Incast Problem: dozens of 400Gbps streams hitting a single switch port at the exact same microsecond.
The Buffer Bloat and the Drop
Standard switches have small shared buffers. When an Incast storm hits:
- The switch buffer fills instantly.
- The switch has no choice but to drop packets (Tail Drop).
- The sender (the GPU/NIC) realizes the packet is gone after a timeout.
- The sender retransmits.
This cycle is lethal for AI. Because training is synchronous (BSP - Bulk Synchronous Parallel), the entire 32,000-GPU cluster moves only as fast as the slowest packet. A single dropped packet on one switch can stall the entire training epoch.
The Rise of RDMA and the "Lossless" Dream
To bypass the overhead of the CPU and the slow, heavy TCP stack, AI clusters use RDMA (Remote Direct Memory Access). Specifically, RoCE v2 (RDMA over Converged Ethernet).
RDMA allows one GPU to write directly into the memory of another GPU without involving the OS kernel. It’s incredibly fast, but it’s also "brittle." RDMA assumes the network is a "lossless fabric." If a packet drops in a pure RDMA environment, the hardware doesn't have the sophisticated recovery mechanisms of the Linux TCP stack. It simply chokes.
To make Ethernet lossless, the industry initially leaned on PFC (Priority Flow Control).
Priority Flow Control: The Big Red Button
PFC is a hop-by-hop flow control mechanism. When a switch's buffer starts filling up, it sends a "PAUSE" frame to the upstream neighbor, telling it to stop sending for a few nanoseconds.
The Problem? It's too blunt an instrument.
- Head-of-Line (HoL) Blocking: You pause a whole port because one flow is congested, even if the other flows on that port were heading to an empty, uncongested part of the network.
- Congestion Spreading: A single hot spot can cause a chain reaction of PAUSE frames that eventually "locks up" the entire data center (a phenomenon known as a PFC Storm).
We needed something smarter. We needed a way to slow down the source, not just pause the link.
Deep Dive: The Algorithms of Modern Congestion Control
The goal of modern CC is to achieve the "Golden Trinity": High Throughput, Low Latency, and Zero Packet Loss.
1. DCQCN (Data Center Quantized Congestion Notification)
If you are running an NVIDIA/Mellanox fabric today, you are likely using DCQCN. It is a hybrid algorithm that combines:
- ECN (Explicit Congestion Notification): Switches mark the IP header of packets when they see their queues growing.
- QCN (Quantized Congestion Notification): A rate-based hardware mechanism.
How it works in the trenches:
- The Switch: Monitors its queue depth. If it exceeds a threshold (K_min), it starts marking packets with a CE (Congestion Experienced) bit.
- The Receiver (Destination NIC): Sees the CE bit. It sends a Congestion Notification Packet (CNP) back to the sender.
- The Sender (Source NIC): Receives the CNP and immediately slashes its injection rate. It then gradually increases the rate (multiplicative decrease, additive increase) as long as no more CNPs arrive.
The Critique: DCQCN is notoriously hard to tune. You have about 15 different parameters (alpha, beta, timers, thresholds). Get it wrong, and you either have an underutilized network or a sea of PAUSE frames.
2. Google’s Swift: Delay-based Control
Google took a different path. Instead of relying on switch markings (ECN), which can be slow to propagate, they developed Swift.
Swift uses RTT (Round Trip Time) as its primary signal. By using high-precision hardware timestamps (often provided by the NIC), Swift can detect congestion the moment the RTT increases by even a few microseconds—long before a switch buffer actually overflows.
# A conceptual simplified snippet of a Swift-like logic
def update_rate(current_rtt, target_rtt, current_rate):
if current_rtt > target_rtt:
# We are seeing queue build-up, slow down!
new_rate = current_rate * (target_rtt / current_rtt)
else:
# Clear skies, speed up!
new_rate = current_rate + additive_increase_constant
return new_rate
3. HPCC (High Precision Congestion Control)
HPCC is the "new hotness" emerging from Alibaba and the academic community. It moves away from "guessing" based on ECN or RTT and moves toward In-band Network Telemetry (INT).
In HPCC, the switch actually writes its internal state (queue length, link utilization, timestamp) directly into the packet header as it passes through.
When the packet reaches the destination, the destination sends this precise metadata back to the sender. The sender doesn't just know "there is congestion"; it knows exactly how many bytes are in the queue at every hop. This allows the sender to calculate the precise rate needed to fill the pipe without overshooting. It can converge to the optimal rate in just one RTT.
The Hardware Frontier: SmartNICs and Programmable Silicon
We are moving away from "fixed-function" networking. The logic of congestion control is migrating from the switch OS into two specific places:
The SmartNIC (The DPU)
Modern NICs (like the NVIDIA BlueField or AMD Pensando) are essentially mini-servers. They handle the Congestion Control logic in hardware state machines. Why? Because at 400Gbps, a packet arrives every ~2 nanoseconds. You cannot wait for a CPU interrupt to decide whether to slow down a flow. The CC logic must be etched into the ASIC or handled by a massively parallel array of tiny RISC-V cores.
Programmable Switches (P4)
Enter P4. Traditionally, switches were black boxes. With P4-programmable chips (like Intel Tofino), network engineers can write custom code to handle congestion. Want to implement a new CC algorithm that prioritizes "Small Flows" (short-lived metadata) over "Large Flows" (gradient transfers)? You can write that logic in P4 and compile it directly onto the switch's pipeline.
The Hype Context: Why is "Ultra Ethernet" a Thing?
If you’ve been following tech news, you’ve likely seen the Ultra Ethernet Consortium (UEC). It includes heavy hitters like AMD, Arista, Broadcom, Google, and Meta.
The elephant in the room: NVIDIA owns the "gold standard" AI interconnect—InfiniBand. InfiniBand is a credit-based, natively lossless architecture. It's fantastic, but it’s proprietary and expensive.
The UEC is an industry-wide attempt to "InfiniBand-ify" Ethernet. They are re-architecting the transport layer to support:
- Flexible Ordering: Traditional Ethernet requires packets to arrive in order. If packet #1 is lost, packets #2-100 sit in a buffer waiting. UEC wants to allow out-of-order delivery, which makes it much easier to multi-path traffic across every available link in the data center.
- Modern Congestion Control: Standardizing the telemetry-based approaches (like HPCC) so that a Broadcom switch can talk to an AMD NIC and a Cisco router using a unified, high-precision congestion language.
Engineering Challenges: The "Silent" Performance Killers
Even with the best CC algorithms, two major issues haunt data center engineers:
1. The Multi-tenant Noise
In a cloud environment, your AI training job might be sharing a switch with a bunch of random microservices. If a "noisy neighbor" starts a massive backup, it can trigger ECN marks that slow down your AI training. The Solution: Strict traffic isolation using VLANs with dedicated hardware queues for RoCE traffic. Most engineers now map AI traffic to "Lossless Queues" and everything else to "Best-effort Queues."
2. Micro-bursts
Congestion isn't always a steady stream. Often, it's a "micro-burst"—a surge of packets that lasts only 10 microseconds. Standard monitoring tools like Prometheus (which polls every few seconds) will never see it. To debug these, we use Mirroring on Drop features. When a switch drops a packet, it sends a copy of that packet (plus a metadata header explaining why it was dropped) to a collector. This is the only way to see the "ghosts in the machine."
Looking Ahead: Scheduled Fabrics
We are reaching the limits of "reactive" congestion control. No matter how fast you react to a congestion signal, the signal still takes one RTT to reach you. At scale, that delay is too long.
The next frontier is Scheduled Fabrics. Instead of a sender just "blasting" packets and hoping they fit, the sender must request a "timeslot" from a centralized or distributed arbiter.
Think of it like a train system. Current Ethernet is like cars entering a highway—everyone merges and hopes for the best, leading to traffic jams. A Scheduled Fabric is like a train schedule; a packet only enters the wire if the fabric has guaranteed a clear path for it from source to destination.
Broadcom’s Jericho3-AI chips are already moving in this direction, using a "Cell-based" fabric instead of a "Packet-based" fabric. They break packets into tiny cells and spread them perfectly across all paths, reassembling them at the other end.
The Bottom Line
Congestion control in AI clusters is no longer a "network problem"—it's a distributed systems problem.
As we move toward 800Gbps and 1.6Tbps links, the margin for error evaporates. The future of AI training won't just be won by whoever has the fastest GPUs; it will be won by whoever can keep those GPUs fed with a perfectly orchestrated, zero-loss, jitter-free stream of data.
If you're building in this space, remember: Bandwidth is cheap, but latency is the speed of light, and buffer space is the most expensive real estate in your data center. Tune your ECN thresholds, watch your tail latencies, and keep an eye on the Ultra Ethernet Consortium. The era of "best-effort" networking is officially over.