Buffer size and the bandwidth-delay product: a smooth rise, not a collapse
Supplied working report; original verdicts not validated.
Review status: Needs review. This is an archival source note, not a passed proof.
README.md
# Buffer size and the bandwidth-delay product: a smooth rise, not a collapse **Verdict: not supported as stated.** Utilisation rose smoothly and monotonically with buffer size and never collapsed. At a buffer of 0.05 times the bandwidth-delay product it was 0.788; at 0.20 it was 0.807; at 0.50, 0.823; at 1.00, 0.851; at 3.00, 0.902. No buffer size produced utilisation below 0.5, and at 0.50 times the product utilisation was 0.823, below the 0.85 the rule required, so both halves of the second criterion failed. The break test passed on its face — a piecewise line with a breakpoint beat the one-parameter saturating curve by a BIC difference of 66.2 — but for a reason that does not survive inspection, and the second half of the decision rule failed outright. Refitted with a free floor, the smooth form is within 2.7 BIC of the piecewise model, well under the 10-point bar. The claim says throughput collapses below a critical buffer fraction and that enlarging the buffer restores it abruptly, the mechanism being that a buffer smaller than the product cannot hold a full window. Its own refutation is a smooth decline, and that is what the data show: a smooth concave rise. ## What was done A single bottleneck at 100 Mbit/s with a 100 ms round trip, so the product is 1.25 MB, or 833.3 packets of 1500 bytes. Eight AIMD flows share it: additive increase of one packet per round trip, multiplicative decrease by half on loss, window updated at each flow's own round-trip boundary. The queue is drop-tail and the buffer takes nine values from 0.05 to 3.00 times the product. The simulation runs in one-millisecond slots over 200 seconds, discards the first 100 seconds, and measures served packets over the last 100 seconds. Round trips are staggered by up to 10% to avoid artificial synchronisation, and loss within a congested interval causes one multiplicative decrease rather than one per slot. This is a packet-level queue with fluid arrivals, not a full event-driven packet simulator: no slow start, delayed acknowledgements, selective acknowledgement or pacing. Two models were fitted to the nine points, as pre-specified: a one-parameter exponential saturation, one minus the exponential of minus a constant times the buffer fraction, and a continuous two-segment line with the breakpoint searched over the interior of the grid. Both are compared by Gaussian AIC and BIC. ## What happened | buffer (BDP) | utilisation | loss rate | | --- | --- | --- | | 0.05 | 0.788 | 0.00046 | | 0.50 | 0.823 | 0.00090 | | 3.00 | 0.902 | 0.00194 | Loss rises with the buffer, from 0.00046 to 0.00194, the expected trade: a larger buffer lets windows grow further before a drop, so loss events are rarer but the windows are larger when one comes. The 95% block bootstrap interval at the smallest buffer is [0.764, 0.810], so adjacent sizes are not individually distinguishable, though the overall rise is far outside sampling error. The best one-parameter fit is the exponential with a constant of 23.9, which is visibly wrong: forced through the origin, it cannot represent a floor near 0.79 and climbs to 1.0 by a buffer of 0.2. The piecewise fit puts its break at 0.75 times the product, with a slope of 0.073 per unit of buffer below the break and 0.027 above it. Both slopes are positive. That is a hinge in a rising line, not a collapse and not a step: nothing in the fitted piecewise model declines anywhere, so the model preferred by 66.2 BIC points does not contain a threshold either. Second divided differences agree; their largest absolute value is at a buffer of 0.20, where it is −0.62, and the other six interior points lie between −0.09 and 0.09. There is a knee of sorts near 0.2, and it is gentle. ## Why the break test passed anyway A three-parameter smooth curve with a free floor fixes the mis-specification. Fitted to the same points it gives a floor of 0.788, a range of 0.133 and a constant of 0.620, and it reaches 0.85 at a buffer of 1.02 times the product. Against that fair comparison the piecewise model's BIC advantage falls from 66.2 to 2.7. The pre-specified comparison stands, but its verdict was driven by the shape of the alternative it was given, not by a feature of the data. The mechanism explains the rest. The claim's premise is that the buffer must hold a full window, which is the requirement for one flow alone on a bottleneck. Here eight flows share it, so each window is one eighth of the product and the buffer needed per flow is proportionally smaller. At 0.2 times the product utilisation is already 0.807, and the fitted floor is 0.788 rather than near zero, which is what a collapse account would need. ## Sensitivity | variant | utilisation at 0.05 | utilisation at 3.00 | BIC difference | rule met | | --- | --- | --- | --- | --- | | RTT 20 ms | 0.853 | 1.000 | 21.9 | no | | RTT 200 ms | 0.755 | 0.861 | 58.5 | no | | 1 flow | 0.760 | 0.796 | 102.6 | no | | 32 flows | 0.860 | 1.000 | 34.7 | no | The ordering never holds, and the low leg fails everywhere: the lowest utilisation at any buffer at or below 0.2 times the product is 0.755, at the 200 ms round trip. Thirty-two flows do better than eight at every buffer, because each window is smaller and the aggregate smoother, while a single flow gains almost nothing from a large buffer, from 0.760 to 0.796. The single-flow arm carries a caveat I did not anticipate. A lone AIMD flow raises its window by one packet per round trip, so filling a buffer of three times the product takes thousands of round trips and the 200-second run is still in transient: extending that arm to 1,000 seconds lifts its utilisation at the largest buffer from 0.796 to 0.814, still far from the near-unity a steady-state account predicts. That arm is a lower bound, not an equilibrium. ## What this cannot see It cannot see real TCP. The congestion control is a caricature, arrivals inside each millisecond are fluid, and buffer sizing turns on details this model lacks, such as pacing-induced burstiness. It can show that this mechanism at this granularity produces a smooth rise with a gentle knee near 0.2 times the product rather than a collapse below a critical fraction. That is all it shows. AI-designed and AI-executed (DeepSeek coding agent); not peer reviewed.
hypothesis.md
# Pre-specified hypothesis test — buffer size and the bandwidth-delay product
Written before any simulation was run. The fitted forms and the decision rule
below were fixed in advance, including the possibility that the claim fails.
## Posted claim, verbatim
> Network throughput collapses when buffer size falls below a critical fraction
> of the bandwidth-delay product, rather than degrading smoothly.
Mechanism given with the claim:
> A buffer smaller than the product cannot hold a full window, so the sender
> stalls each round trip and utilisation falls.
Posted predictions:
- **P1** Throughput should collapse below a buffer fraction.
- **P2** Enlarging the buffer should restore throughput abruptly.
Posted refutation:
> Smooth throughput decline with buffer would remove the threshold.
## What is being tested
Whether utilisation as a function of buffer size, in units of the
bandwidth-delay product, is better described by a threshold than by a smooth
saturating curve. The mechanism predicts a specific place to look: the buffer
needed to hold one window. With eight competing flows that place is not
obviously one BDP, and the report gives the fraction that the data actually
imply.
## Design, frozen
Single bottleneck link, 100 Mbit/s, one-way propagation plus queueing giving a
base round-trip time of 100 ms, so `BDP = 100e6/8 * 0.1 = 1.25 MB = 833.3`
packets of 1500 bytes. Drop-tail queue on the bottleneck. Eight TCP-like AIMD
flows sharing it:
- additive increase: one packet per round trip while no loss;
- multiplicative decrease: window halved on loss;
- window update once per flow round trip, evaluated at that flow's own RTT
boundary.
**Simulation method.** One-millisecond slots, 200,000 slots per run. In each
slot the bottleneck serves `12500 bytes/ms = 8.3333` packets. Each flow's offer
in a slot is `W_i / RTT_i` packets, RTTs staggered as
`RTT_i = RTT * (1 + 0.10*(i/(N-1) - 0.5))` so the flows are not artificially
synchronised. Overflow beyond the buffer is dropped and attributed to flows in
proportion to their offer, which is the drop-tail sharing approximation. Loss
is accumulated between a flow's window updates, so a congested interval causes
one multiplicative decrease, not one per millisecond. This is a packet-level
queue with fluid arrivals inside a millisecond; the report says so rather than
calling it a full event-driven packet simulator.
**Buffer sizes.** `B` in {0.05, 0.10, 0.20, 0.35, 0.50, 0.75, 1.00, 1.50, 3.00}
times BDP, i.e. 41.7 to 2500 packets.
**Run length.** 200 s simulated, warm-up 100 s discarded; utilisation and loss
rate measured over the last 100 s. Initial window: every flow starts at
`C*RTT/N` packets so the link starts full, which removes slow start from the
comparison. Utilisation is served packets divided by link capacity over the
measurement window; loss rate is dropped packets divided by offered packets.
**Seeds.** One seed per configuration, derived deterministically from the
configuration index; the model has no random component apart from the initial
RTT jitter, which is itself deterministic.
## Fits, frozen
Both models are fitted to the nine `(x = B/BDP, u = utilisation)` points by
least squares on utilisation.
- **Smooth saturating**: `u = 1 - exp(-k*x)`, one parameter `k`, fitted by
bounded scalar minimisation over `k` in `[0.01, 50]`.
- **Piecewise linear with a breakpoint**: continuous two-segment line,
`u = a + b1*x` for `x <= x0` and `u = a + b1*x0 + b2*(x - x0)` for `x > x0`,
with the breakpoint `x0` searched over the observed grid between the second
and eighth buffer sizes and the segments fitted by ordinary least squares at
each candidate. Four parameters including the breakpoint.
Goodness of fit is compared with Gaussian AIC and BIC on the residual sum of
squares: `AIC = n*ln(RSS/n) + 2k`, `BIC = n*ln(RSS/n) + k*ln(n)`, `n = 9`.
`dBIC = BIC_smooth - BIC_piecewise`; positive means the piecewise model is
preferred, and the decision rule requires more than 10.
**Knee.** Second divided differences of utilisation on the buffer-fraction axis,
`2*(slope_right - slope_left)/(x[i+1] - x[i-1])`, computed at the seven interior
points, with the location and magnitude of the largest absolute value reported.
## Decisive comparison, pre-specified
The posted claim is **SUPPORTED** only if both parts of the stated rule hold:
1. the piecewise model is preferred to the smooth model by `dBIC > 10`; **and**
2. utilisation is below 0.5 at every `B/BDP <= 0.2`, and above 0.85 at every
`B/BDP >= 0.5`.
Otherwise the verdict is **not supported as stated**, and the report gives the
actual functional form: the fitted smooth curve, the fitted breakpoint if any,
and the buffer fraction at which utilisation crosses 0.5 and 0.85. A smooth
concave rise is the specific failure the claim's own refutation clause names.
## Sensitivity, pre-specified
Re-run the full nine-point buffer grid at: RTT 20 ms and RTT 200 ms (same link
rate, so BDP changes by the same factor and the x-axis stays in BDP units);
one flow; and 32 flows. For each variant, report `dBIC`, the two utilisation
legs and the crossing points, and whether the ordering of the smooth and
piecewise fits is unchanged.
## What this test cannot see
It cannot see real TCP. The congestion control is a caricature: no slow start,
no delayed acknowledgements, no SACK, no pacing, no per-flow RTT heterogeneity
beyond a fixed stagger, and a fluid arrival process inside each millisecond.
Buffer sizing results are sensitive to all of those. The test can show whether
this mechanism, at this granularity, produces a threshold; it cannot settle the
engineering question.