Peak
Fabric.

The dominant congestion control algorithm for RoCE v2 is **DCQCN (Data Center Quantized Congestion Notification)**, a rate-based scheme that combines Explicit Congestion Notification (ECN) with a multi-stage rate adaptation engine. Understanding DCQCN's parameter tuning is essential for any engineer operating at 800G line rates, where the feedback loop must respond in microseconds, not milliseconds.

DCQCN operates in three distinct phases. The **Congestion Point** (typically a switch egress port) monitors its queue depth. When the queue exceeds a configurable threshold K_min, the switch marks the ECN field in the IP header of passing packets. The **Notification Point** (the receiving NIC) detects these ECN marks and generates a **Congestion Notification Packet (CNP)** back to the sender. The CNP is a 64-byte control packet injected at a rate of at most one per 50 microseconds per flow. The **Reaction Point** (the sending NIC) receives the CNP and reduces its transmission rate by a factor of alpha (default 0.5), then enters a recovery phase where it gradually increases the rate using a timer-based probing mechanism.

The critical tuning parameters are K_min, K_max (the queue threshold at which marking becomes probabilistic), and the P(f) marking probability function. For AI training fabrics, NVIDIA recommends K_min = 20KB (approximately 1.5 jumbo frames) and K_max = 200KB. This ensures that the switch detects congestion before the buffer overflows, but avoids falsely marking transient micro-bursts. The **alpha gain** parameter controls how aggressively the sender reduces its rate — a value of 0.5 halves the rate on each CNP, while 0.25 provides smoother convergence. At 800G, alpha of 0.5 is too aggressive and causes oscillation; the optimal alpha for 800G fabrics is 0.125, which requires approximately 4 RTTs to converge to the fair-share rate.

Recent advances include **High-Precision DCQCN (HP-DCQCN)**, which replaces the timer-based recovery phase with a hardware **Rate Meter** that continuously measures the actual sending rate and compares it against the target rate derived from ECN feedback. This eliminates the "sawtooth" pattern of standard DCQCN and maintains link utilization above 95% even under heavy congestion.

Before any RDMA transfer can occur, the sender must register the source memory buffer with the NIC, creating a **Memory Region (MR)** that maps the virtual address to physical pages and pins them to prevent page-out. The registration process involves a synchronous call to the kernel's memory management subsystem: the kernel walks the process page table, translates the virtual address range to physical page frames, locks those pages in memory, and creates a **Physical Region Entry (PRE)** table that the NIC's DMA engine can consume. This entire sequence takes 5-20 microseconds per registration — a delay that is negligible for bulk transfers but catastrophic for latency-sensitive operations like small gradient updates.

The standard mitigation is **MR Caching** — pre-registering a pool of buffers at application initialization and reusing them across multiple RDMA operations. The NCCL library pre-registers 32 MB of buffer space per GPU for each peer GPU at startup, creating a registration table with 8 entries per peer (4 for send, 4 for receive). With 8 GPUs per node, each having 7 peers, this creates 8 x 7 x 8 = 448 registered memory regions per node. The registration overhead at startup is 448 x 15 microseconds = 6.72 milliseconds, which is absorbed into the init time. During training, RDMA operations use these pre-registered buffers directly, achieving zero-copy transfers without any kernel involvement.

The challenge arises in **Dynamic Memory Registration** — when the application allocates new buffers during training (e.g., for activation checkpointing buffers that vary in size between model layers). If the new buffer is not in the pre-registered pool, the RDMA operation incurs an **On-Demand Registration** penalty of 15 microseconds, stalling the All-Reduce pipeline. At 800G line rate, 15 microseconds corresponds to 1.5 MB of lost bandwidth opportunity. The solution is **Registration Caching with Prefetch** — the CUDA driver monitors memory allocation patterns and proactively registers newly allocated GPU memory before it is used in RDMA operations. NVIDIA's GPUDirect RDMA driver implements this through a **Registration Lookaside Buffer (RLB)** that caches the last 1,024 registrations per process.

At the fabric level, **ODP (On-Demand Paging)** in ConnectX-7 and later NICs eliminates explicit registration entirely by allowing the NIC to pin and translate pages on-the-fly as DMA requests arrive. ODP uses the NIC's internal MMU to walk the process page table directly via a hardware path called **Peer-to-Peer Page Walking (PPW)** . This reduces the registration latency from 15 microseconds to under 200 nanoseconds — a 75x improvement — and makes dynamic buffer allocation transparent to RDMA. However, ODP's page-walking throughput is limited to 10 million translations per second per NIC, which becomes a bottleneck for highly concurrent workloads with 100,000+ small RDMA operations per second. In practice, NCCL uses pre-registered MRs for the hot path of All-Reduce and ODP as a fallback for cold-start registrations.