UC2 — Continuous LOS Relay

Abstract

Every satellite produces exactly one file at the start of the run. While the constellation is operating, we inject a continuous, randomised stream of hardware faults (network failures, bandwidth reductions, disk full / disk failure) on satellites and ground stations alike. The experiment measures how long it takes for every produced file to reach at least one ground station, and which fraction never makes it inside the time budget. Compares EDFS against TUS.

Success Condition

The run ends successfully once a single ground station holds at least 95% of the produced files. Every satellite produces exactly one file, so the file count x equals sat_count; the generator sets the ground-station receive-only agent to a fixed SUCCESS_AFTER_FILES = floor(0.95·x) − 1 (clamped to ≥ 1) with SUCCESS_BROADCAST=true. The first GS to reach that many distinct files publishes experiment/end-request{SUCCESS}, which the experiment-executor confirms against the authoritative crud-events stream and records as Success.

If max_duration (6h) fires first, the run ends TimedOut and the fraction of files that did arrive is the delivery-success rate — that partial-delivery outcome is itself a data point (see Main goal).

The − 1 margin pulls the effective threshold below 95% at small sat_count (6/8 at n08, 1/2 at n02) and converges to ~95% as the file count grows (94/100, 189/200).

Detailed description

At t=0 every satellite agent writes one file of fixed size and exits — so the number of distinct files in flight is sat_count. The seven ESTRACK ground stations run a multi-receiver agent that keeps logging RECEIVED events for every distinct file it sees and stays alive until the experiment ends.

A per-fsNode hardware-event schedule is generated up front and stamped into each Behaviour.hardwareEvents so the run is fully reproducible (the operator's CRD validation already ensures Destroy is rejected for recurring schedules; we use only the non-terminal fault types). Default fault intensity: on every fsNode, on every fault type, one occurrence every 5m (intervalJitterPercent: 50) lasting 30s-60s (durationJitterPercent: 50). This produces "roughly 10-15% of fsNodes in some kind of fault state at any given moment" — degraded but not crippled.

Fault menu (no Destroy here; that's UC4's domain):

• NetworkBandwidthReduced with capBitsPerSec: 100 kbps
• NetworkFailure (full link drop)
• DiskFull
• DiskFailure

The run ends when (a) all files are received by at least one GS, or (b) the maxDuration (default 6h) timer fires — whichever comes first. The latter case is itself a data point.

Main goal

Quantify delivery completeness and time-to-all-delivered under realistic operational faults. The hypothesis is:

• EDFS achieves ≥ 95% delivery success rate even under the fault stream, because the DHT replicates each file across multiple peers and any of those replicas can be the one that meets a GS.
• TUS degrades faster: a fault on the producer's link during its only contact window with a GS loses that file for the whole run.

KPI: delivery success rate ≥ 95% for EDFS at every sat_count; TUS is expected to fall below.

Parameters

TUS parameter coverage. TUS has no notion of file priority or replication factor — priority and RF are ignored by the engine. For TUS we therefore only sweep (sat_count) (under the same per-run fault schedule), pin priority=default and omit RF. Each TUS run is compared against the full (priority, RF) matrix of EDFS runs at the same sat_count and the same fault seed.

Assumptions

• The inter-ground-station network is broadband and disturbance-free. Every pair of ground stations is treated as permanently linked, independent of orbital line-of-sight: the link is fixed at 10 Gbit/s with zero packet loss, and only its propagation delay scales with the great-circle distance between the two stations. Satellite links, by contrast, exist only while the two nodes are in line-of-sight and their bandwidth degrades with distance. The only event that can disturb a ground-station-to-ground-station link is a hardware failure injected as a HardwareEvent (e.g. NetworkFailure or NetworkBandwidthReduced) on one of the two stations.

Additional metrics

Beyond yass_file_delivery_seconds histogram (filtered to "any-GS delivery"):

• Delivery success rate: count(distinct files received by ≥1 GS) / sat_count.
• "Critical replication time" — wall-clock at which the delivery_success_rate reaches each of {50%, 90%, 95%, 100%}.
• Per-fsNode and aggregate:
• yass_container_cpu_millicores, yass_container_memory_bytes
• yass_network_tx_bytes_total, yass_network_rx_bytes_total
• Fault overlay (for cross-correlation, not a KPI): yass_hardware_event_active{type} from the timeline dashboard so we can see which files happen to be in flight during which fault windows.
• Total network cost: sum(yass_network_tx_bytes_total) aggregated over the whole constellation for the run. Plain bytes shipped — engine- agnostic, no made-up coefficients. Useful for comparing the relative cost of EDFS replication vs. TUS bounce-and-forward under the same fault stream.