]> Cisco

fcalabri@cisco.com

Blue Fern Consulting

carlos@bluefern.consulting

Huawei

bill.wu@huawei.com

Huawei

giuseppe.fioccola@huawei.com

Operations and Management BMWG Internet-Draft This document defines benchmarking terminology, methodologies, and Key Performance Indicators (KPIs) for evaluating Ethernet-based AI training network fabrics. As large-scale distributed AI/ML training clusters grow to tens of thousands of accelerators (GPUs/XPUs), the backend network fabric becomes the critical bottleneck determining job completion time (JCT), training throughput, and accelerator utilization. This document establishes vendor-independent, reproducible test procedures for benchmarking fabric-level performance under realistic AI training workloads, covering RDMA/RoCEv2 transport, the Ultra Ethernet Transport (UET) protocol defined by the UEC Specification 1.0 , congestion management (PFC, ECN, DCQCN, CBFC), load balancing strategies (ECMP, DLB, packet spraying), collective communication patterns (AllReduce, AlltoAll, AllGather), and scale/soak testing. The methodology enables direct, reproducible comparison across different switch ASICs, vendor implementations, NIC transport stacks (RoCEv2 vs. UET), and fabric architectures (2-tier Clos, 3-tier Clos, rail-optimized). About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the BMWG Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The rapid growth of distributed AI/ML training workloads has fundamentally changed the performance requirements for data center network fabrics. Unlike traditional data center traffic characterized by diverse flow sizes and protocols, AI training workloads generate highly synchronized, bandwidth-intensive, east-west traffic patterns dominated by collective communication operations (AllReduce, AlltoAll, AllGather). These workloads impose unique demands: lossless transport (via RoCEv2 over RDMA), ultra-low tail latency, near-perfect load balancing across all fabric paths, and the ability to absorb coordinated micro-bursts from thousands of accelerators simultaneously. Existing BMWG methodologies, while foundational, do not adequately address the characteristics of AI training fabrics. defines benchmarking for general network interconnect devices but does not account for RDMA transport semantics, collective communication patterns, or the unique congestion dynamics of GPU-to-GPU traffic. and establish data center benchmarking terminology and methodology but predate the AI fabric paradigm and do not address RoCEv2-specific behaviors such as Priority Flow Control (PFC) interactions, DCQCN congestion control convergence , or the impact of load balancing strategies on Job Completion Time (JCT). Industry experience deploying RoCEv2 at scale further highlights the need for standardized benchmarking methodology. The EVPN benchmarking methodology provides a structural template for service-oriented benchmarking but is scoped to L2VPN services rather than RDMA fabrics. This document fills the gap by defining a comprehensive benchmarking methodology specifically designed for AI training network fabrics.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Scope and Applicability This document applies to Ethernet-based AI training backend network fabrics employing RoCEv2 and/or UEC Ultra Ethernet Transport (UET) protocols. The scope includes leaf-spine (2-tier Clos) and leaf-spine-superspine (3-tier Clos) topologies. InfiniBand fabrics are explicitly out of scope, though many KPIs defined herein may be adapted for IB benchmarking by future documents. The DUT is the network fabric itself (the collection of switches and interconnecting links), not individual accelerators or host NICs, though host-side configuration MUST be documented as it materially affects results. The DUT boundary for all measurements in this document is the NIC-to-NIC Ethernet fabric segment. Intra-node communication (NVLink, PCIe) and Individual GPU/accelerator performance are explicitly out of scope. Collective operation measurements (AllReduce, AllGather, AllToAll) are measured at the Ethernet fabric boundary; intra-node NVLink contributions MUST be reported separately when characterizing wide-EP or multi-node onfigurations. The methodology is designed for controlled laboratory environments per the BMWG charter; it is NOT intended for production network measurement.

Relationship to Existing BMWG Work Relationship to Existing BMWG Work

Document	Relationship
	Base terminology for network benchmarking; terms reused herein
	Base methodology; throughput/latency/loss tests adapted for RDMA
	LAN switching methodology; MAC learning concepts adapted for ARP/ND scale
	Data center terminology; buffer, congestion, and microburst terms extended
	Data center methodology; line-rate and buffer tests adapted for RoCEv2
	Back-to-back frame updates; burst absorption methodology referenced
	Complementary document benchmarking the inference serving stack. Treats the network as opaque SUT. This document benchmarks the fabric itself. The two documents MAY be used together but MUST NOT be combined in a single benchmarking report without explicit section demarcation.
	UET protocol specification; transport services, congestion control, and link-layer enhancements benchmarked in

Terminology and Definitions The following terms are defined for use in this document. Where a term overlaps with or , the definition herein takes precedence in the context of AI fabric benchmarking. Terminology and Definitions

