Ultra Ethernet 1.1: When AI Ethernet Grows Scale-Up Headers, Collectives, and Programmable Congestion

On 12 October 2026, the Ultra Ethernet Consortium (UEC) released Ultra Ethernet Specification v1.1, building on the v1.0 foundation published in June 2025. The consortium’s own announcement frames 1.1 as more than a bug-fix pass: it adds broad work for scale-up networking, transport enhancements for application compatibility and faster bulk transfer, In-Network Collectives (INC), Congestion Signaling (CSIG), and Programmable Congestion Management (PCM).

That release matters for AI cluster networking because Ethernet’s AI story is no longer only “RoCE done carefully at leaf-spine scale.” UEC is explicitly pushing the same family of technologies toward the short, latency-sensitive domain traditionally owned by proprietary accelerator links—while still targeting HPC and AI scale-out. This article stays close to the UEC v1.1 specification and press materials, attributes quantitative upside as UEC’s own claims, notes early endpoint demos (not shipping product promises), and situates 1.1 beside related open efforts such as OCP ESUN without collapsing them into one acronym soup.

Sidebar — Scale-up vs scale-out (non-expert version)
Scale-up links accelerators inside a tight domain—often a node, tray, or pod—so GPUs/XPUs can share memory-like traffic with very low latency (think NVLink-class problems, now also chased by open Ethernet variants).
Scale-out links many nodes across the hall so thousands of accelerators train or serve as one cluster (classic InfiniBand or RoCE Ethernet fabrics).
Ultra Ethernet began as a scale-out AI/HPC Ethernet effort; v1.1, according to the UEC, adds headers, profiles, and offloads aimed at scale-up as well—so one standards family can stretch across both jobs. They remain different designs; 1.1 tries to stop them from being different universes.

What v1.0 already changed—and why 1.1 arrived quickly

UEC positions Ultra Ethernet as an open, interoperable Ethernet architecture for AI and HPC, developed under the Joint Development Foundation with a large industry membership. The v1.0 specification (June 2025) established the transport and ecosystem direction; the consortium’s 1.1 announcement states that next-generation AI and HPC deployments have already adopted many v1.0 techniques. Version 1.1, dated 12 October 2026 on both the press release and the published PDF, is the first major revision to push aggressively into scale-up and in-network compute features.

The specification itself stresses that UE does not require changes to the network layer or Ethernet PHY/link layers: a compliant implementation may use Ethernet switches common at publication time, while optional features improve AI/HPC behavior. That philosophy—enhance Ethernet without forking the physical universe—is what makes UEC politically different from a greenfield interconnect, and what forces the hard engineering into headers, transport, congestion, and NIC programmability.

Scale-up networking support in 1.1

According to the UEC, the most substantial 1.1 theme is scale-up. The consortium highlights several concrete mechanisms:

Smaller packets, less idle overhead. UEC describes optimizations that reduce inter-packet gap idle bytes—saving as many as 11 bytes between packets in its explanation—aimed at making small messages more efficient. Scale-up traffic is full of small, latency-sensitive operations; wasting bytes on gaps hurts more than it does for elephant AllReduces.

Unified Forwarding Header (UFH). UEC introduces UFH as a network header that overlays a traditional Ethernet header, saving 20 bytes compared with a traditional IP packet in the consortium’s account, while maintaining IP routing functionality and wire interoperability with traditional Ethernet. The announcement points readers to UFH_32 details in the 1.1 specification.

“Unified Local” profile. Aimed at scale-up endpoints, this profile includes a simplified transport supporting write, read, and atomic operations with optimized headers, remaining wire-compatible with Ultra Ethernet Transport (UET) standards according to UEC.

Taken together, these are not “Ethernet but slower NVLink.” They are an attempt to make Ethernet packetization less tax-heavy inside a pod while preserving interoperability—exactly the compromise open coalitions can ratify and proprietary buses can ignore.

Collaboration notes in the UEC release matter operationally: UEC says it is working with OCP so that ESUN’s next specification can absorb v1.1 scale-up technologies (ESUN 1.0 already included many v1.0 ideas), with OCP SUE-T on expanded endpoint support, and with IEEE on further CSIG standardization. Buyers should track those alignments; a NIC that speaks UET but a switch silicon roadmap that only tracks ESUN—or the reverse—creates integration risk.

Transport enhancements: porting without a rewrite

A stated 1.1 goal is lowering migration cost. UEC created a Verbs mapping for UE (UET Verbs) supporting the AI Base profile and two transport-layer features: more flexible memory mapping across logical services, and synchronization groups that help replicate in-order responder completion delivery semantics familiar from existing Verbs. According to the UEC, the combination means existing applications can be ported to UE with fewer modifications.

For AI software stacks living on NCCL, MPI, and vendor collectives, that is the adoption hinge. Fabrics die in the porting swamp even when wire protocols look elegant. Verbs-shaped semantics are how UEC tries to keep PyTorch-era infrastructure from treating Ultra Ethernet as a research weekend.

