UEC v1.1 Explained: Scale-Up, INC, CSIG, and PCM

UEC v1.1 Explained: Scale-Up, INC, CSIG, and PCM

The Ultra Ethernet Consortium (UEC) released UE Specification v1.1 on October 12, 2026, introducing major enhancements to Ethernet-based networking for artificial intelligence and high-performance computing (HPC). The update extends the protocol stack’s capabilities beyond conventional scale-out cluster networking, adding dedicated support for scale-up communication, in-network collective operations, finer-grained congestion telemetry, and programmable congestion management.

The previous v1.0.3 release, published in July 2026, provided an established foundation for AI and HPC networking. Version 1.1 builds on that foundation with a more comprehensive set of specifications for local accelerator communication, packet-overhead reduction, network-assisted computation, and application compatibility.

The significance of this release is architectural. Rather than treating communication within a tightly coupled accelerator domain and communication across a large cluster as entirely separate networking problems, UEC is extending a common Ethernet-based framework to address both.

The new specification introduces six major capabilities:

• Unified Local: A profile optimized for low-latency scale-up communication and small messages.
• Unified Forwarding Header (UFH): An optional header optimization that reduces packet overhead.
• In-Network Collectives (INC): Switch-assisted computation for operations such as AllReduce.
• Congestion Signaling (CSIG): More detailed congestion information than conventional ECN marking alone.
• Programmable Congestion Management (PCM): Standardized interfaces for customizable congestion-control and load-balancing algorithms.
• UET Verbs mapping: A compatibility path for applications using established RDMA Verbs semantics.

Together, these changes move Ultra Ethernet toward a more complete networking architecture for distributed AI training, inference, and HPC workloads. They also establish new implementation choices for NIC and switch vendors without requiring every deployment to enable every optional feature.

The authoritative reference is the Ultra Ethernet Consortium’s Specification v1.1 announcement and specification archive.

🌐 1. Why UEC v1.1 Matters: From Scale-Out to Scale-Up

#

Scale-out and scale-up solve different problems

#

AI infrastructure depends on two related but distinct communication domains.

Scale-out networking connects servers across a cluster. It must support high aggregate bandwidth, efficient multipath routing, congestion management, and reliable communication among large numbers of endpoints.

Scale-up networking connects tightly coupled accelerators within a server or other local accelerator domain. Its priorities include low latency, efficient small-message transport, and rapid exchanges among GPUs participating in the same computation.

These communication patterns create different engineering constraints.

A large distributed training job may transfer substantial amounts of tensor data between servers, making throughput and congestion management essential. Inside a tightly coupled accelerator domain, however, frequent memory reads, writes, and atomic operations can generate large numbers of short transactions.

When packet headers and transport bookkeeping consume a significant portion of a small message, even a high-speed link can be used inefficiently.

UEC v1.1 addresses both environments by adding a dedicated Unified Local profile and complementary optimizations for packet efficiency, network-assisted computation, and congestion management.

What changed between v1.0.3 and v1.1?

#

UEC released v1.0.3 on July 16, 2026, and v1.1 on October 12, 2026. The newer specification expands the protocol architecture rather than simply refining existing scale-out features.

The key distinction is between introducing an architectural concept and specifying the mechanisms needed to implement it consistently.

Version 1.1 defines additional profiles, packet formats, control interfaces, and software integration points so that vendors can implement the new capabilities according to the specification.

One protocol framework, multiple networking profiles

#

UEC does not require every product to support every capability.

The AI Base, AI Full, and HPC profiles address different combinations of transport services and application requirements. Unified Local adds a profile specifically targeting short-range accelerator communication.

Optional enhancements such as UFH, INC, CSIG, and PCM provide further implementation choices.

This allows silicon vendors and system builders to adopt the features that best match their deployment requirements instead of implementing the entire feature set in every NIC and switch.

For new designs, the important question is therefore not simply whether a product supports Ultra Ethernet. It is which specification revision, profiles, and optional capabilities the product actually implements.

For a broader architectural comparison, see KAD’s analysis of Ethernet-based scale-up networking and the challenge of replacing proprietary accelerator interconnects.

🧩 2. Unified Local: A Dedicated Profile for Scale-Up Networking

#

Unified Local is one of the most important additions to UEC v1.1.

The profile targets communication between closely coupled endpoints, where small messages and frequent synchronization can make conventional networking overhead disproportionately expensive.

Why small packets need a different approach

#

Traditional Ethernet communication commonly includes Ethernet, IP, transport, and protocol-specific headers. These layers provide addressing, routing, reliability, and application semantics, but they also consume bandwidth and require processing.