Term	Definition
AI Fabric	The dedicated Ethernet backend network interconnecting accelerators (GPUs/XPUs) for distributed AI training, typically a non-blocking Clos topology running RoCEv2
JCT (Job Completion Time)	The wall-clock duration from start to completion of a training job, inclusive of all computation and communication phases
DUT Fabric	All leaf switches, spine switches, superspine switches (if applicable), and interconnecting links forming the AI training fabric
Roofline JCT	Theoretical minimum JCT assuming perfect (zero-contention) network behavior
JCT Ratio	Measured JCT / Roofline JCT; 1.0 = no network overhead; >1.0 = fabric inefficiency
BusBW (Bus Bandwidth)	Effective per-accelerator throughput; algo_factor is collective- and algorithm-specific (see ). Reports MUST state collective type, algorithm, and algo_factor
QP (Queue Pair)	RDMA communication endpoint (Send Queue + Receive Queue); multiple QPs per src-dst pair increase ECMP entropy
Incast Ratio	Ratio of senders to receivers (e.g., N:1 incast)
MMR (Max-Mean Ratio)	Flow count on most-loaded link / average flow count; quantifies ECMP imbalance (1.0 = perfect)
PFC Pause Event	Single PFC PAUSE frame transmitted on a priority class
ECN Marking Ratio	% of packets marked with Congestion Experienced (CE) over a measurement interval
Collective Operation	Coordinated cross-accelerator communication: AllReduce, AlltoAll, AllGather
DCQCN	Data Center Quantized Congestion Notification: ECN + PFC for end-to-end congestion control with RoCEv2
Packet Spray	Load balancing distributing individual packets across all ECMP paths; maximizes utilization but may cause reordering
DLB/Flowlet	Dynamic Load Balancing using flowlet detection; reroutes traffic at flow idle gaps
Zero-Impact Failover	Sub-microsecond path convergence upon link/switch failure with no measurable JCT impact
UET (Ultra Ethernet Transport)	Connectionless RDMA transport defined by UEC Spec 1.0; designed as next-generation replacement for RoCEv2
PDC (Packet Delivery Context)	Ephemeral, connectionless UET transport endpoint; analogous to but distinct from an RDMA QP
ROD	Reliable Ordered Delivery: UET service semantically equivalent to RoCEv2 RC mode
RUD	Reliable Unordered Delivery: UET service enabling native packet spray without receiver reorder buffer overhead
RUDI	Reliable Unordered Delivery for Idempotent operations; simplified retransmission for RDMA Writes
UUD	Unreliable Unordered Delivery: best-effort UET service for telemetry/speculative operations
LLR (Link Layer Retry)	Optional UEC per-hop error recovery (sub-microsecond) at the Ethernet link layer
Packet Trimming	Optional UEC enhancement; congested switches transmit packet header only instead of dropping the full packet
CBFC (Credit-Based Flow Control)	Optional UEC per-destination flow control; alternative to PFC that avoids head-of-line blocking
UEC Profile	Defined UET feature subset: AI Base, AI Full, or HPC
Entropy Value	Explicit per-packet UET field for ECMP path selection; improves multipath utilization vs. 5-tuple hashing

Test Topology and Architecture

Reference Fabric Topologies Three reference topologies are defined. All tests MUST specify which topology is used. Results obtained under different topologies are NOT directly comparable without normalization.

Topology A: 2-Tier Clos (Leaf-Spine)

Topology A: 2-Tier Clos (Leaf-Spine)

The DUT boundary encompasses all leaf and spine switches and their interconnecting links. Traffic generators or actual GPU hosts connect at the leaf layer.

Topology B: 3-Tier Clos (Leaf-Spine-Superspine) For clusters exceeding thousands of accelerators, a superspine layer is added. Each pod consists of a leaf-spine fabric; pods interconnect via superspine switches. This topology scales to 32,000+ accelerators at 800GbE with current-generation ASICs. The DUT boundary encompasses all three tiers.

Topology C: Rail-Optimized

Topology C: Rail-Optimized | |<-Rail-7->| ]]>

In rail-optimized topologies, each NIC on a multi-NIC host connects to a dedicated leaf switch ("rail"), co-optimizing network locality with the collective communication library (NCCL/RCCL). The DUT boundary and rail mapping MUST be fully documented.

Device Under Test (DUT) Identification DUT Identification Parameters

Parameter	Description	Example
Switch Vendor/Model	Vendor name, product family, model number	Vendor Family Model
Switch ASIC	Silicon vendor, ASIC family, revision	Silicon Vendor ASIC Family Rev
NOS Version	Network operating system name and version	NOS Name Version
Port Speed	Per-port line rate	400GbE, 800GbE
Buffer Architecture	Shared/dedicated, total buffer per ASIC/port	32MB shared + 16MB VOQ per port
Optics/Cables	Transceiver type, cable type and length	OSFP 400G-DR4, DAC 3m copper
NIC Vendor/Model	RDMA NIC vendor, model, firmware	NIC Vendor Model Speed
NIC Firmware	NIC firmware version	Firmware Version
Host Config	OS, CCL lib version, driver, BIOS settings	OS Version, CCL Version, OFED Version

Traffic Generator Requirements

Mandatory Functional Capabilities The traffic generator MUST support: RoCEv2 transport emulation (QP establishment, RDMA Write/Read, ECN processing, DCQCN rate control); configurable QP scaling (1-256 QPs per source-destination pair); programmable collective communication patterns (AllReduce, AlltoAll, AllGather with configurable message sizes); and nanosecond-precision timestamping.

Minimum Measurement Accuracy Requirements Minimum Measurement Accuracy Requirements

Parameter	Minimum Requirement
Timestamp accuracy	<= 100 nanoseconds
Frame rate accuracy	+/- 0.1% of specified rate
QP scaling range	1 to 256 QPs per src-dst pair
Message size range	1 KB to 8 GB
Flow counter resolution	Per-flow byte and packet counts
Loss measurement	0 ppm resolution
Burst generation	1-1000 frames at line rate

Acceptable Implementations The platform used MUST be identified in all test reports. (a) Hardware Traffic Generator — dedicated hardware capable of line-rate RDMA emulation meeting Section 3.3.2 accuracy requirements. Suitable for point-to-point RDMA tests (Sections 5 and 6). For collective tests (Section 9), the following limitations MUST be documented: whether synchronization barriers are reproduced, whether flow patterns are schedule-driven or gradient-driven, and whether straggler behavior is modeled. (b) Accelerator Cluster — cluster running an actual collective communication library with RDMA tooling. Preferred for Section 9 collective benchmarks. Host configuration (accelerator model, collective library name and version, PCIe topology, BIOS power management settings) MUST be documented. Any non-fabric overhead in timing measurements MUST be quantified and reported separately. When a hardware generator is used for collective benchmarks, results SHOULD be cross-validated against an accelerator cluster at one or more overlapping (message_size, N) configurations. Discrepancies exceeding 10% in BusBW or JCT Ratio MUST be investigated and reported.

KPI Framework and Metrics Taxonomy

• Target values in this section are NON-NORMATIVE illustrative reference points derived from current industry practice. They do NOT constitute benchmarking acceptance criteria. Per BMWG charter, defining acceptance criteria is explicitly out of scope. Implementers MAY use these values as contextual references; they MUST NOT be used as pass/fail thresholds.

Primary KPIs Primary KPIs

