[spike][protocol] Control-plane cost at constellation scale — does reactive flooding survive 1584 nodes?

[danieljoppi]

Spike under #194. Answer this before tuning anything else in the sub-epic — if flooding is disqualifying at scale, the tuning targets change.

The concern

A Starlink-class shell is 1584 satellites (72 planes × 22), each with ~4 ISLs, network diameter ~20–40 hops. AntHocNet's reactive route discovery is a broadcast flood, bounded by the two-factor acceptance band (antAcceptanceFactor a1=0.9 / antAcceptanceFactorNewHop a2=2.0) rather than by a hop budget since #177.

The repo's own evidence says this is the pressure point: #173 recorded a 7×7 grid costing 30,090 ants per discovery before the band was fixed, and large-scale at 21.7% PDR / NRL 3071. #177 brought that to 154 ants per discovery, "~3.1n and flat in n" on the same grid. Flat in n is the encouraging part — but it was measured at n=49, and the extrapolation to n=1584 is exactly the kind of claim that should be measured rather than assumed.

Add the steady-state cost: 1584 nodes × 4 interfaces × 1 Hz hello ≈ 6.3k control packets/s before a single ant is sent (see #204).

Method

Cheap first, expensive only if needed:

1. Analytic: extend the ~3.1n observation from [protocol] decide the reactive route-setup design on measurement: thesis single-route (A) vs source-parameterised band (B) vs the repo bound (C, shipped) #177 with the ISL-grid degree (4, versus a dense wifi neighbourhood) — a +Grid torus has fewer neighbours per node than the disk-model grid, which should help. Predict ants-per-discovery at n = 100 / 400 / 1584.
2. Core testbench: if [core] Abstract discrete-event testbench in core/tests — trend regression without a simulator #64's abstract discrete-event testbench exists by then, this is exactly its use case — trend regression at scale with no simulator. If it does not, note that this spike is an argument for building it.
3. ns-3: only at the largest scale the substrate ([epic][ns3] Satellite simulation substrate — pick the platform (spike set) #193) can actually run — see the node-count-ceiling question in every substrate spike.

Answer these

1. Ants per discovery and control packets per second at n = 100 / 400 / 1584 on a +Grid torus.
2. Which bound is load-bearing at scale — the acceptance band, maxHistory (4096), networkDiameter (30), or none of them?
3. Is networkDiameter = 30 adequate for a constellation's 20–40 hop diameter, or does the expanding-ring search silently cap reachability the way the per-path budget did in [protocol] reactiveMaxBroadcasts=2 caps discoverable paths at ~5 hops — routes beyond it are never found #169?
4. What NRL would a satellite benchmark ([epic][benchmark] Satellite benchmark harness + the precomputed-shortest-path control #196) show, and is that publishable next to a precomputed-path control that has essentially zero control traffic?

Acceptance

A comment with the numbers and a verdict: flooding scales / needs a satellite-specific bound / is disqualifying. If the last, say what replaces it — that is a protocol-design ticket, not a tuning one, and should be opened as its own issue.

Related

#194 (parent), #173 and #177 (the flood-bound history and the ~3.1n measurement), #169 (the reachability trap the diameter question echoes), #64 (core testbench — the cheap way to run this), #196.