leios overlap

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) 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.

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.

Quantitative target for the adaptive levers. Yves Hauser's §5.6 extension to the ΔQ report (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, 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" 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" 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 — 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 — 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 — 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.