Swift was developed by Google and is deployed across Google's Jupiter fabric and Alibaba's RDMA clusters. Unlike DCQCN, Swift does not require ECN marking at the switch. Instead, the NIC itself measures per-flow RTT and reacts to RTT increase directly.

The core algorithm

Swift operates on a simple principle: if RTT > target delay, reduce the rate; if RTT < target delay, increase the rate. The target delay is set to the baseline propagation delay plus a fixed queuing budget:

target_delay = propagation_delay + queuing_budget
             = ~800ns (fabric RTT)    + 5µs (typical)
             = 5.8µs

if measured_RTT > target_delay:
    cwnd = cwnd × (1 - β × (RTT - target) / RTT)   # multiplicative decrease
else:
    cwnd = cwnd + α / cwnd                           # additive increase

Where β (beta) is the multiplicative decrease factor (typically 0.5) and cwnd is the congestion window in packets.

Where RTT is measured

On Google's RDMA hardware, RTT is measured per-QP directly in NIC hardware, timestamping the packet departure and the ACK arrival. The measured RTT includes:

• Propagation delay (wire + switch cut-through latency)
• Queuing delay at every switch in the path
• NIC processing latency at the remote end

This means Swift gets signal from the entire path, not just the most congested hop. Under incast, RTT begins rising immediately as the first packets enter the switch buffer — much earlier than ECN would mark (which requires queue depth to reach 500 KB first).

Swift's advantage: 1-RTT feedback

Time 0:   Queue starts building at switch
Time +0:  RTT of queued packets immediately starts rising
Time +1RTT: Sender sees RTT increase; rate is reduced

Swift reacts in 1 RTT versus DCQCN's 2 RTTs. Under incast scenarios with tight latency budgets, this half-RTT difference is significant.

Swift's limitation: no commodity NIC support

Swift requires per-QP RTT measurement in NIC hardware. ConnectX-7 does not natively implement Swift's RTT measurement model in the same way as Google's custom RDMA silicon. Swift-like behavior can be approximated with ib_write_lat loop timing and kernel-bypass sockets, but this is not production Swift. This is the primary reason DCQCN remains dominant in NVIDIA-based deployments: ConnectX-7 ships with DCQCN support.