Skip to main content

Module ramp

Module ramp 

Source
Expand description

In-band concurrency ramp: find the useful connection count during the transfer, not before it.

§Why this replaces the probe

The standard way to pick a connection count is to probe: fetch a slab with one connection, then two, then three, comparing aggregate goodput, and settle where the marginal gain stops paying. That is what crate::Admission does, and it is the right decision rule. The problem is where the samples come from.

HARP (Kim, Yildirim & Kosar, SC’16) states the objection plainly: probing captures instantaneous load but “may bring too much probing overhead”, because each sample is an extra transfer paid for before the real one begins. Measured on this client against a live path with a 3.15 MB object, the climbing probe made the whole transfer 1.96x slower than not probing at all — 18.2 s median against 8.3 s, paired across 9 interleaved repetitions, p = 0.004. The search cost more than the concurrency it found could recover. HARP’s own answer is to amortise the samples across a historical corpus of past transfers, so a new transfer needs at most one probe.

This module takes the cheaper route available to a downloader: run the same search on the object itself. Concurrency is adjustable mid-transfer ([Scheduler::set_active_limit]), so the ramp starts at one connection, watches the aggregate rate over a short window, and admits another connection while the marginal gain justifies its setup cost. Every byte moved while searching is a byte of the object that had to be fetched anyway, so the search is free in bytes — its only cost is arriving at the final concurrency a few windows late.

§What it measures, and the trap in measuring it

The quantity that decides whether to admit connection k+1 is the aggregate goodput at k, and it must be sampled after the new connection’s transient has passed. A window that starts the instant a connection is admitted measures its handshake and slow-start, not its steady contribution, and would conclude that every added connection helps less than it does. So each admission is followed by a settling delay before the next window counts.

The opposite error is just as easy: a window long enough to be clean is a window during which a saturated path is running more connections than it needs. The window length is therefore expressed in terms of the measured setup cost delta — the same quantity the repair deadband is floored at — because that is the timescale on which a connection’s contribution becomes visible.

Structs§

ConcurrencyRamp
Drives concurrency upward on a live transfer while it pays to do so.

Enums§

Ramp
Outcome of feeding a window of observations to the ramp.