Diagnose the binding transport constraint before tuning

Start with a concrete user operation: a large object download, many small inference requests, a training checkpoint upload, or a stream of interactive updates. Record object sizes, concurrency, connection reuse, deadlines, endpoints, and relevant software versions. Define useful bytes as application payload successfully delivered for the stated purpose, then divide by the chosen elapsed interval. Wire throughput includes headers and retransmissions; application goodput does not. A large batch can produce excellent aggregate goodput while its slowest request misses a deadline, so collect completion distributions and success outcomes alongside byte rates.

Separate connection setup, security establishment, time to first useful byte, body transfer, and application processing using observable boundaries. Do not add overlapping intervals as if they were serial. For a long backlogged transfer, compare the usable flight limit divided by RTT with measured goodput and bottleneck capacity. For short requests, count dependent round trips and server work instead. A hypothesis that explains a bulk file's steady state may not explain a tiny response's completion. Keep the benchmark representative rather than changing the workload until a preferred optimization appears successful.

A receiver-limited flow should show constrained advertised space or receiver-consumption evidence; a small congestion budget should show sender state consistent with that limit. A standing-queue hypothesis predicts increased loaded RTT relative to an unloaded baseline and often sensitivity to offered load. Recovery-related stalls should align with loss signals, retransmission behavior, and flight timing, but retransmissions alone do not prove original loss. Host CPU saturation, interrupt load, copying, encryption work, or a slow producer can leave a fast network underused. Correlate application, socket, host, and network observations on a defensible timeline.

Packet capture is not an infallible view of the wire. Segmentation and receive offload can expose large aggregated units, capture loss can hide packets, and unsynchronized clocks can suggest impossible ordering. A single observation point may not distinguish forward loss from return-path ACK loss or endpoint scheduling. Record capture drop counters and offload context, and compare endpoint state with traces when possible. Explicitly label what is observed, inferred, and unknown. An honest unresolved ambiguity is more useful than confidently naming a router from an end-to-end delay graph that cannot locate the queue.

Choose an experiment that discriminates hypotheses. If you suspect receiver consumption, compare a controlled fast sink with the real consumer while preserving the network and payload. If you suspect a window ceiling, vary that limit only when another constraint is not already binding. If you suspect queueing, vary offered load and inspect both goodput and loaded RTT. Repeat measurements, document warm-up and background traffic, and include rollback criteria for live changes. More parallel connections can improve one benchmark by changing aggregate competition; that result does not establish that the original path lacked physical capacity.

Rehearse independent queue experiments before touching a system. For EACH run Reset, explicitly re-set BOTH rates, predict, then Play or Step. Compare (λ,μ)=(3,2), (2,2), and (1,2): from backlog four at t=0, expect growth, balance, and draining to zero at t=4 seconds respectively. Parameter edits retain t and recompute from four rather than continuing previous conditions. If measurements contradict the simple constant-rate prediction, investigate burstiness, feedback, service changes, or a wrong observation boundary. The separate M/M/1 estimate needs its stochastic assumptions; neither display identifies a controller, locates a queue, or reproduces an operating system.