KPI	Unit	Definition	Reference Target (Non-Normative)
Job Completion Time (JCT)	seconds	Wall-clock time for benchmark iteration (compute + communication)	Minimize
JCT Ratio	dimensionless	Measured JCT / Roofline JCT	<= 1.05 (<= 1.15 acceptable)
Bus Bandwidth (BusBW)	Gbps/accelerator	Effective per-accelerator throughput during collective; algo_factor is collective- and algorithm-specific; see . Reports MUST state collective type, algorithm, and algo_factor	>= 90% of NIC line rate (intra-pod)
Aggregate Throughput	Tbps	Total fabric goodput during collective phase	>= 95% of bisection BW
Packet Drop Rate	ppm	Frames lost end-to-end not retransmitted	0 ppm (lossless)
Tail Latency (P99/P99.9)	us	99th/99.9th percentile one-way fabric latency	Minimize

Secondary KPIs Secondary KPIs

KPI	Unit	Definition
ECN Marking Ratio	%	Percentage of packets marked CE over measurement interval
PFC Pause Count	events/sec	Rate of PFC PAUSE frames per priority per port
PFC Pause Duration	us	Cumulative time a port is in PFC-paused state per interval
RDMA Retransmission Rate	retx/sec	NIC-level retransmissions due to timeouts or NAKs
ECMP Imbalance (MMR)	dimensionless	Max-Mean Ratio of flow counts across parallel uplinks
Jain Fairness Index (JFI)	0.0-1.0	Fairness of traffic distribution; 1.0 = perfect
Queue Depth (P95/Max)	bytes or cells	95th percentile and maximum egress queue occupancy per port
Congestion Control Convergence	us	Time from congestion onset to DCQCN rate stabilization
Out-of-Order Packet Rate	pkt/sec	Packets delivered out of sequence (relevant for packet spray)
CTS/ACK Delay	us	Delay for control messages (Clear-to-Send, ACKs)

Fabric Health Indicators Fabric Health Indicators

Indicator	Unit	Definition
Switch CPU Utilization	%	Average and peak CPU usage on DUT control plane during test
Switch Memory Utilization	%	Average and peak memory usage, including FIB/MAC table occupancy
FIB/Route Convergence Time	ms	Time to converge routing after topology change
Link Flap Count	events	Spurious link state changes during test period
CRC/FCS Error Rate	errors/sec	Physical layer errors indicating cable or optics issues
Power Consumption	Watts	Per-switch and per-port power draw under test load

Test Category 1: RDMA Transport Benchmarks These tests establish baseline fabric performance for RDMA traffic independent of collective communication patterns. They extend and methodology for RoCEv2 semantics.

Baseline Throughput Objective: Determine the maximum sustainable RDMA Write throughput through the DUT fabric at each tested message size. Procedure:

• Configure N host pairs, each establishing Q Queue Pairs per pair
• Initiate RDMA Write operations and measure aggregate goodput
• Test MUST run for at least 60 seconds at each rate
• Binary search per Section 26.1 SHOULD be used
• Message sizes: 64B, 256B, 1KB, 4KB, 64KB, 256KB, 1MB, 4MB
• QP counts: 1, 4, 16, 32 per src-dst pair
• Test both unidirectional and bidirectional traffic

Reporting: Report aggregate throughput (Tbps), per-port utilization (%), and throughput efficiency (measured/theoretical). Present as table indexed by message size x QP count, and as graph (message size on X-axis).

Latency Characterization Objective: Determine one-way and round-trip RDMA latency distribution at the throughput rate from . Procedure:

• Inject tagged frames at 60s into a 120s stream (per Section 26.2)
• Nanosecond-precision timestamping
• MUST report: min, mean, P50, P95, P99, P99.9, max
• Repeat at least 20 times; report averages
• Test under both zero-load (single QP) and loaded (full fabric utilization) conditions

Reporting: Tabulate latency statistics per message size. Provide histogram and CDF plot. Report latency increase factor (loaded/unloaded).

Back-to-Back Burst Absorption Objective: Characterize the DUT fabric's ability to absorb back-to-back RDMA bursts without loss, extending methodology for RoCEv2. Procedure:

• Transmit bursts at line rate with minimum inter-frame gap
• Increase burst length until first frame loss is detected
• Test incast ratios: 2:1, 4:1, 8:1, 16:1, 32:1
• Repeat at least 50 times per burst length

Reporting: Report burst absorption capacity (frames and bytes) for each message size and incast ratio. Plot burst capacity vs. incast ratio.

Test Category 1A: UEC Transport Protocol Benchmarks The Ultra Ethernet Consortium (UEC) Specification 1.0 defines UET, a connectionless RDMA transport designed to replace RoCEv2 for AI/HPC workloads. All UET tests use the libfabric API and run on UEC 1.0-compliant NICs. The UEC compliance profile (AI Base, AI Full, or HPC) used during testing MUST be documented.

UET Throughput by Transport Service Objective: Determine maximum sustainable throughput under each UET transport service (ROD, RUD, RUDI, UUD) and compare to RoCEv2 RC/UC on the same DUT fabric. Procedure: Use UEC 1.0-compliant NICs; establish PDCs; use libfabric fi_write. Apply binary search ( Section 26.1). Vary PDC counts: 1, 4, 16, 32. A parallel RoCEv2 test series MUST be executed. Both unidirectional and bidirectional configurations MUST be tested. Reporting template: UET Throughput by Transport Service

Metric	ROD	RUD	RUDI	UUD	RoCEv2 RC	RoCEv2 UC
Throughput @ 1MB (Gbps)	(meas)	(meas)	(meas)	(meas)	(meas)	(meas)
Throughput @ 4MB (Gbps)	(meas)	(meas)	(meas)	(meas)	(meas)	(meas)
Efficiency (% line rate)	(meas)	(meas)	(meas)	(meas)	(meas)	(meas)
PDC/QP Setup Time (us)	(meas)	(meas)	(meas)	(meas)	(meas)	(meas)
Max Sustained PDC/QP Count	(meas)	(meas)	(meas)	(meas)	(meas)	(meas)

