Overview

This chapter compares UCCL-Tran's two policy case studies: EQDS, which lets a receiver allocate credits before incast fills a last-hop queue, and selective retransmission, which uses GPU-resident reordering state, selective acknowledgements, and a bitmap to resend missing data. It distinguishes their triggers, state, and costs, then qualifies the results: EQDS tail-latency gains come from a constructed CX_IB scenario with a pacer thread, while loss comparisons include prior-work hardware figures that are not apples-to-apples.

Learning outcomes

EQDS changes incast timing by letting a receiver distribute credits before senders overwhelm the last-hop bottleneck; it does not remove the hot expert or raise link capacity.
Selective retransmission uses GPU-memory reordering state and selective acknowledgements to resend missing chunks, but chunk-level recovery can resend more than one missing packet.
The reported improvements are scenario-bound: EQDS uses a dedicated pacer in a CX_IB test, and hardware loss comparisons come from prior, non-identical experiments.

Keywords

UCCL-TranEQDSincastrecoveryreorderingpacer

UCCL-Tran's Transport Policies for Hard ML Workloads

UCCL-Tran becomes most consequential when it changes a transport policy rather than merely choosing a different queue pair. This chapter compares two such policies: receiver-driven EQDS for incast and selective retransmission for packet loss. The comparison shows what software ownership changes—the location of the decision, the state it can keep, and the event that triggers action—while also showing why the reported improvements must be read with their experimental boundaries.

The two cases address different failures. EQDS asks who should control senders when many of them converge on one receiver. Selective retransmission asks what should happen after data is missing or out of order. Treating them as one generic congestion-control improvement would hide the reason each policy exists and the evidence each result can support.

A receiver can control incast before the queue becomes a crisis

A sender-driven transport gives each sender responsibility for estimating congestion from the feedback associated with its own traffic. That arrangement is natural for independent flows, but it can react too late when many senders converge on one last-hop port. By the time a sender sees a severe congestion signal, the queue may already have grown, upstream flow control may have paused traffic, and unrelated flows may have become victims.

UCCL-Tran implements EQDS, an edge-queued datagram service with receiver-driven congestion control, to change that timing. The receiver becomes the point that allocates permission to send. In the paper's implementation, each NIC has a dedicated pacer thread. The pacer maintains lists of senders needing retransmission, actively sending, or waiting; it allocates credits and transmits credit packets over dedicated queue pairs. The transmit and receive engines notify the pacer through shared memory when data chunks arrive or a sender's state changes.

A credit is not merely an acknowledgement that data already arrived. It is a budget for future sending. The receiver can therefore limit the aggregate amount of traffic entering the last-hop constraint and distribute that budget among senders. If one receiver is hot, the pacing decision is made close to the place where capacity is scarce. This is the control loop's essential difference from a sender waiting for congestion to propagate backward through the fabric.

The distinction is especially relevant to MoE serving. A model may place different experts on different GPUs, and the request mix can make one expert temporarily much hotter than the others. A load-balancing system can replicate or move experts, but moving model state is comparatively slow. EQDS operates at the packet or message-flow timescale, so it can manage the burst while the higher-level placement decision remains unchanged. It does not remove the hot expert or increase its physical link rate; it keeps the transient demand from turning into an uncontrolled queue.

The policy also protects traffic that is not part of the incast. In a shared RDMA network, Priority Flow Control or its InfiniBand equivalent can pause upstream ports when a queue fills. That may prevent further loss at the immediate queue while disturbing flows that were merely passing through the same upstream resources.

Published by DeepMox

FAQ

How does EQDS control an incast?

EQDS controls an incast by making the receiver allocate credits for future sending through a pacer, limiting aggregate traffic before the last-hop queue becomes a crisis. The pacer adds scheduling work and needs a dedicated thread per NIC in the implementation.

How does selective retransmission differ from go-back-N recovery?

Selective retransmission resends only data identified as missing through selective acknowledgements and a bitmap, whereas go-back-N can repeat a broad suffix after an earlier gap. It still requires timeout tuning and chunk-level trade-offs.

How strong is the evidence for UCCL-Tran's EQDS and recovery gains?

The evidence is scenario-specific: EQDS is evaluated with 15-to-1 incast and 16-NIC permutation traffic on CX_IB, while loss results use instrumented UCCL-Tran drops and compare hardware figures from prior work. The comparison is not a controlled apples-to-apples benchmark.

Previous10 minUCCL-Tran: Multipath and Path Entropy

Next12 minUCCL-Tran: Collective and ML Results

UCCL-Tran: EQDS and Selective Recovery

UCCL-Tran's Transport Policies for Hard ML Workloads

A receiver can control incast before the queue becomes a crisis

FAQ