In-Network Collectives: UEC’s bandwidth math

In-Network Collectives (INC) are the headline offload. According to the UEC, traditional all-reduce paths send data into the network twice—reduce, then broadcast—so producing a 1 GB reduced result can require each endpoint to send 2 GB. With INC, UEC states, an endpoint needs to send only 1 GB, yielding up to a 2× communication speedup in that illustrative accounting, because switches reduce data as it arrives and broadcast the result.

UEC also claims INC can cut latency for small collectives by using network broadcast instead of tree algorithms that pay log n hops of incremental latency. Those gains are UEC’s stated benefits for the architectural pattern; they assume INC-capable switches and a software path that actually invokes the offload. Operators should read them as upper-bound consortium claims pending silicon and NCCL integration—not as measured job-time improvements on a named cluster.

Congestion Signaling and programmable control

AI Ethernet lives or dies on congestion behavior. UEC’s 1.1 announcement details two complementary tools.

Congestion Signaling (CSIG). According to the UEC, CSIG is a compact 4- or 8-byte Layer-2 tag updated by switches with high-fidelity bottleneck information along a packet’s path. Endpoints learn both magnitude and location of congestion. UEC states that its congestion control algorithms NSCC and RCCC now consume CSIG: NSCC uses reported queueing latency at the bottleneck hop to improve fairness; RCCC uses delay or queue-depth measurements when granting sender credits. Beyond control loops, UEC positions CSIG as fine-grained telemetry for operators. The announcement references an ACM SIGCOMM paper for deeper CSIG design discussion.

Programmable Congestion Management (PCM). Looking past today’s built-in algorithms, UEC describes PCM as a unified language and API surface that NIC vendors expose so congestion control and load-balancing algorithms can be tailored to a workload and compiled to run on endpoints—portable across PCM-capable NICs. That is an AI Accelerators & Silicon point as much as a networking point: the NIC becomes a programmable congestion computer, not only a fixed RoCE offload.

AMD’s 11 October 2026 AI NIC blog (one day before the UEC 1.1 drop) underscores the industrial parallel: AMD describes a programmable AI NIC architecture used to develop and validate AI-ready Ethernet transports, notes AMD as a UEC founding member and author of Network-Signaled Congestion Control (NSCC) now in the UEC congestion management specification, and says AMD delivered one of the first AI NICs capable of supporting the UEC transport specification for ecosystem testing. Treat that as vendor context for why PCM/NSCC language is landing in silicon roadmaps—not as an independent benchmark of 1.1 features.

Endpoints in late 2026: demos, not a finished retail shelf

Specification velocity only helps if endpoints exist. As of late October 2026, public hardware stories remain early.

At Altera Innovators Day 2026 (San Jose, 28 October 2026), DYNANIC demonstrated Ultra Ethernet framing and datapath on a Silicom ThunderFjord card with an Altera Agilex 7 M-series FPGA—two 400GbE ports and PCIe Gen5 x16—using loopback to emulate two endpoints and show congestion impact in real time. DYNANIC’s own write-up is explicit about roadmap sequencing: Ultra Ethernet framing and datapath run on real hardware in the demo; retransmission, congestion response, and multipath—core Ultra Ethernet Transport elements—are next on its roadmap. That is a demo and evaluation path, not a claim of a complete, generally available UET NIC product. DYNANIC also states it is preparing interoperability testing with UEC and offers early evaluation of Ultra Ethernet IP for selected partners.

Reading UEC 1.1 next to that demo calendar is the honest adoption picture: the ink on scale-up headers and INC is dry; multipath-complete, congestion-complete commercial NICs are still converging. Hyperscalers with captive silicon will move first; FPGA and IP vendors bridge everyone else.

What 1.1 changes for architects

1. Dual-domain planning. If your 2027 accelerator pod expects open scale-up Ethernet (ESUN/UE paths) rather than only proprietary links, UFH and Unified Local profiles belong in the NIC/switch RFQ—not as footnotes.

2. Collectives offload as a switch feature. INC, according to the UEC, moves reduction into the network. That implies switch silicon and NOS features, NCCL/library hooks, and failure modes when a reducing switch misbehaves. Budget integration tests.

3. Telemetry that is useful under AI bursts. CSIG’s path-bottleneck tags are designed for low-entropy, synchronized AI flows that defeat classic ECMP assumptions. Ask vendors how CSIG appears in their streaming telemetry.

4. Programmability governance. PCM lets you compile custom congestion policy. That is power and risk: version the algorithms like firmware, test them under job mixes, and avoid per-cluster snowflakes that only one engineer understands.

5. Keep scale-across separate. UEC 1.1’s scale-up push is about pods and halls, not multi-campus coherent DCI. Distance-aware Ethernet fabrics and ZR optics are a different problem (see our multi-campus networking piece).

How 1.1 fits next to RoCE, ESUN, and proprietary scale-up