UET Latency Characterization Objective: Measure latency distribution for UET transport services; quantify differential vs. RoCEv2, with particular attention to connectionless PDC establishment overhead. Procedure: Measure latency for: (a) steady-state PDC transfers; (b) first-packet latency (PDC + first data packet, measuring "data before handshake"); (c) zero-load baseline. Test ROD and RUD separately to isolate reordering-related latency. Reporting: Tabulate latency statistics per (transport_service, message_size, load_condition) tuple. Plot latency CDF for UET ROD, UET RUD, and RoCEv2 RC side-by-side.

Packet Spray Efficacy Under UET RUD Objective: Quantify the load balancing improvement achieved by UET's native per-packet spray with RUD, which eliminates the receiver reorder buffer constraint. Procedure: Test four configurations:

• UET RUD + packet spray
• UET ROD + packet spray
• RoCEv2 RC + packet spray
• RoCEv2 RC + standard ECMP (baseline)

Measure MMR, JFI, out-of-order delivery rate, retransmission rate, and effective goodput. Vary ECMP paths: 4, 8, 16, 32. Reporting template: Packet Spray Efficacy Under UET RUD

Load Balancing Config	MMR	JFI	OOO Rate	Retx Rate	Effective Goodput (%)
UET RUD + Packet Spray	(meas)	(meas)	(meas)	(meas)	(meas)
UET ROD + Packet Spray	(meas)	(meas)	(meas)	(meas)	(meas)
RoCEv2 RC + Packet Spray	(meas)	(meas)	(meas)	(meas)	(meas)
RoCEv2 RC + ECMP (baseline)	(meas)	(meas)	(meas)	(meas)	(meas)
UET RUD + DLB/Flowlet	(meas)	(meas)	(meas)	(meas)	(meas)

• UET RUD SHOULD achieve zero host-visible reordering despite per-packet spray because the transport layer natively tolerates unordered delivery.

UET Congestion Control Benchmarks Objective: Evaluate UET's dual-sided (sender + receiver) congestion control under N:1 incast conditions vs. RoCEv2 DCQCN. Procedure: Measure: (a) incast throughput at N = {2, 4, 8, 16, 32, 64}; (b) convergence time after doubling active senders (until all flows within 10% of fair share); (c) PFC avoidance with PFC disabled on the DUT; (d) receiver credit utilization. Reporting: Tabulate incast throughput, convergence time, peak queue depth, PFC event count, and packet drop rate for UET vs. DCQCN per incast ratio. Critical differentiator: report whether UET achieves zero application-visible loss without PFC.

Link Layer Enhancement Benchmarks Objective: Measure performance impact of optional link-layer enhancements: LLR, Packet Trimming (PT), and CBFC. Procedure:

• (a) LLR Retry Latency: inject controlled bit errors; measure LLR retry latency (expected sub-microsecond per hop) vs. transport-layer retransmission (~10-100us RTT). Run with 80% background load.
• (b) Packet Trimming Effectiveness: configure 2:1 oversubscription bottleneck; measure time from congestion onset to first retransmission request, bandwidth saved vs. full-packet drops.
• (c) CBFC vs. PFC: identical N:1 (N=32) incast scenarios; measure head-of-line blocking duration (CBFC is per-destination, PFC is per-priority), pause propagation hops, and throughput of non-congested flows.

Reporting: Before/after comparison table for each enhancement. Note which features are hardware-supported vs. software-emulated.

UET Collective Communication Performance Objective: Measure collective communication (AllReduce, AllToAll, AllGather) performance over UET and compare directly to RoCEv2, isolating the transport protocol contribution to collective efficiency. Procedure: Execute the collective benchmark suite from over UET RUD transport using a UEC-compliant collective library. The same accelerator count (N), message sizes, and fabric topology MUST be used for both UET and RoCEv2 runs to ensure a valid comparison. Run UET RUD + packet spray as the primary configuration and UET ROD + ECMP as the secondary baseline. For AllReduce, if UET group keying (transport-layer reduction support per UEC Spec 1.0) is active on the DUT NIC, this MUST be noted explicitly. When group keying is active, algo_factor MUST be recomputed from observed bytes transferred rather than applying the closed-form formula, since group keying alters the effective number of pass-through hops. Document the group keying state (active / inactive) as a required result field. For all collectives, the algo_factor used MUST be stated per message-size bucket. See for reference values. Reporting: Report the percentage improvement in BusBW and JCT attributable to UET native packet spray and congestion control. Reporting template: UET Collective Communication Performance

Collective	Msg Size	N Accels	UET RUD BusBW	UET ROD BusBW	RoCEv2 RC BusBW	Delta UET/RoCEv2
AllReduce	1GB	128	(meas)	(meas)	(meas)	(meas)
AllReduce	1GB	512	(meas)	(meas)	(meas)	(meas)
AlltoAll	1GB	128	(meas)	(meas)	(meas)	(meas)
AllGather	1GB	128	(meas)	(meas)	(meas)	(meas)

UET PDC Scalability and Connection Setup Rate Objective: Measure PDC establishment rate and maximum concurrent PDC count vs. RoCEv2 QP-based connections. Procedure: (a) PDC establishment rate: initiate PDC creation to M = {100, 1000, 10000, 100000} remote endpoints. (b) Data-before-handshake: measure first-byte latency for UET vs. RoCEv2 RDMA Write. (c) Maximum concurrent PDC count: scale until per-PDC throughput drops below 90% of single-PDC rate. The UEC specification targets up to 1 million endpoints.

Test Category 2: Congestion Management AI training workloads generate repetitive micro-congestion during the back-propagation gradient synchronization phase.

ECN Marking Accuracy and Threshold Objective: Verify that the DUT marks packets with ECN CE at the configured threshold with correct granularity. Procedure: Configure threshold T on DUT egress queue. Verify: (a) no packets marked below T; (b) 100% marked above maximum threshold; (c) appropriate WRED/RED probability ramp between thresholds. Test thresholds: low (~100KB), medium (~1MB), high (~5MB). Reporting: Plot ECN marking probability vs. instantaneous queue depth. Report measured threshold accuracy (deviation from configured).