For large data transfers, the header overhead is relatively small compared with the payload.

For a short read, write, or atomic operation, the payload may be only a few dozen bytes. A large collection of headers can therefore consume a substantial share of the transmitted frame.

This creates two costs.

First, header bytes consume physical link capacity that could otherwise carry application data.

Second, processing and maintaining transport state for large numbers of short requests can increase latency and constrain implementation scalability.

The Unified Local profile addresses these problems with a simplified transport model and optimized packet representation for local scale-up environments.

Reliable ordered delivery for local operations

#

The local transport design includes reliable ordered communication and support for operations such as reads, writes, and atomics.

For implementations using the Reliable Ordered Delivery for Local Networks (RODL) mechanism described in the supplied technical material, the goal is to handle small local transactions without paying the full operational cost associated with more general long-distance transport patterns.

Important design objectives include:

• Reducing per-packet overhead for small requests.
• Lowering the cost of maintaining transport state.
• Reducing acknowledgment overhead where supported by the transport design.
• Supporting reliable and ordered delivery semantics.
• Providing efficient handling of local memory operations.

The complete specification defines the normative behavior and required fields. Implementers should not assume that every possible state-table reduction or header optimization described in secondary explanations is a mandatory mechanism unless it is explicitly specified.

Direct memory addressing and compact request metadata

#

The Unified Local design also introduces more compact ways of representing request information and addressing semantics.

For scale-up workloads, direct memory addressing and reduced transport overhead can help limit the cost of frequent operations between accelerators.

The purpose is not to eliminate addressing or reliability requirements. It is to express the required information more efficiently for the target operating environment.

These optimizations are particularly relevant when a workload issues many small requests rather than transferring large, contiguous blocks of data.

Profile-specific requirements

#

Unified Local is a defined profile rather than a universal replacement for all UET communication modes.

An implementation that declares support for the profile must meet its applicable mandatory requirements. Other devices can continue to implement AI Base, AI Full, or HPC without necessarily implementing every Unified Local feature.

This profile-based approach lets UEC address short-range accelerator communication while preserving implementation flexibility across different networking products.

📦 3. Unified Forwarding Header: Reducing Packet Overhead

#

The Unified Forwarding Header (UFH) reduces the overhead associated with traditional network packet headers.

In conventional Ethernet over IP, packets carry separate layer-two and layer-three addressing information alongside transport metadata. This structure is flexible, but it can be inefficient when a small AI message carries relatively little application data.

UFH provides an alternative packet representation designed for Ultra Ethernet traffic.

UFH_32 and UFH_16

#

UEC v1.1 defines UFH_32 and UFH_16 variants.

According to the consortium, UFH can save approximately 20 bytes compared with a traditional IP packet, depending on the relevant packet format and comparison baseline.

The approach uses the existing Ethernet framing position to carry the unified forwarding information rather than requiring a separate conventional IP header in the same way as ordinary Ethernet-over-IP traffic.

The result is lower overhead for supported traffic while retaining the routing behavior needed by the Ultra Ethernet architecture.

UFH is optional. It does not mean that every Ultra Ethernet packet must use the compressed representation.

Coexisting with conventional Ethernet

#

An important design objective is interoperability.

UFH is designed to permit supported Ultra Ethernet traffic and conventional Ethernet traffic to coexist on the same link. This reduces the need to dedicate an entirely separate physical network solely because one traffic class uses a more compact forwarding representation.

However, coexistence does not mean that every legacy device understands UFH. Devices and interfaces must support the relevant framing and forwarding behavior for the feature to operate correctly.

Deployments must therefore validate the actual interoperability path, including which devices recognize the UFH format and how conventional traffic is handled.

Reducing inter-packet idle time

#

UEC v1.1 also describes an optional idle-reduction mechanism that reduces the number of idle bytes inserted between packets.

The consortium reports that this mechanism can save up to 11 bytes per packet under the applicable conditions.

Combined with UFH, this can improve line efficiency for high packet-rate workloads, where each individual packet carries a relatively small payload.

The practical gain depends on the frame sizes, link behavior, packet rate, and the portion of traffic eligible for the optimization.

These features are particularly valuable in scale-up environments, where frequent short requests make per-packet overhead an important performance consideration.

🔄 4. In-Network Collectives: Offloading AllReduce to Switches

#

In-Network Collectives (INC) allow supported collective operations to be performed within the network rather than requiring all intermediate data to travel to endpoint processors for reduction.

This is especially relevant to distributed AI training.

Why AllReduce is expensive

#

Distributed training frequently uses AllReduce to combine gradients or other intermediate values across participating workers.