Ultra Ethernet does not erase RoCEv2 overnight. Many AI Ethernet fabrics will keep running today’s congestion recipes while NICs gain UET features. The migration story UEC is selling with Verbs mapping is gradual: preserve application semantics, introduce UFH and local profiles where pods need them, and enable INC where switch silicon supports reduction. According to the UEC, wire compatibility with traditional Ethernet remains a design constraint—so brownfield leaf-spine plants are not asked to renumber the universe on day one.

ESUN (Ethernet for Scale-Up Networking) under OCP is the complementary packaging of Ethernet-for-pods. UEC’s release states that ESUN 1.0 already incorporated many v1.0 technologies and that the groups are actively aligning v1.1 scale-up work into the next ESUN specification, alongside SUE-T endpoint work. Architects should therefore RFQ both UEC transport claims and ESUN switch/profile claims, and ask vendors to show a single interoperability matrix rather than two slide trees that never meet in a lab.

Proprietary scale-up (NVLink and peers) will continue to dominate the densest memory-semantic domains. UEC 1.1 is the open camp’s answer for operators who refuse a single-vendor pod—or who want Ethernet operational skill to cover more of the rack. It is not a claim that open Ethernet already matches every proprietary latency number. It is a claim that the header tax and collective offload gaps are now specified problems with specified tools.

Security, multitenancy, and operational caveats

AI clouds share fabrics. Programmable congestion (PCM), according to the UEC’s framing, lets operators compile policies to endpoints. That power needs tenancy fences: one tenant’s aggressive PCM program must not starve another’s training job. CSIG tags, being path telemetry, also expand the data an observer can infer about fabric hotspots. Security reviews should treat INC-capable switches and PCM-capable NICs as privileged infrastructure—firmware signing, algorithm allow-lists, and blast-radius tests belong in the same binder as BGP policy.

Failure modes multiply when collectives move into the network. If a reducing switch reboots mid-AllReduce, libraries must fall back cleanly to endpoint-only algorithms. UEC’s architectural claims assume the happy path; production NCCL (or successor) integration will be judged on the unhappy path. Demand explicit fallback demos in vendor POCs.

A practical 180-day checklist after Spec 1.1

1. Inventory which NICs in your roadmap claim UET AI Base / Verbs mapping, and which switches claim CSIG and INC.
2. Lab a two-rack replay of a production collective mix with and without INC (when silicon allows)—compare not only bandwidth but straggler tails.
3. Align UEC 1.1 features to the OCP ESUN revision your switch vendor actually commits to ship.
4. Treat FPGA Ultra Ethernet demos (such as DYNANIC’s Altera Innovators Day loopback demonstration) as learning tools for framing and congestion visualization—not as capacity planning inputs.
5. Write acceptance tests for PCM algorithm rollout: version pins, canary jobs, and automatic disable under pathological loss.
6. Separate campus/DCI projects from this workstream so ZR optics and UFH headers do not share the same risk register.

Those checklist items also force organizational clarity: networking, accelerator, and ML platform teams must share one Ultra Ethernet roadmap owner. Specs advance on consortium calendars; clusters advance on change-management calendars. Bridging them is the real 1.1 adoption work.

Outlook

Ultra Ethernet Specification v1.1 is the moment UEC publicly stretches AI Ethernet from “better scale-out RoCE successor” toward scale-up headers, in-network collectives, and programmable congestion—with quantitative upside presented as UEC’s own claims (byte savings, up to 2× communication speedup in the INC all-reduce illustration, CSIG-enhanced fairness). Early FPGA demos show framing paths lighting up; full transport feature completeness is still landing. For AI Hyperscale Infrastructure buyers, the actionable step is not to rewrite the cluster tomorrow—it is to demand 1.1-aware roadmaps in NIC, switch, and collectives software contracts written in Q4 2026 and H1 2027.

The strategic picture for AI Accelerators & Silicon teams is similar: endpoint silicon that cannot expose CSIG-aware control and a Verbs-shaped UE mapping will age out of hyperscale RFQs even if raw SerDes rates look fine. Conversely, switch ASICs that implement INC without robust fallback will fail job-level reliability reviews. Spec 1.1 raises the floor for what “AI Ethernet” means in a purchase order.

Open Ethernet for AI is no longer a single slogan. It is a versioned specification with a dated PDF, a congestion research trail, and a hardware demo circuit that just started humming. Treat v1.1 as the checklist against which vendors must now answer—and keep measuring job completion time, not only conformance logos.

Related reading

• InfiniBand vs Ethernet for AI Clusters
• Inside the AI Switch: Co-Packaged Optics Moves From Lab Demo to Liquid-Cooled Fabric
• How Distributed AI Superfactories Stretch the Network Between Campuses
• The 1 MW Rack: How 800V DC and Warm-Water Cooling Are Rewiring the AI Factory

Images: original illustrations generated for AndBeyond.Tech; no logos or real people depicted.