The Case for Moving GPU Transport Control Back Into Software

UCCL-Tran answers the question in this series with a selective, not total, migration of responsibility. The system does not argue that CPUs should replace RDMA NICs or that software is automatically faster than hardware. It argues that congestion control, path selection, and loss behavior change with ML workloads quickly enough that fixing them inside a NIC can become the bottleneck, while the bulk path that moves data between the NIC and GPU should remain as close to hardware as possible. The judgment that follows is therefore about where transport state belongs.

That distinction lets us weigh UCCL-Tran on its own terms. The subject is a concrete software transport layer integrated with collective libraries, not an abstract call for programmability. Its value appears when a workload exposes a mismatch—colliding flows, a hot receiver, inefficient recovery, or inconsistent NIC behavior—and when the host, driver, GPU-memory path, and network provide enough support for software to act. Its cost appears when CPU time, signal quality, queue-pair state, or reassembly work becomes more important than the mismatch it is meant to fix.

The shift is selective, not total

The central design choice is a division between payload movement and transport policy. UCCL-Tran leaves collective libraries and GPU kernels responsible for preparing, reducing, and consuming tensor data. It uses RDMA or user-space packet I/O to move that data, and it relies on GPUDirect-style access where the NIC can reach GPU memory without a CPU bounce buffer. The software layer instead owns decisions about how aggressively to send, which path to choose, how to respond to acknowledgements or loss, and what state to keep for future decisions.

That division changes the speed at which a transport can evolve. A hardware transport must fit its state, algorithms, and signals into a NIC's fixed resources and release cycle. A software transport can change a congestion policy, add per-path state, or adapt a recovery rule in a normal user-space process. UCCL-Tran's plugin boundary lets a collective library continue to expose its application-facing operations while the transport beneath it changes. The point is not that software has no interface constraints. It is that the constraints are visible in code and can be revised without replacing the whole NIC.

The three case studies make the ownership change concrete. For a flow collision, the relevant question is which path a collective's traffic uses. A single-path-per-connection transport can leave physical routes unused, so UCCL-Tran uses many queue-pair identities, per-path state, and RTT-aware selection to make path choice a software decision. For incast, the question is who can see the last-hop bottleneck soon enough. EQDS gives a receiver-side pacer the ability to allocate credits to senders before a queue and upstream pause disturb other flows. For loss, the question is what data is missing and how much should be repeated. Selective retransmission keeps reordering state and uses selective acknowledgements so software can resend missing data rather than a broad suffix.

These policies are different, but they share a reason for leaving hardware. Each requires state or context that a fixed transport may not have: per-path RTTs, receiver demand, application-relevant recovery choices, or a reordering buffer larger than the NIC can afford. The software layer does not remove the physical bottleneck. It moves the policy decision to a place where the state can be represented and changed. That is why the theme is transport control returning to software, not networking returning to the CPU.

The data/control split also clarifies what “hardware-level performance” means in the paper. UCCL-Tran does not reproduce an ASIC's every action in a general-purpose loop. It uses UC when the NIC can still segment and reassemble a large transfer, uses RC as a compromise when its congestion control can be disabled, and uses UD or related datagram techniques when avoiding fixed control logic matters more than the extra packetization and reassembly work. The software layer is efficient because it chooses which work to inherit from hardware and which work to take over.

That choice has a correctness boundary. Control metadata and payload must share their arrival or loss fate.