UC1 — Rapid Disaster Response

Abstract

A single Earth-Observation satellite captures one high-value image at a known moment and we measure how quickly that file reaches at least one ground station, under varying constellation sizes, file sizes, priorities and (for EDFS) replication factors. Compares the distributed file system EDFS against the legacy store-and-forward baseline TUS.

Success Condition

The run ends successfully the moment the file reaches any ground station.

Detailed description

One designated satellite acts as the producer: on activation its agent writes a single image of size S MB with priority P and exits. Every other satellite in the constellation is idle ("pure relay"). The seven ESTRACK ground stations are fixed and act as receivers. The experiment ends as soon as the first GS reports a RECEIVED event for that file (END_ON_ANY=true on every GS agent).

The producing satellite is positioned far from any ground station at t=0 so the file cannot be downlinked instantly — the time advantage of EDFS comes from peer satellites that happen to be in LOS with both the producer (via ISL) and a GS earlier than the producer itself would.

Each (engine, S, P, sat_count, RF) combination is one run with its own Experiment.spec.runId so dashboards can multi-select across them.

Main goal

Quantify how time-to-first-delivery scales for EDFS vs. TUS as a function of constellation size and file size. The hypothesis is:

• EDFS time-to-first-delivery decreases sub-linearly as sat_count grows (more relay paths → more chances of an earlier hand-off).
• TUS time-to-first-delivery is largely insensitive to sat_count (the file only exists on the producer until it meets a GS).
• High-priority files (UC1 also overlaps with UC3 here) should arrive at least as fast as normal, ideally faster on EDFS.

KPI: time_to_first_GS_delivery — EDFS/TUS ratio < 0.50 at sat_count ≥ 8 (EDFS delivers in at most half the TUS time at the same sat_count and S). Defined on the median over repeated runs per cell; single-run cells are point estimates (run ≥ 3 repeats before declaring met/not-met).

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 (S, sat_count), pin priority=default and omit RF from the run-id. Each (S, sat_count) TUS run is then compared against the full (priority, RF) matrix of EDFS runs at the same (S, sat_count).

Each combination produces one overlay directory plus one Experiment.spec.runId:

• EDFS: uc1-edfs-s<size>-p<priority>-n<NN>-rf<rf> (e.g. uc1-edfs-s128m-pdefault-n08-rf3)
• TUS: uc1-tus-s<size>-n<NN> (e.g. uc1-tus-s128m-n08)

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 the headline yass_file_delivery_seconds_bucket histogram (filtered by source = the producer):

• Per-fsNode and aggregate:
• yass_container_cpu_millicores
• yass_container_memory_bytes
• yass_network_tx_bytes_total, yass_network_rx_bytes_total
• Bandwidth efficiency: bytes_transmitted / file_size. A pure TUS bounce-and-forward should sit close to 1.0; high-RF EDFS will be > 1.
• 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. Used as the proxy for "how much did this engine cost us in total" when comparing EDFS vs TUS.