A conventional implementation may first transfer data for reduction and then distribute the reduced result back to the participating endpoints.

This process creates substantial network traffic, particularly when the same collective operation is repeated across a large accelerator cluster.

Because training workers often synchronize at collective boundaries, communication inefficiency can also leave accelerators idle while they wait for the operation to complete.

Switch-assisted reduction

#

INC moves supported reduction operations into the network.

Instead of requiring all input values to be processed at an endpoint and then redistributed, participating switches can perform the configured reduction as data passes through the network.

UEC’s published example illustrates the possible bandwidth benefit: to produce a 1GB reduced result using the conventional two-phase transfer pattern, each endpoint may need to send 2GB of data across the relevant operations. Under the described INC model, the endpoint can send 1GB of input data for reduction, potentially reducing communication volume by half and enabling up to a 2× improvement in the communication phase.

These figures describe the communication model, not a guarantee that every complete training job will run twice as fast.

Actual results depend on the collective algorithm, topology, data layout, switch capabilities, and overhead associated with coordination and result distribution.

INC management and software integration

#

UEC v1.1 provides a more comprehensive framework for managing in-network collectives.

The design includes an INC Manager (IM) for discovering capabilities, managing communication domains, coordinating supported operations, and handling errors.

It also addresses packet formats, software integration, and recovery behavior.

The specification distinguishes mandatory and optional switch capabilities, allowing vendors to implement supported subsets rather than requiring every switch to perform every collective operation.

This is important because in-network reduction requires more than arithmetic hardware. Switches must also maintain appropriate state, process control information, handle failures, and integrate with the endpoint software responsible for initiating collectives.

When INC is most useful

#

INC is most relevant when an AI or HPC workload repeatedly performs supported collective operations and network communication contributes materially to job completion time.

For example, a large distributed training job can spend a substantial portion of each iteration exchanging gradients or synchronizing intermediate values.

Reducing the bytes transported and the distance between communication and computation may improve cluster utilization.

However, not every collective operation can be offloaded in every implementation. Developers must verify supported reduction types, message sizes, group semantics, and fallback behavior before relying on INC in production.

📡 5. CSIG: More Detailed Congestion Telemetry Than ECN

#

Congestion is a major source of performance variability in AI networks.

When many accelerators transmit simultaneously, queues can grow at bottleneck switches, increasing packet latency and reducing the efficiency of distributed computation.

Conventional Explicit Congestion Notification (ECN) can mark packets to indicate that congestion has occurred, but the marking alone does not communicate a complete description of the congestion experienced along the path.

UEC v1.1 introduces Congestion Signaling (CSIG) to provide more detailed information.

How CSIG works

#

CSIG uses compact metadata carried with packets.

The specification describes 4-byte and 8-byte formats. As a packet traverses supported switches, the network can update the signal with information about congestion encountered along the path.

Depending on the selected format and measurement, this can represent metrics such as the maximum queueing delay or the minimum available bandwidth observed.

The receiver can return this information to the sender in acknowledgment traffic, allowing the endpoint to make congestion-control decisions using more detailed path information.

The key distinction is that CSIG provides a mechanism for conveying path measurements rather than relying solely on a conventional binary indication that congestion has occurred.

Why path-level information matters

#

Suppose a packet crosses several switches, but only one switch experiences a substantial queue.

A sender that receives only a basic congestion mark may know that congestion occurred without having enough information to distinguish a minor bottleneck from a severe one.

CSIG can provide a more informative signal based on the configured metric and the information collected along the path.

The sender can then use this information as input to rate control or load balancing.

This does not mean CSIG automatically chooses the best path or eliminates congestion. It supplies additional telemetry that supported congestion-control algorithms can consume.

Integration with existing congestion algorithms

#

UEC v1.1 specifies how its baseline congestion-control algorithms can use CSIG information.

Network Signal-based Congestion Control (NSCC) can use queueing-latency measurements to improve congestion response and bandwidth-sharing behavior.

Receiver-Credit Congestion Control (RCCC) can use network delay or queue-depth measurements as part of its congestion-management process.

The value of CSIG therefore extends beyond telemetry collection. It provides a more detailed input signal for algorithms responsible for regulating traffic through the network.

Its effectiveness still depends on accurate measurements, correct protocol implementation, and the endpoint algorithm’s ability to respond appropriately.

🧮 6. Programmable Congestion Management: From Fixed Algorithms to Adaptable Policies

#

AI workloads continue to evolve in message size, traffic intensity, communication patterns, and synchronization behavior.

A congestion-control algorithm that works well for one workload may not be optimal for another.

