# Overlap between the mux RTT/DeltaQ work and the Leios ΔQ report ## The opportunity The Leios ΔQ report ([`ouroboros-leios/analysis/deltaq/improved-leios/report.md`](../ouroboros-leios/analysis/deltaq/improved-leios/report.md)) is a paper model of Endorser-Block diffusion feasibility. It computes $P_{\text{cert}}$ as a function of network conditions (RTT distribution, per-connection throughput, per-mini-protocol tx-arrival) that it currently *assumes* rather than measures. Its Recommendation 5 explicitly names three missing measurements it wants back from the live SPO mesh. The mux RTT/DeltaQ work on this branch — the cookie-echo RTT window, per-`MiniProtocolNum` `TraceRecvDeltaQObservation`, and the burst-SDU `estBurstS` estimator — produces exactly that class of measurement, live, from the deployed node. A single testnet campaign can serve two distinct purposes: - **Validation**: substitute the report's assumed inputs with empirical distributions and see whether $P_{\text{cert}}$ holds up under real conditions. - **Adaptive Leios**: expose the same telemetry to running mini-protocols so the node reacts to the *observed* mesh, not the *assumed* one. That's a category shift from static-analytical protocol design to online closed-loop. Both angles are worth pursuing. The rest of this document maps the correspondence, sketches what each frame makes possible, and points at the operational deep-dives. ## Where the two lines of work meet The Leios report treats the network as a two-parameter box: (OWD, congestion-control regime). It says so directly in Recommendation 5 (`report.md:1598-1604`): > Three measurements would narrow the band: > - 95th-percentile SPO-to-SPO one-way delays (currently assumed 268 ms long-haul) > - End-to-end packet loss on intercontinental SPO paths (currently $p = 10^{-4}$) > - Effective receive-window autotuning state for typical SPO connections (The report's Rec 5 labels 268 ms as *one-way*, but 268 ms is the *round-trip* figure from the Praos paper — the long-haul one-way delay is 134 ms. §4.2 and this document use 134 ms OWD / 268 ms RTT consistently; the Rec 5 wording is a source-side slip.) The correspondence to what our tracing provides: | Leios-report input | What the report currently uses | What our machinery gives | |---|---|---| | Per-mini-protocol delivery time (§4.3 assumption that tx-submission has pre-diffused) | Assumed | Per-mini-protocol DeltaQ trace bucketing (`track.md` Appendix A shape B — *proposed, not yet implemented; the aggregator is protocol-mixed today*) *would* make tx-submission's actual diffusion latency a first-class observation. Per-protocol *throughput* is separately derivable today from the per-mini-protocol `ChannelTrace` counters | | Steady-state throughput per connection | Mathis vs CUBIC formulae over assumed $p = 10^{-4}$ | `estBurstS` from response bursts — a direct in-band throughput reading, independent of `p` and of which cwnd law is actually running; cross-checked by plain per-protocol throughput counters from `TraceChannelSendStart` / `TraceChannelRecvEnd` | | Loss rate & effective rwnd state (Recommendation 5 items 2 & 3) | Assumed $p = 10^{-4}$; rwnd autotuning state not modelled at all | `TraceTCPInfo` kernel scrape (`tcpi_retrans`, `tcpi_lost`, `tcpi_snd_cwnd`, `tcpi_advmss`, `tcpi_rcv_space`) — direct kernel telemetry; Linux-only, so testnet / design-time only (see Frame 1 subsection below) | | RTT distribution (short / medium / long) | 12 / 69 / 268 ms from Praos paper Table 1 | Empirical per-peer RTT CDF from `PeerRTT.quantile`; per-hop bucketing derivable from peer address | | Cold-start / idle-restart penalty (§5.4 caveats 1–2, not modelled) | — | First-burst RTT vs steady-state RTT is directly observable in the trace stream | | Inter-protocol contention / head-of-line blocking (not modelled) | — | Per-protocol bearer share / fairness, plus (proposed, `track.md` §"blocked on missing traces") egress queue depth and oldest-byte-age per mini-protocol | The two most load-bearing report inputs — the 1-hop pre-diffusion approximation (`report.md:1416-1428`) and the Mathis-vs-CUBIC throughput choice (`report.md:1046-1173`) — are *precisely* the ones our tracing can either falsify or confirm on the real mesh. ## Frame 1 — Paper-model validation The report's headline conclusion — 12 MB `S_EB_tx` is robustly feasible with $P_{\text{cert}} \approx 0.497$ — rests on inputs the report itself flags as unmeasured guesses. Two of these matter most. **Does tx-submission actually pre-diffuse before EB creation?** This is the report's biggest open question. Limitation 1 (§7) calls it out, and the "1-hop approximation" invoked throughout §5 collapses to a full-blended multi-hop worst case if pre-diffusion fails, driving $P_{\text{cert}}$ to zero. Per-mini-protocol DeltaQ traces on tx-submission convert the *tx-gossip pipeline's transport health* from an assumption into a live measurement — per peer, per moment. The outcome side — observed π₁ at EB arrival — is an application-layer signal (EB tx list cross-referenced against the local mempool), not visible at the mux layer; joined to the transport traces (and to the `mempool-measurements` dataset the report already leans on for π₁'s baseline), it gives the full empirical picture of pre-diffusion in practice. **Which throughput formula fits real Cardano paths?** The report reports both Mathis and CUBIC because it doesn't know which is realistic on the SPO mesh. `estBurstS` is a direct measurement of steady-state per-byte cost per peer, independent of both formulae. A histogram of `estBurstS` across peer distances collapses the Mathis-vs-CUBIC band from a modelling uncertainty into an empirical fact. If neither formula fits, that's the more interesting finding. Beyond these, the same machinery quantifies caveats the report lists as unmodelled or admitted guesses: cold-connection / idle-restart penalties (§5.4 caveats 1–2) become directly observable as first-burst RTT vs steady-state RTT; empirical p95 OWD replaces the assumed `long_hop_owd = 134 ms`; per-protocol bearer share surfaces the inter-protocol head-of-line blocking that the report doesn't model at all. And, addressed at length in the subsection below, `TraceTCPInfo` scraping closes the report's loss-rate and rwnd assumptions with direct kernel telemetry. Two signature experiments: - **Controlled bulk-transfer at known RTT/loss.** Two nodes over `tc netem`-shaped links at the report's short/medium/long RTT bins, issue a synthetic 2 MB transfer at each bin, harvest `estBurstS`, compare against the report's per-model predictions (2 MB / long ≈ 4.4 s Mathis, 2.0 s CUBIC). A direct pass/fail on the modelling choice, achievable on an isolated two-node rig. - **Cross-region testnet OWD/S sweep with per-protocol bucketing.** Live nodes across ap/eu/us regions running under representative load, collecting `PeerRTT` quantiles and per-mini-protocol `estBurstS` for a week. Feeds §5.4 sensitivity and Recommendation 5 with real numbers, and — because tx-submission is bucketed separately — makes tx-gossip transport health directly observable. Paired with EB-arrival π₁ measurements at the application layer, this gives the full pre-diffusion picture. For the full campaign shape and how to extend it to investigate blended-diffusion dynamics when 1-hop fails, see [`leios-testnet.md`](leios-testnet.md). ### What testnet-only TCPInfo actually drives Because TCPInfo is Linux-only, its role is *design-time only*: setting static bounds on CIP-0164 parameters and validating the rationale document, not powering any runtime behaviour. It informs three tiers of decision. **CIP-0164 protocol parameters.** `S_EB_tx` (max EB closure size, currently 12 MB, whose feasibility rests on the Mathis-vs-CUBIC choice at 2 MB); `L_vote` (currently 4 s, the tunable component of the 7 s voter deadline); `L_diff` (certRB-diffusion budget, currently 7 s); and the certification-probability target `p_cert` the CIP commits to. All are set by the report's throughput-model-driven feasibility analysis at an assumed `p`. TCPInfo replaces both the model choice and the assumed `p` with measurements, so the resulting parameter values ship with empirical backing rather than defensible guesses. **CIP-0164 rationale-document assumptions.** The `p = 10⁻⁴` default (§4.2 loss-rate convention), the Mathis-vs-CUBIC choice (`report.md:1046-1173`), and §5.4 caveats 1–2 (rwnd lag, idle-restart penalty). These aren't runtime parameters — they're the numbers underpinning the design analysis. TCPInfo settles them empirically: `tcpi_retrans` gives the actual distribution of `p` across connections (likely lower on inter-AWS, higher on consumer uplinks); `tcpi_snd_cwnd` over time picks between Mathis and CUBIC; `min(tcpi_snd_cwnd, tcpi_rcv_space)` shows how often connections are actually rwnd-limited; `tcpi_rto` quantifies the idle-restart caveat. **Node-implementation constants.** The BlockFetch per-peer byte watermarks in `calculatePeerFetchInFlightLimits` are derived from `PeerGSV`; if measured `tcpi_delivery_rate × tcpi_rtt` contradicts them systematically, the constants warrant retuning. (`tcpi_delivery_rate` is not in the current `TCPInfo/Linux.hsc` binding — a small addition when this cross-check is wanted.) Not a spec change — a code change. SPO operational tuning guidance (MSS, IW10, TCP congestion-control choice, rwnd autotuning defaults) is similarly informed downstream. What it doesn't touch: consensus-critical parameters (Praos slot rate, leader-election schedule, the ≈ 0.497 cap), per-transaction CPU costs (from `apply-reapply`), or `π₁` (from `mempool-measurements`). And by construction, none of it can be a runtime-adaptive signal — that role falls to the portable mux-layer signals in Frame 2 below. The frame is *"measure once carefully on a controlled testnet, freeze the parameters into CIP-0164 with empirical backing"* — an artefact of the design phase, not a runtime knob. ## Frame 2 — Adaptive Leios via the reader view The reader view — `PeerRTT` exposed through `ExpandedInitiatorContext` / `ResponderContext` — means the same measurements that validate the report are also *available to running mini-protocols in real time*. That converts what would otherwise be an offline analytical exercise into an online control signal. The category shift: **static-analytical** protocol design fixes network conditions, solves for parameters, freezes them. Once frozen, every voter applies the same deadline regardless of whether the actual mesh currently resembles the assumed one. **Online closed-loop** protocol behavior lets a running voter compare its *observed* p95 RTT against CIP-0164's assumed p95 and act on the gap. RTT alone is only one signal in the composite. A voter's *immediate* "will I make my deadline?" question is better answered by *local outbound queue state* than by far-mesh RTT: the oldest-byte-age of the egress buffer and the queue depth per mini-protocol tell the node whether its own bearer is draining fast enough right now, before any peer signal is involved. These traces are proposed in `track.md`'s "measurements blocked on missing traces" section but don't yet exist — they're a prerequisite for the strongest form of the adaptive-Leios lever. Combined with `PeerRTT` (far-mesh health), the composite gives a voter's decision materially more information than any single signal. ### What runtime-adaptive mux telemetry could drive Mirroring Frame 1's parameter tiers, but for *runtime* decisions rather than design-time bounds. All signals here are portable — mux-layer, no kernel dependency. **Per-voter runtime decisions.** A voter reading `PeerRTT.quantile 0.95` plus local queue state can: - *Refuse to vote* when its own outbound queue's oldest-byte-age already eats into the round budget, or when far-mesh RTT to typical peers is outside the range CIP-0164 was set against. Trades quorum size for quorum quality: better fewer votes that will actually diffuse than many that will fail. - *Adaptively size the closure* at production time — a block producer can voluntarily cap `S_EB_tx` below the CIP-0164 ceiling when observed mesh health won't carry the full size within `L_diff`. - *Drive Freshest-First-Delivery* from a real "am I going to make my deadline" trigger rather than a static threshold. **Peer-selection & churn.** Currently `PeerGSV` is derived from KeepAlive samples at ~10 s cadence. The branch's per-connection matched RTT samples update on every response, spanning all mini-protocols. This lets `PeerGSV` respond seconds faster to degradation, and lets a peer be demoted when its measured RTT drifts significantly from the handshake expectation. BlockFetch's `calculatePeerFetchInFlightLimits` becomes a live control loop rather than a slowly-updated approximation. **Runtime enforcement of Recommendation 3.** The report's Recommendation 3 ("ensure effective tx-submission pre-diffusion") is currently unsatisfiable at design time — pre-diffusion is a runtime property. Per-mini-protocol tx-submission traces observe the *transport health* of the tx gossip pipeline (per-peer RTT, throughput, channel liveness) — a leading indicator of pre-diffusion status, not the outcome itself. The outcome — observed π₁ at EB arrival — is an application- layer signal (EB tx list cross-referenced against the local mempool), not visible at the mux layer. Composed, transport + outcome distinguish qualitatively different failure modes: degraded gossip with rising π₁ is a transient network issue; healthy gossip with high π₁ points at adversarial withholding or a partition, warranting a different response. Either way, the composite lets a node throttle EB production, alert operators, or refuse to vote based on *which* failure mode is in play, rather than failing silently on a single conflated signal. This frame changes what Leios can *do*, as distinct from what the report can *verify*. The specific mechanisms, adversarial-gaming caveats, feedback-loop risks, and governance implications are worked through in [`leios-testnet.md`](leios-testnet.md). **Quantitative target for the adaptive levers.** Yves Hauser's §5.6 extension to the ΔQ report ([`leios-conditional-diffusion.md`](leios-conditional-diffusion.md)) computes $F_{\text{full}\mid C}(14)$ — the conditional probability that all $N$ honest nodes have the EB body by 14 s, given certification succeeded at 7 s — with a closed-form in $G(t)^N$. Because it depends on $G(t)^N$, it's sensitive to the *slowest* nodes, not the mean. This gives two of Frame 2's adaptive levers a concrete analytical target: - *Slowest-node targeting.* Reducing $\max_i T_j^{(i)}$ by 1 s on the slowest 1 % of nodes improves $F_{\text{full}\mid C}$ more than reducing $\mathbb{E}[T_i]$ by 500 ms across the whole mesh. Requires cross-node visibility (which node is slow), but the intervention is per-node (better peers, kernel tuning, operator alerting). *Applicability caveat.* Only pays off when the slowest-node identity is persistent across rounds. Under the rotating or bimodal (churn-induced) regimes discussed in [`leios-conditional-diffusion.md`](leios-conditional-diffusion.md#1-slowest-node-targeting), per-node targeting has no stable target and per-round-adaptive levers (voter self-throttle, adaptive body sizing) apply instead. - *Adaptive body sizing at production time.* Yves's formula depends on body size through $G$; smaller bodies give faster $G$ and higher $F_{\text{full}\mid C}$. A block producer observing degraded mesh health can voluntarily cap $S_{EB\text{-}tx}$ below the CIP-0164 ceiling. The formula quantifies the improvement per 100 kB shave. **Cost caveat.** The RTT/DeltaQ machinery isn't free at production scale — a public relay with hundreds of inbound peers can pay several percent of a core to run it unconditionally, which is exactly why existing Cardano practice keeps DeltaQ strictly on the trace path. Frame 2 needs the machinery deployed in production, but that deployment depends on cost mitigations (statistical sampling, protocol-scoped enablement, probe sampling) rather than the branch's current "unconditional on every connection" default. And a compile-time opt-out remains available for operators who refuse the cost — creating a network bifurcation between Frame-2-capable and vanilla nodes. See [`leios-testnet.md`'s "Production cost of the DeltaQ machinery"](leios-testnet.md#production-cost-of-the-deltaq-machinery) part for the cost breakdown and mitigation options. ## Where the fit is *not* clean To keep the framing honest, three things the branch has nothing to say about: - **π₁** (TxCache miss rate, *steady state*) is a mempool question, not a network one. The report already handles it via the `mempool-measurements` dataset. *Dynamic-stability caveat.* Under sustained-overload conditions where certification is failing, TxCache's dynamic role — necessary but not sufficient to prevent a positive-feedback livelock — is a separate story covered in [`leios-testnet.md`'s "Cascade to livelock"](leios-testnet.md#cascade-to-livelock-bounding-sustained-overload-failure) section. - **CPU-side inputs** (`µ_apply`, `µ_reapply`, Normal-CLT tails) come from `post-cip/apply-reapply`. Orthogonal. - **The Praos-cap ceiling** ($P_{\text{cert}} \approx 0.497$) is a schedule property of the leader election, not a network property. No amount of tracing moves it. ## What to read next - [`leios-testnet.md`](leios-testnet.md) — operational shape of a validation-and-parameter-driving campaign on a real cross-continental testnet. Covers infrastructure, topology choices, the microbench-vs-testnet split, the reader-view expansion, and how to extend the same setup to investigate fully-blended diffusion when 1-hop fails. - [`leios-main-vs-branch.md`](leios-main-vs-branch.md) — what changes if the campaign is run from `main` (with the old `RemoteClockModel` one-way timestamp scheme) instead of this branch. Per-protocol tx-submission diffusion is the single experiment `main` cannot do cleanly without the `MiniProtocolNum` enrichment. - [`leios-conditional-diffusion.md`](leios-conditional-diffusion.md) — how our tracing supports Yves Hauser's §5.6 conditional-CDF analysis ($F_{\text{full}\mid C}$: given certification, does the whole mesh see the EB body by 14 s?). Precise measurement recipe, adaptive levers, and mapping to the report-gaps. --- Net: the natural target is Recommendation 5 as-written — our tracing is the missing SPO-mesh instrumentation the report explicitly names as a follow-up. But the branch also unlocks an adjacent lever — runtime-adaptive protocol behavior — that the report's static-analytical framing doesn't consider at all. Both are worth pursuing, and can share a single testnet campaign.