Skip to content

Chapter 20: Ultra Ethernet Consortium (UEC) · Part 6 of 10

Act 5 -- Congestion Control: End-to-End Without Pause Frames

UEC defines its own congestion control algorithm designed to work without PFC. The mechanism uses the ECN CE-bit in IP headers (the same ECN bit as DCQCN) but the response is ACK-based rather than CNP-based.

The flow:

  1. A UEC-capable switch marks outgoing packets with the ECN CE bit when its buffer occupancy exceeds a threshold. This is the same ECN marking mechanism used in DCQCN (Ch5). Switch configuration for this is identical: set Kmin and Kmax buffer thresholds for each traffic class.

  2. The receiver sees CE-marked packets and sets the C flag in ACK packets it sends back to the source. The ACK already had to travel back for SACK purposes -- piggybacking the congestion signal on it is free.

  3. The sender NIC firmware reads the C flag from incoming ACKs and reduces its injection rate. The rate reduction algorithm in UEC 1.0 is based on DCQCN's mathematical model (the same alpha-based multiplicative decrease, additive increase) but because the signal arrives on ACKs rather than CNPs, the feedback loop timing is slightly different.

Congestion feedback loop: DCQCN (2x RTT) vs UEC (1x RTT)
RTT progression (click step for detail)
Step 1
Sender NIC
t=0x RTT
Step 2
Switch
t=0.5x RTT
Step 3
Receiver NIC
t=1x RTT
Step 4
Receiver NIC
t=1x RTT
Step 5
Switch
t=1.5x RTT
Step 6
Sender NIC
t=2x RTT
Sender NICSender injects at 400G
Sender pushes packets at line rate. No congestion signal yet received.
DCQCN feedback cost
2x RTT
Packet CE receiver CNP packet sender
At 400G / 2us RTT: ~400 MB queued before sender responds
UEC feedback cost
1x RTT
Packet CE receiver sets C-flag ACK sender
Same ECN switch config. No extra CNP packet. Signal on existing ACK.
Switch ECN configuration is identical for both: Kmin/Kmax thresholds per traffic class, ECN marking enabled. The difference is entirely in what the endpoints do with the CE signal -- not in the switch.

Comparison with DCQCN

The feedback loop in DCQCN: packet arrives at congested switch -> switch marks CE -> packet arrives at receiver -> receiver generates CNP -> CNP arrives at sender -> sender reduces rate. Total feedback delay: 2 x network RTT (packet forward + CNP return).

The feedback loop in UEC: packet arrives at congested switch -> switch marks CE -> packet arrives at receiver -> receiver sets C flag in next ACK -> ACK arrives at sender -> sender reduces rate. Total feedback delay: 1 x network RTT (packet forward + ACK return). The ACK was going to travel anyway. The congestion signal is on the critical path, not an additional round trip.

This matters at 400G link speeds where a 2x RTT feedback delay vs 1x RTT feedback delay means the difference between marking 100 packets vs 200 packets before the sender responds. At 1.6 Tbps (next-generation 8x 200G), the congestion overshoot in DCQCN before the CNP loop closes becomes a real problem. UEC's faster feedback loop is designed for 400G-to-1600G.

PFC-free operation: what stays, what goes

What stays in a UEC fabric:

  • ECN marking on switches (identical configuration to RoCEv2)
  • Priority queuing for traffic classes (storage vs compute vs management)
  • DSCP marking on endpoints for traffic class identification

What goes:

  • PFC pause frame generation and processing (disabled on switches and NICs)
  • Lossless queuing configuration (headroom buffers for PFC, pause-propagation timers)
  • PFC watchdog configuration
  • The requirement that every device in a path agrees on PFC priority mapping