PFC Behavior Under Incast Objective: Characterize DUT's PFC generation behavior under N:1 incast conditions. Procedure: Generate N:1 incast at 100% line rate, N = {2, 4, 8, 16, 32, 64}. Measure PFC PAUSE frame count/sec per hop, PFC PAUSE duration per port, PFC storm onset, and end-to-end throughput. Test SHOULD verify correct headroom sizing and PFC watchdog effectiveness.

DCQCN Convergence Time Objective: Measure time for DCQCN to converge to fair-share rate after congestion onset. Procedure: Establish M flows through a common bottleneck. At T0, inject additional M flows (creating 2:1 oversubscription). Measure time until all 2M flows achieve rates within 10% of fair share. Repeat for M = {4, 16, 64, 256}. Vary DCQCN parameters and report sensitivity.

PFC Storm and Deadlock Resilience Objective: Verify the DUT does not enter PFC deadlock or sustained PFC storm under adversarial traffic. Procedure: Generate cyclic traffic patterns known to cause PFC deadlocks. Run for 300 seconds. The DUT MUST demonstrate resilience via PFC watchdog or architectural immunity (e.g., VOQ-based scheduling).

Test Category 3: Load Balancing Efficacy Load balancing across parallel fabric paths is critical for AI training fabrics because the traffic consists of a small number of high-bandwidth, long-lived elephant flows.

ECMP Entropy and Polarization Objective: Quantify traffic polarization under standard ECMP hashing for AI training flow patterns. Procedure: Configure standard 5-tuple ECMP. Generate traffic with Q = {1, 4, 8, 16, 32} QPs per src-dst pair. Measure per-link utilization, MMR, and JFI. Test with and without BTH-aware hashing. Repeat for fabric sizes of 8, 16, 32, and 64 leaf switches.

Dynamic Load Balancing (Flowlet) Objective: Evaluate DUT's flowlet-based DLB performance and compare to baseline ECMP. Procedure: Configure vendor-specific DLB (document algorithm type). Generate traffic with Q=4 QPs. Measure MMR, JFI, per-link utilization, out-of-order rate. Vary flowlet gap timer and report sensitivity.

Packet Spraying Objective: Evaluate DUT's per-packet spraying performance and quantify the utilization vs. reordering tradeoff. Procedure: Configure per-packet load balancing. Measure MMR (expected ~1.0), JFI (expected ~1.0), out-of-order rate, and RDMA retransmission impact. If the DUT provides an in-fabric reorder buffer, document per .

Jain Fairness Index Measurement Objective: Single-number summary of load balancing quality comparable across all strategies. Formula:

Jain Fairness Index Formula

where LinkTx_i = transmitted traffic on fabric link i, N = total parallel links. Range: 1/N (worst) to 1.0 (perfect). Reporting: Report JFI for each load balancing strategy. Provide bar chart comparing ECMP, DLB, and packet spray.

Test Category 4: Collective Communication Benchmarks These tests evaluate the fabric's performance under realistic collective communication patterns. Unlike synthetic RDMA tests in and , these exercise the full stack including the collective library (NCCL , RCCL, or equivalent).

AllReduce Benchmark Objective: Measure fabric performance during AllReduce operations,the dominant collective for gradient synchronization in data-parallel training. Procedure: Using N accelerators connected through the DUT fabric, execute AllReduce (sum) operations using the collective communication library benchmark suite (e.g., nccl-tests or equivalent). Test parameters:

• Message sizes: 1 MB, 8 MB, 64 MB, 256 MB, 1 GB, 4 GB
• Accelerator counts (N): 8, 16, 32, 64, 128, 256, 512, 1024
• Minimum iterations per (message_size, N) pair: 100
• Load balancing strategies: ECMP, DLB, packet spray

For each (message_size, N) pair, record average, P50, P95, and P99 BusBW, ECN marking ratio, PFC pause count, and per-link utilization. The collective algorithm in use MUST be verified via library tracing for each message size bucket and reported alongside the BusBW result. If the library selects the algorithm dynamically (e.g., tree-based for small messages, ring for large messages), algo_factor varies with message size and MUST be reported per bucket, not as a single value. For ring AllReduce, algo_factor = 2*(n-1)/n. See for the full algo_factor reference table and mandatory reporting requirements. Reporting : Tabulate BusBW for each (message_size, N, LB_strategy, algo_factor) combination. The algo_factor column is REQUIRED; results without it are incomplete. Plot BusBW vs. N for each message size. Report BusBW efficiency = BusBW / NIC_line_rate.

AlltoAll Benchmark Objective: Measure fabric performance during AllToAll operations the dominant collective for Mixture-of-Experts (MoE) expert parallelism dispatch and pipeline-parallel communication. Procedure: Using the same message sizes, accelerator counts, iteration count, and load balancing strategies as , execute AllToAll operations via the collective communication library. AllToAll generates the worst-case fabric stress pattern: every accelerator simultaneously sends a unique payload to every other accelerator in the group, creating maximum entropy and N-to-N incast at every fabric link. This makes AllToAll JCT the most sensitive single indicator of fabric congestion management quality. For AllToAll, algo_factor = (n-1)/n regardless of topology or library implementation. BusBW reports MUST state this value explicitly. See . Measurement: Report BusBW (average, P50, P95, P99), JCT per iteration, ECN marking ratio, PFC pause count, and per-link utilization for each (message_size, N, LB_strategy) combination. Reporting: Same table format as , with algo_factor column required. Additionally report JCT for each configuration; JCT degradation relative to the ECMP baseline SHOULD be highlighted as the primary congestion sensitivity indicator.

