Ultra Ethernet 1.1 vs RoCEv2: What Changes in the AI Fabric Transport and How to Test It

The bottom line

On October 12, 2026, the Ultra Ethernet Consortium published specification 1.1. Sixteen months after version 1.0 (June 11, 2025), the standard moved beyond scale-out into the rack and made congestion control programmable. For fabrics running on RoCEv2, this is not a replacement but a second transport operating alongside the first. The fabric will have to be tested for both.

What version 1.1 adds

• Unified Local profile for scale-up. A transport for short links between accelerators: one tier of switches or none at all. Designed for a lossless fabric with PFC or credit-based flow control (CBFC). The request carries the acknowledgment for the reverse direction, so fewer standalone ACKs are needed.
• Unified Forwarding Header (UFH). A replacement for the IP header: addressing moves into a 12-byte MAC header, saving up to 20 bytes per packet. For comparison, a baseline UET 1.0 packet carries 104 bytes of headers.
• Idle reduction. The inter-packet gap shrinks from an average of 84 bytes to a constant 80. The effect is noticeable on the small messages typical of scale-up.
• CSIG. A 4- or 8-byte tag updated by every switch along the path: the worst queueing delay or the minimum available bandwidth. The receiver returns it in the ACK, and the sender sees the real bottleneck instead of a single ECN bit.
• PCM. Congestion control and load balancing algorithms are loaded onto the NIC as programs. The baseline NSCC and RCCC remain and can use CSIG as input. The algorithm can change over the entire service life of the card without changing the silicon.
• In-Network Collectives. Reduction is performed on the switch: an endpoint sends 1 GB instead of 2 GB for an allreduce with a 1 GB result.

How it compares with RoCEv2

What they share: both are RDMA over Ethernet, and both rely on ECN and a lossless fabric with PFC. Unified Local is explicitly designed for PFC/CBFC, so PFC remains part of the fabric.

What changes: - Loss. RoCEv2 uses go-back-N: after a single loss, the tail of the flow is retransmitted. UET uses selective ACK: only the lost packets are resent. - Load balancing. RoCEv2 pins a flow to one path via the ECMP hash. UET sprays packets across all paths, and the receiving NIC restores the order. - Congestion control. RoCEv2 relies on DCQCN: the switch sets an ECN mark, the receiver sends a CNP, the sender slows down. The reaction is implemented in the NIC firmware, and the signal is a single bit. In UET: NSCC based on delay, trimmed packets and ECN; RCCC based on receiver credits; and, as of 1.1, CSIG and any algorithm via PCM. Instead of dropping, UET applies packet trimming: the switch cuts the packet down to 64 bytes from the typical 4 KB and forwards it through a priority queue.

None of this retires RoCEv2. On October 1, 2025, Keysight and Nokia demonstrated on AresONE 800GE and the 7220 IXR-H5 / 7250 IXR-10e switches that UET 1.0 and RoCEv2 with DCQCN run in the same fabric at the same time.

What this means for fabric testing

A test of "RFC 2544 + DCQCN with default settings" no longer covers the risk. The generator and the methodology must be able to: - emulate RoCEv2/DCQCN and UET in parallel on the same 400/800GE links — this is precisely the migration scenario; - exercise a set of CC algorithms: NSCC, RCCC, their combination, and custom PCM programs from the NIC vendor; - verify CSIG on the switches: whether the tag is updated at every hop and whether the worst value reaches the sender; - measure the metrics that matter in AI workloads: collective completion time, tail latency, the share of trimmed packets and retransmissions, PFC pause frequency, victim flows under incast; - for scale-up, decode UFH frames without IP and the reduced inter-packet gap. Not every analyzer supports this.

A migration path for RoCEv2 fabrics

1. Establish a baseline on RoCEv2/DCQCN: incast, PFC pauses, collective completion time.
2. Check the switches for packet trimming and CSIG support. Trimming exists on some current platforms; CBFC and LLR require new silicon.
3. Introduce UET on a pilot segment in mixed mode, leaving the PFC configuration unchanged, and repeat the same tests.
4. For scale-up, wait for Unified Local support in NICs: every 1.1 feature requires hardware support, and some of it will arrive via firmware.
5. Request a list of supported profiles from the vendor: UEC compliance is self-attestation against a checklist, with no independent certification.

What this means for the business

RoCEv2 remains the primary transport of AI clusters for at least the next procurement cycle. But new NICs and switches should be selected with UET 1.1 in mind: packet trimming, CSIG, PCM. Otherwise, in two years the fabric will have to be replaced outright rather than updated with firmware. The main risk is trusting a "UEC ready" label: there is no single certificate. The only protection is your own testing on a bench before the invoice is paid.

What to do

If a UET migration or a fabric validation is on your roadmap, contact TEST4NET: we will discuss your scenario and propose a test program.

Sources

• Network World: Ultra Ethernet 1.1 extends the specification to scale-up networks and adds programmable congestion control
• UEC: Specification page
• UEC blog: Accelerating AI with Open Standards
• SDxCentral: UEC releases version 1.1
• Arista: Demystifying Ultra Ethernet (white paper)
• DriveNets: RoCEv2 as a scale-out transport protocol
• Converge Digest: Nokia advances 800GE Ultra Ethernet