Traditional implementations commonly embed their congestion-control behavior in the NIC’s hardware or firmware, making major changes dependent on vendor-specific implementation choices and update mechanisms.

UEC v1.1 introduces Programmable Congestion Management (PCM) to provide a more flexible framework.

A standardized programming model

#

PCM defines a common set of APIs and a programming model through which NIC vendors can expose supported congestion-control and load-balancing customization.

The intent is to allow new algorithms to be developed and adapted to particular workloads without requiring every change to be implemented as a new hardware design.

The specification retains NSCC and RCCC as baseline algorithms while introducing a framework for additional programmable policies.

The practical execution model depends on the supported implementation. PCM-based algorithms may be developed, compiled, and deployed using the interfaces provided by compatible endpoint hardware and software.

PCM does not eliminate the need for hardware support. A device must implement the necessary PCM facilities, and custom algorithms must operate within the capabilities and safety constraints of that platform.

Combining PCM with CSIG

#

PCM and CSIG are complementary.

CSIG supplies more detailed information about congestion along the path. PCM provides a framework for developing and deploying algorithms that can use such information to adjust congestion control or load balancing.

For example, a policy could use queueing-delay measurements to detect an overloaded path and then adjust the sending rate or select an alternative route where the available controls permit it.

Another policy might be optimized for a workload dominated by collective communication, where synchronization and tail latency are particularly important.

These examples illustrate the potential of the architecture rather than guaranteed behavior for every PCM implementation.

The objective is to reduce the cost of adapting congestion management as AI workloads change, while preserving a standardized software interface across compatible NICs.

🧑‍💻 7. UET Verbs Mapping: Improving RDMA Application Compatibility

#

A networking specification must address software migration as well as wire-level performance.

Many existing RDMA applications use established Verbs interfaces, often through libraries such as libibverbs. UEC’s software stack also provides libfabric-based APIs designed for Ultra Ethernet Transport (UET).

Without an appropriate compatibility layer, moving applications between networking models could require significant changes to application logic and memory-management behavior.

UEC v1.1 introduces a UET Verbs mapping specification to bridge this gap.

Preserving application semantics

#

The mapping targets the AI Base profile and defines how supported UET operations correspond to RDMA Verbs concepts.

Its goal is to preserve important application-level semantics while using the underlying UET transport.

This can reduce migration effort for existing RDMA software, although the extent of the required changes depends on the application’s use of specialized operations and the capabilities supported by the target implementation.

It should not be assumed that every legacy libibverbs application can run unchanged merely because a Verbs mapping exists.

Applications need compatible implementations of the relevant interfaces, operations, error handling, and resource-management behavior.

More flexible memory mapping

#

One addition enables more flexible management of memory-region resources across logical services within an application.

Memory registration and mapping are important parts of RDMA programming because they determine which memory regions are available for remote access and under what permissions.

Reducing restrictions on how those resources are represented or reused can simplify software integration in supported implementations.

The precise semantics and requirements are defined by the specification and must be followed by compatible implementations.

Synchronization groups

#

The Verbs mapping also introduces synchronization groups to support completion-order semantics associated with existing responder behavior.

These mechanisms are important for applications that depend on relationships between operations rather than treating every request as an independent event.

Preserving those semantics helps reduce the changes required when porting existing applications to a different transport.

For AI infrastructure, this compatibility can be significant because networking libraries are deeply integrated into training frameworks, collective communication implementations, and distributed runtime systems.

🔗 8. Compatibility Between UEC v1.0.3 and v1.1

#

UEC v1.1 extends the existing specification rather than replacing the entire protocol architecture.

The original AI Base, AI Full, and HPC profiles remain part of the framework, while Unified Local introduces a dedicated profile for scale-up communication.

The new specification also defines additional features that implementations can support according to their hardware and software capabilities.

Backward compatibility and feature negotiation

#

Compatibility must be evaluated at the profile and feature level.

A device implementing v1.1 is not automatically guaranteed to use every new feature with a device implementing v1.0.3. Both endpoints and relevant switches must support the selected profile and extensions.

Similarly, an older device should not be expected to implement Unified Local, UFH, INC, CSIG, or PCM merely because it supports an earlier UEC revision.

The correct approach is to determine the common feature set supported by the communicating devices and apply the relevant negotiation rules defined by the specification.

Do not assume that an older endpoint can simply ignore every new packet field or extension. Interoperability depends on the wire format, profile, and feature-negotiation behavior of the specific implementation.

Optional capabilities and implementation requirements

#

The new features do not all have the same implementation status.

This layered model provides vendors with flexibility, but it also makes precise capability discovery essential.

For hardware procurement and interoperability testing, request explicit details on the UEC specification revision, supported profiles, optional features, firmware requirements, and any vendor-specific limitations.

