• RoCEv2's operational friction at scale comes from four sources: PFC as a system dependency (pause storms, misconfig propagation), DCQCN's 2-RTT feedback latency, low-entropy ECMP requiring explicit spraying configuration, and out-of-order delivery limitations.

• UEC is a four-component specification (UET transport + retransmit + congestion control + multipath) ratified in Q4 2024. It targets PFC elimination, native packet spraying, and ACK-based congestion control with 1-RTT feedback latency.

• The UET packet format replaces BTH with a 20-byte header using Message ID + Packet Offset instead of PSN. This enables out-of-order reassembly natively. Destination UDP port is 4792.

• UEC reliability uses SACK-based retransmit at the NIC firmware layer. Individual packet loss costs approximately 1 RTT of added latency (microseconds) vs RoCEv2's QP-error recovery path (milliseconds).

• UEC congestion control marks the same ECN CE bits as DCQCN but reads them from ACK packets rather than CNPs. The feedback loop is 1 RTT instead of 2 RTT -- relevant at 400G and above.

• Switch requirements: ECN marking is sufficient for baseline UEC. NPM path feedback and path-ID-aware forwarding improve multipath performance but require newer firmware or ASICs.

• Deployment reality (March 2026): AMD Pensando Salina is production-available UEC silicon. Intel Gaudi 3 has UEC-capable ports. NVIDIA ConnectX-7/BF3 (used in all current DGX nodes) do not support UEC. A DGX cluster cannot run UEC without NIC replacement.

• Operationally: if you are running a DGX cluster today, you run RoCEv2. UEC is the evaluation framework for your next NIC/switch purchase cycle. The right question to ask vendors in 2026 is "UEC 1.0 compliant?" not "does this support RoCEv2?"

Continue to Chapter 21 -- Congestion Control Deep Dive ->