AllGather Benchmark Objective: Measure fabric performance during AllGather operations, the dominant collective for weight and activation distribution in tensor-parallel and pipeline-parallel training. Procedure: Using the same message sizes, accelerator counts, iteration count, and load balancing strategies as , execute AllGather operations via the collective communication library. AllGather consists of a gather phase only — each accelerator contributes a shard and receives the full concatenated tensor. There is no reduce phase, which produces lower peak fabric load than AllReduce at equivalent message size and N. This makes AllGather a useful baseline for isolating the gather-path fabric contribution from the combined send-and-reduce cost. For ring AllGather, algo_factor = (n-1)/n. BusBW reports MUST state this value explicitly. See . Measurement: Report BusBW (average, P50, P95, P99), JCT per iteration, ECN marking ratio, PFC pause count, and per-link utilization for each (message_size, N, LB_strategy) combination. Reporting: Same table format as , with algo_factor column required. Report BusBW efficiency = BusBW / NIC_line_rate. Where results are compared to AllReduce under identical parameters, the BusBW ratio (AllGather / AllReduce) quantifies the fabric overhead attributable to the reduce phase.

Collective Communication Library Bus Bandwidth Summary Reporting template: Collective Communication Bus Bandwidth Summary

Collective	Msg Size	N Accels	ECMP BusBW (Gbps/accel)	DLB BusBW (Gbps/accel)	Spray BusBW (Gbps/accel)
AllReduce	1GB	128	(meas)	(meas)	(meas)
AllReduce	1GB	512	(meas)	(meas)	(meas)
AlltoAll	1GB	128	(meas)	(meas)	(meas)
AlltoAll	1GB	512	(meas)	(meas)	(meas)
AllGather	1GB	128	(meas)	(meas)	(meas)
AllGather	1GB	512	(meas)	(meas)	(meas)

Test Category 5: Job Completion Time (JCT) Benchmarks JCT is the single most important user-facing KPI for AI training fabrics, directly determining accelerator utilization and training cost.

Synthetic JCT Under Controlled Conditions