🏗️ 9. Practical Implications for AI Networking Deployments

#

UEC v1.1 creates opportunities for different parts of the AI infrastructure ecosystem, but the benefits will depend on implementation quality and workload characteristics.

For NIC and switch vendors

#

Chip vendors can select the features appropriate to their target products.

A NIC focused on scale-up networking may prioritize Unified Local and small-packet efficiency. A switch designed for distributed training may prioritize INC, CSIG processing, or the forwarding capabilities needed for compatible collective operations.

PCM offers a route toward more adaptable congestion-control behavior, while the UET Verbs mapping can reduce friction when integrating with established application software.

This allows implementation differences without requiring every product to support the entire set of new capabilities.

For AI cluster operators

#

Operators can evaluate whether the new features address bottlenecks in their current deployments.

Unified Local targets the overhead and communication patterns of tightly coupled accelerators. UFH and idle reduction improve the efficiency of supported small-packet traffic. INC can reduce communication volume for eligible collective operations, while CSIG and PCM provide tools for more informed congestion management.

However, these capabilities do not automatically guarantee better end-to-end performance.

A cluster still requires appropriate topology design, traffic engineering, capacity planning, performance monitoring, and workload-aware benchmarking.

For a practical overview of the networking requirements of distributed accelerator systems, see KAD’s Introduction to AI Cluster Networks.

For developers and software framework maintainers

#

The Verbs mapping and software API work are important because hardware innovation alone cannot create a usable ecosystem.

Developers need clear interfaces, predictable semantics, and compatible implementations across NICs and switches.

Framework maintainers must also determine which new capabilities to expose to applications, when to use them, and how to fall back when a particular device does not support them.

The result should be an implementation model in which applications can access improved networking behavior without embedding assumptions about a single hardware vendor.

For standards development

#

UEC has stated that it is collaborating with the Open Compute Project and IEEE on aspects of its technology.

The consortium’s published roadmap describes work to bring scale-up technologies into subsequent OCP Ethernet specifications and to advance CSIG standardization through the IEEE.

These activities are relevant because broad interoperability depends on more than publication of a specification. It also requires compatible implementations, test methods, operational tooling, and evidence from multi-vendor deployments.

🧪 10. When Is UEC v1.0.3 Still Sufficient?

#

A deployment centered on established scale-out AI training or HPC traffic may not require every capability introduced in v1.1.

If its existing NICs and switches already implement the required transport profiles and provide adequate congestion management, an upgrade may offer limited immediate benefit.

The case for v1.1 becomes stronger when a new architecture needs one or more of the following:

• Dedicated scale-up transport for local accelerator communication.
• Lower per-packet overhead for small messages.
• Switch-assisted collective operations.
• More detailed congestion telemetry.
• Programmable congestion-control policies.
• Improved compatibility with applications using RDMA Verbs semantics.

For new projects, the appropriate choice depends on product availability, interoperability evidence, implementation maturity, and the target workload.

UEC lists v1.1 as the latest published specification. That makes it the appropriate starting point for evaluating new capabilities, but it does not mean every currently available product supports all v1.1 features.

Before committing to a design, verify vendor implementation claims and benchmark the supported features with the intended topology and software stack.

🌌 Conclusion: UEC v1.1 Expands Ethernet for AI Scale-Up and Scale-Out

#

UEC v1.1 represents a significant expansion of the Ultra Ethernet architecture for AI and HPC networking.

The Unified Local profile addresses tightly coupled accelerator communication, while UFH and idle reduction target the overhead associated with small packets. INC moves supported collective computations into the network, CSIG supplies more detailed congestion information, PCM provides a framework for customizable congestion management, and UET Verbs mapping helps preserve established application semantics.

Together, these capabilities extend the scope of Ultra Ethernet beyond conventional cross-node cluster networking toward a more unified framework for scale-up and scale-out communication.

The specification also preserves implementation flexibility. Vendors can implement the capabilities relevant to their products, provided they meet the requirements of the profiles and features they claim to support.

The remaining challenge is practical adoption. The value of UEC v1.1 will depend on NIC and switch implementations, interoperable software stacks, validated failure-recovery behavior, and measurable improvements in real AI workloads.

The broader direction is clear: Ethernet is evolving to address not only the bandwidth demands of large AI clusters, but also the short-message efficiency, collective communication, and congestion-control requirements of tightly coupled accelerators.

UEC v1.1 provides a more complete specification framework for that evolution. Whether it delivers consistent gains at scale will depend on how effectively the industry turns those protocol capabilities into interoperable hardware and production-ready systems.