• Objective: Measure JCT for a defined synthetic workload with a known computation-to-communication ratio to isolate fabric-induced overhead. Procedure: Define a synthetic training iteration as a strictly sequential model:
  1. Computation phase of C milliseconds (simulated sleep or GPU compute kernel)
  2. Communication phase: AllReduce of S bytes across N accelerators
  Synthetic JCT Test Parameters

  Parameter	Values
  Computation time C	10 ms, 50 ms, 100 ms, 500 ms
  Message size S	256 MB, 1 GB, 4 GB
  Accelerator count N	64, 128, 256, 512, 1024
  Iterations	1000

  Execute 1000 iterations and measure total wall-clock JCT.

  JCT Ratio Calculation

  This model assumes strictly sequential compute and communication phases and represents a conservative upper bound on communication overhead. Many frameworks overlap these phases via gradient bucketing or asynchronous collectives, reducing the effective communication overhead visible in wall-clock JCT. Implementations using overlapped execution SHOULD additionally report:

  Overlap Fraction Calculation

  An Overlap_Fraction of 0 indicates fully sequential execution; 1.0 indicates communication is perfectly hidden behind compute. When overlap is present, the residual fabric overhead SHOULD be reported as: The Overlap_Fraction and communication library overlap configuration (e.g., bucket size, number of async streams) MUST be documented as part of the test configuration when this optional measurement is reported. Reporting: Tabulate JCT Ratio for each (C, S, N, LB_strategy combination. Plot JCT Ratio vs. N to characterize fabric scalability.
  • NOTE: JCT Ratio < 1.05 indicates excellent fabric performance; 1.15 indicates significant fabric-induced overhead. These are non-normative illustrative reference values only.

MLPerf-Aligned JCT Objective: Measure JCT using MLPerf Training benchmark workloads to enable comparison with published industry results. Procedure: Execute MLPerf Training closed-division workloads (e.g., BERT, ResNet, GPT-3 175B) per MLPerf submission rules. Simultaneously capture all fabric KPIs from . Report time-to-train and/or tokens-per-second.

Multi-Tenant JCT Interference Objective: Quantify JCT impact when multiple training jobs share the same fabric. Procedure: Configure two or more independent training jobs. Jobs SHOULD overlap in spine-layer link usage. Measure baseline JCT (isolated) and contention JCT (simultaneous).

JCT Interference Factor

Test with spine link overlap: 0%, 25%, 50%, 75%.

Test Category 6: Scale and Convergence

Fabric Scale Limits Objective: Determine the maximum fabric scale at which the DUT maintains acceptable KPI performance. Procedure: Progressively increase active accelerator endpoints from N=64 to maximum topology support while running AllReduce (, S=1GB). At each scale point record JCT Ratio, BusBW, ECN ratio, PFC count, CPU and memory utilization. Also measure BGP/routing convergence time after clearing all adjacencies (analogous to Sections 3.10, 3.11, 4.9, 4.10).

Link Failure Convergence Objective: Measure traffic disruption and JCT impact when a fabric link fails during active training. Procedure: With the fabric fully loaded (AllReduce, N=128, S=1GB), administratively fail a spine uplink. Measure:

• Duration of packet loss
• Packets lost
• JCT overhead for the failure iteration vs. steady state
• Time for load balancing mechanism to redistribute flows

Repeat for: leaf uplink failure, spine switch failure, superspine link failure (if applicable). Test under each load balancing strategy.

Zero-Impact Failover Measurement Objective: Verify vendor claims of zero-impact or sub-microsecond failover. Procedure: Execute with nanosecond-precision measurement. A failure is considered "zero-impact" if the measured JCT for the failure iteration is within the P99 JCT of steady-state iterations.

Test Category 7: Soak and Stability

24-Hour Sustained Load Objective: Verify DUT fabric stability under sustained AI training load over an extended period, following the methodology pattern from Sections 3.12, 4.11. Procedure: Configure DUT at maximum validated scale from . Generate bidirectional collective communication traffic (alternating AllReduce and AlltoAll). Run continuously for 24 hours. Sample all KPIs from every 60 seconds. There SHOULD NOT be any memory leaks, crashes, or CPU spikes. Any anomaly MUST be reported with timestamp and duration. Reporting: Time-series plots of JCT Ratio, BusBW, ECN ratio, PFC count, CPU, and memory over the 24-hour period. Report standard deviation of JCT Ratio (stability metric).

Resource Leak Detection Objective: Detect memory leaks, handle exhaustion, or gradual performance degradation in DUT software. Procedure: Record per-process memory usage at T=0, T=1h, T=6h, T=12h, T=24h. Compute linear regression slope of memory usage over time. A slope exceeding 1MB/hour for any process indicates a potential memory leak and MUST be reported. Also monitor forwarding-plane counter wraparounds and hardware table occupancy trends.

Reporting Format Test reports MUST include the following sections:

1. DUT Identification: Complete parameters from for all fabric components.
2. Test Topology: Diagram and description per , including physical cabling.
3. Test Configuration: All DUT configuration parameters: QoS policies (ECN thresholds, PFC headroom, DCQCN parameters), load balancing mode, buffer allocation, and vendor-specific tuning.
4. Host Configuration: Complete host stack description per including NIC firmware, driver, collective library version, and any tuning. For UET tests, additionally report: UEC compliance profile, libfabric provider version, NIC UEC firmware version, and enabled optional link-layer features (LLR, Packet Trimming, PRI, CBFC).
5. Test Results: For each test from through , provide specified tables, graphs, and statistical summaries. For tests, results MUST include side-by-side UET vs. RoCEv2 comparison data on the identical DUT fabric.
6. Anomalies: Any deviations from specified procedures, test failures, or unexpected behaviors MUST be documented.
7. Repeatability Statement: Report iteration count and coefficient of variation (std deviation / mean) for each test's primary metric. CV below 5% is RECOMMENDED for test validity.

Security Considerations This document defines benchmarking methodologies for controlled laboratory environments and does not introduce new security mechanisms or protocols. Per , the tests defined herein MUST NOT be performed on production networks. The use of dedicated test IP address ranges per Appendix C (198.18.0.0/15) is RECOMMENDED to prevent accidental interaction with production infrastructure. When RDMA/RoCEv2 traffic is used, the test environment SHOULD be isolated from production RDMA fabrics to prevent QP number space collisions or inadvertent PFC propagation. When UET traffic is used (), the test environment MUST ensure that UDP port 4793 traffic does not leak to production networks and that PDC identifier spaces are isolated. UET's optional transport security sub-layer (TSS) SHOULD NOT be enabled during performance benchmarking unless transport security overhead is explicitly being measured.

IANA Considerations This document makes no request of IANA.

References Normative References This memo discusses and defines a number of terms that are used in describing performance benchmarking tests and the results of such tests. This memo provides information for the Internet community. It does not specify an Internet standard. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document is a republication of RFC 1944 correcting the values for the IP addresses which were assigned to be used as the default addresses for networking test equipment. This memo provides information for the Internet community. This document is intended to provide methodology for the benchmarking of local area network (LAN) switching devices. This memo provides information for the Internet community. The purposes of this informational document are to establish definitions and describe measurement techniques for data center benchmarking, as well as to introduce new terminology applicable to performance evaluations of data center network equipment. This document establishes the important concepts for benchmarking network switches and routers in the data center and is a prerequisite for the test methodology document (RFC 8239). Many of these terms and methods may be applicable to network equipment beyond the scope of this document as the technologies originally applied in the data center are deployed elsewhere. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The purpose of this informational document is to establish test and evaluation methodology and measurement techniques for physical network equipment in the data center. RFC 8238 is a prerequisite for this document, as it contains terminology that is considered normative. Many of these terms and methods may be applicable beyond the scope of this document as the technologies originally applied in the data center are deployed elsewhere. Fundamental benchmarking methodologies for network interconnect devices of interest to the IETF are defined in RFC 2544. This memo updates the procedures of the test to measure the Back-to-Back Frames benchmark of RFC 2544, based on further experience. This memo updates Section 26.4 of RFC 2544. Ultra Ethernet Consortium Informative References The Benchmarking Methodology Working Group (BMWG) has been developing key performance metrics and laboratory test methods since 1990, and continues this work at present. The methods described in RFC 2544 are intended to generate traffic that overloads network device resources in order to assess their capacity. Overload of shared resources would likely be harmful to user traffic performance on a production network, and there are further negative consequences identified with production application of the methods. This memo clarifies the scope of RFC 2544 and other IETF BMWG benchmarking work for isolated test environments only, and it encourages new standards activity for measurement methods applicable outside that scope. This document is not an Internet Standards Track specification; it is published for informational purposes. NVIDIA n.d. OpenFabrics Interfaces Working Group n.d. MLCommons n.d.

KPI-to-Test Mapping Summary KPI-to-Test Mapping Summary

KPI	Test Section	Measurement Method	Reporting Unit
Throughput Rate		Binary search, zero-loss	Tbps, % line rate
Latency (P99)		Tagged frame, loaded / unloaded	us
Burst Absorption		Max burst without loss	frames, bytes
ECN Accuracy		Queue depth vs. marking	threshold deviation %
PFC Behavior		Incast sweep N=2..64	PAUSE events/sec, duration
DCQCN Convergence		Rate stabilization after onset	us
PFC Deadlock		Cyclic adversarial traffic	observed/reported, watchdog events
ECMP Imbalance		MMR, JFI per QP count	dimensionless ratios
DLB Efficacy		Throughput delta vs. ECMP	%, out-of-order rate
Spray Efficacy		JFI, retransmission rate	dimensionless, retx/sec
AllReduce BusBW		CCL benchmark	Gbps per accelerator
AlltoAll JCT		CCL benchmark	seconds per iteration
AllGather BusBW		CCL benchmark	Gbps per accelerator
Synthetic JCT Ratio		Measured / Roofline	dimensionless
MLPerf JCT		Time-to-train	minutes, tokens/sec
Multi-Tenant Impact		Contention / Baseline JCT	interference factor
Scale Limit		Max N with JCT Ratio characterized	accelerator count
Failover Time		Loss duration on link fail	us
24h Stability		JCT Ratio std deviation	dimensionless
UET Throughput (RUD)		Binary search per transport service	Gbps, % line rate
UET First-Packet Latency		PDC establish + first data	us
UET Spray Efficacy		JFI/MMR under RUD spray	dimensionless, OOO rate
UET PFC-Free Loss Rate		Incast without PFC enabled	%, retx overhead
LLR Retry Latency		Per-hop error recovery time	nanoseconds
Packet Trimming Savings		BW saved during congestion	% bandwidth
CBFC vs PFC HOL Blocking		Head-of-line blocking duration	us
UET Collective BusBW		AllReduce/AlltoAll over UET	Gbps per accelerator
PDC Establishment Rate		Sustained PDC creation rate	PDCs/second
Max Concurrent PDCs		Scale limit per NIC	count

ASIC Feature Categories (Informational) This appendix identifies ASIC feature categories relevant to AI fabric performance. Implementers SHOULD document which categories are present and enabled on the DUT. Specific vendor names are intentionally omitted. ASIC Feature Categories

Feature Category	Sub-types	Relevance to AI Fabric	What to Report
Aggregate Switching BW	ASIC-level capacity	Cluster scale, bisection BW	Total Tbps; per-port speed (400/800GbE)
Buffer Architecture	Shared, VOQ, Cut-through	Microburst absorption, PFC behavior, lossless operation	Buffer type; total bytes; shared vs. dedicated split; per-port/queue allocation
Packet Distribution	Per-flow, Per-packet, Flowlet	ECMP load balancing quality and reordering risk	Supported granularities; in-fabric reorder buffer (yes/no)
Congestion Control	ECN marking, PFC, DCQCN	DCQCN convergence and lossless behavior	ECN granularity (port/queue/VOQ); PFC priorities; DCQCN parameter range
Adaptive Routing	Flowlet, ECMP, Spray, Topology-aware	Load balancing quality under collective patterns	Algorithm type; flowlet gap timer range; topology-aware support
Telemetry	Per-port, Per-queue, Per-flow	Required for KPI measurement during benchmarking	Monitoring granularity; streaming interval; INT support
Cluster Scale Support	2-tier, 3-tier	Applicable topology scales	Max cluster size per topology; ASIC count

All values MUST be reported based on vendor documentation or measured capability. Additional DUT capabilities affecting benchmark results MUST also be documented.

RoCEv2 Test Frame Format RoCEv2 Test Frame Format

Offset	Field	Size	Value / Description
00	Ethernet Dst MAC	6B	DUT next-hop MAC
06	Ethernet Src MAC	6B	Test equipment MAC
12	EtherType	2B	0x8100 (802.1Q) or 0x0800 (IPv4)
14	VLAN Tag (optional)	4B	PCP=3 (RoCEv2 priority), VID
18	IPv4 Header	20B	DSCP=26 (ECN-capable), Proto=17 (UDP)
38	UDP Header	8B	DstPort=4791 (RoCEv2), SrcPort=var
46	BTH (Base Transport Header)	12B	OpCode, DstQP, PSN, P_Key
58	RETH (if Write)	16B	VA, R_Key, DMA Length
74	Payload	var	Test data (incrementing octets)
var	ICRC	4B	Invariant CRC
var+4	FCS	4B	Ethernet Frame Check Sequence

UET (Ultra Ethernet Transport) Frame Format UET runs over UDP/IP using IANA-assigned destination port 4793. UET Frame Format

Offset	Field	Size	Value / Description
00	Ethernet Dst MAC	6B	DUT next-hop MAC
06	Ethernet Src MAC	6B	Test equipment MAC
12	EtherType	2B	0x8100 (802.1Q) or 0x0800 (IPv4)
14	VLAN Tag (optional)	4B	PCP=3 (UET priority class), VID
18	IPv4 Header	20B	DSCP=26, ECN=ECT(0), Proto=17 (UDP)
38	UDP Header	8B	DstPort=4793 (UET), SrcPort=entropy
46	UET Common Header	16B	Version, OpCode, PDC ID, PSN, Entropy Value, Flags
62	SES Header (Semantic)	var	Operation-specific (Write/Send/etc.)
var	PDS Header (Pkt Delivery)	var	Sequence, Credit, Ack fields
var	CMS Header (Cong. Mgmt)	var	ECN feedback, rate signals
var	Payload	var	Application data
var	ICRC	4B	Invariant CRC
var+4	FCS	4B	Ethernet Frame Check Sequence

Key Differences from RoCEv2 RoCEv2 vs. UET Comparison

Field	RoCEv2 Value	UET Value	Notes
UDP Dst Port	4791	4793	IANA-assigned for each protocol
Transport Endpoint	QP Number (24b)	PDC ID (variable)	Connectionless in UET
Sequence Number	PSN (24b)	PSN (extended)	Larger range for RUD OOO tolerance
Congestion Signal	ECN bits only	ECN + CMS sub-header	Sender + receiver signals in UET
Entropy Source	UDP src port	Explicit entropy field	Deterministic spray in UET
Ordering Guarantee	Always in-order (RC)	Per-service (ROD/RUD)	RUD allows OOO delivery
Min Header Overhead	~74B (Write)	~78B (est. Write)	Slight increase for sub-layer headers

1. UDP Destination Port: UET uses port 4793 vs. RoCEv2 port 4791.
2. Entropy Value: Explicit entropy field for ECMP path selection. Test equipment MUST vary this field to achieve uniform path distribution.
3. Transport Service Indicator: Header encodes transport service (ROD/RUD/RUDI/UUD). Tests MUST set this to match the service being benchmarked.
4. PDC Identifier: Connectionless PDC ID replaces RoCEv2's Destination QP. Test equipment MUST track PDC lifecycle for accurate measurement.
5. Layered Sub-Headers: UET uses four sub-layers (SES, PDS, CMS, TSS) with variable-length headers. Implementations MUST follow Section 4 for wire format details.
6. Optional Link Layer Headers: When LLR, Packet Trimming, or PRI features are enabled, additional link-layer framing may be present. Test equipment MUST be configured to recognize and parse these.

Acknowledgments Contributions and review are solicited from the BMWG mailing list (bmwg@ietf.org). The BMWG chairs and Area Director are identified at https://datatracker.ietf.org/group/bmwg/about/.