--- title: 'SCIONLab Testbed: Global Path-Aware Research' url: https://www.emergentmind.com/topics/scionlab-testbed type: topic --- # SCIONLab Testbed: Global Path-Aware Research SCIONLab Testbed is a deployed research environment for path-aware networking in which SCION Autonomous Systems are organized into multiple Isolation Domains and interconnected by up-, core-, and down-segment links. Recent measurement studies use it both as a global overlay visible at the scale of some 30–40 ASes across five continents and as a controlled experimental substrate for longitudinal observation of path discovery, control-plane churn, path lifetime, forward/reverse asymmetry, and concurrent multipath behavior. In that role, the testbed has become a reference platform for evaluating protocol assumptions behind mechanisms such as Multipath QUIC (MPQUIC), particularly the assumptions of path stability, bidirectional symmetry, and monotonic gains from additional subflows [2509.04695][2509.07154]. ## 1. Topology, scope, and deployment variants SCIONLab is described as a global research overlay comprising dozens of SCION Autonomous Systems organized into multiple Isolation Domains (ISDs) and interconnected by a full-mesh of up-, core-, and down-segment links. At the time of one measurement study, the testbed spanned ASes in at least three distinct ISDs—ISD 19 (central Europe), ISD 17 (Switzerland), and ISD 18 (United States)—with peering at multiple Internet exchange points. The same study notes that the SCIONLab “Figure 1” topology map shows some 30–40 ASes across five continents [2509.04695]. Two recent deployments exemplify different experimental uses of the testbed. One study originated active measurements from three co-located Google Cloud VMs, each hosting a user AS in one of the three target ISDs; the VMs were co-located in `us-central1` to minimize artifacts from heterogeneous IP-transit links and to isolate SCION control- and data-plane behaviors [2509.04695]. Another study deployed four SCIONLab hosts as Google Cloud `e2-medium` instances, each configured as a full SCION AS, with identifiers `1-ff00:0:110` (Europe), `1-ff00:0:120` (North America), `1-ff00:0:130` (Switzerland), and `1-ff00:0:140` (Taiwan). That configuration used one node per major region to maximize path diversity [2509.07154]. The interconnection model in the four-node deployment relied on SCIONLab’s global backbone, with core ASes in Zurich, Munich, Boston, and Singapore. SCION data-plane traffic was carried over the public Internet through IP-in-UDP tunnels, and end-to-end paths traversed 2–5 AS hops depending on the endpoint pair [2509.07154]. Taken together, these deployments indicate that SCIONLab functions simultaneously as a geographically distributed operational substrate and as a controllable measurement target. This suggests that results obtained on the testbed can reflect both intrinsic SCION path dynamics and deployment-dependent artifacts introduced by vantage-point selection. ## 2. Architectural components and forwarding model The control plane in the standard SCIONLab configuration includes beacon servers, path servers, and certificate servers. Beacon servers, one per local core AS, distribute up/down-segments. Path servers cache segments for remote ASes. Certificate servers publish AS certificates and TRCs [2509.07154]. These components define the discoverability and availability of path segments, and therefore directly condition any measurement of path churn or asymmetry. The data plane is implemented through SCION border routers, which handle per-packet MAC checks and forward traffic along the selected path segment. In the four-node study, multipath forwarding was enabled via the `mp-prober` and `mp-bandwidth` scripts, but it ultimately used the same SCION data-plane [2509.07154]. This is operationally significant because any degradation observed under concurrent subflows cannot be separated from the underlying forwarding substrate merely by invoking a multipath tool; the forwarding path still traverses the same border-router logic and the same overlay links. A common misconception is that path-aware forwarding by itself implies stable and symmetric route availability. The measurement evidence does not support that interpretation. The control plane advertises, filters, and caches path segments, while the data plane forwards only on the paths currently exposed to endpoints. As a result, the testbed exhibits path-set volatility and forward/reverse mismatch even when endpoints operate within the same deployed architecture [2509.04695]. ## 3. Measurement workflows and data collection One longitudinal campaign ran for four weeks over the period July 11–August 11, 2025, with analysis focused on the stable window July 16–August 11. Its suite executed every 30 minutes and consisted of `pathdiscover`, `comparer`, `prober`, `mp-prober`, `bw-alldiscover`, and `bw-multipath`. In that pipeline, `pathdiscover` invoked `scion showpaths` to enumerate all end-to-end SCION paths to each remote AS; `comparer` logged “add” and “remove” events by comparing successive path sets; `prober` used `scion ping` over a random sample of up to 15 distinct paths; `mp-prober` issued three concurrent `scion ping` streams over disjoint paths; and `bw-alldiscover / bw-multipath` used `scion-bwtestclient` on up to two simultaneous paths per destination [2509.04695]. A second campaign ran for 28 days with a 30-minute interval between measurement cycles via `cron`. Each cycle included seven enabled measurement types: path discovery with `scion showpaths`, path stability tracking with `comparer`, unipath bandwidth with `scion-bwtestclient` at 10 Mbps, 50 Mbps, and 100 Mbps targets, concurrent bandwidth with `mp-bandwidth`, unipath latency with `scion ping`, concurrent latency with `mp-prober`, and path analysis with `scion traceroute` to obtain per-hop RTT vectors. The per-cycle collection pipeline executed SCION CLI tools in sequence, emitted JSON records containing `timestamp`, `source AS`, `destination AS`, `path fingerprint`, measurement parameters, and raw results, rotated logs into `archives/` and `current/`, and periodically ran `scionpathml convert-json-to-csv` to produce ML-ready tables [2509.07154]. The scale of the four-node campaign is explicitly quantified. With 28 days and 48 cycles per day, it produced 1,344 measurement cycles per AS-pair. With 4 AS nodes, there were 12 distinct ordered AS–AS pairs, yielding approximately 16,128 total path-discovery events [2509.07154]. The three-VM study reports `N=1,281` half-hour intervals for its two primary destinations [2509.04695]. These designs show two complementary methodological choices: geographically distributed measurement to maximize path diversity, and co-located measurement to suppress underlay heterogeneity. A plausible implication is that SCIONLab supports both ecological observation and controlled isolation of specific control-plane effects. ## 4. Formal metrics used to characterize the testbed The studies formalize SCIONLab dynamics through several related metrics. In one formulation, if $P(t)$ is the set of available paths at time $t$, then the path change over an interval $\Delta t$ is $$ \Delta P(t) = |P(t) \,\Delta\, P(t-\Delta t)|, $$ where $\Delta$ denotes symmetric difference, and the instantaneous churn rate is $$ \lambda(t) = \Delta P(t) / \Delta t. $$ Over the whole campaign, the average churn rate is $$ \bar{\lambda} = (1/T) \sum_{i=1}^{N} \frac{|P(t_i) \,\Delta\, P(t_{i-1})|}{t_i - t_{i-1}}. $$ A second operationalization defines the control-plane churn rate as $$ \lambda = (A + R) / T, $$ with $A$ and $R$ the total numbers of path additions and removals over measurement duration $T$ in hours; an AS-pair–specific form is written as $$ \lambda_{A \to B} = E[\#(\text{additions} + \text{removals})] / T_{\text{obs}}. $$ Both papers therefore treat churn as the time-normalized intensity of path-set change, even though one is defined from set differences and the other from logged add/remove events [2509.04695][2509.07154]. Path lifetime is measured per fingerprint. For each distinct path fingerprint $f$, let $L_f$ be the time between first and last observation, with empirical CDF $$ F_L(\tau) = P[L_f \le \tau] = (1/M) \cdot |\{f : L_f \le \tau\}|, $$ where $M$ is the total number of unique fingerprints observed. The related study using comparer logs defines path lifetime $T_i$ for path $i$ as the elapsed time between first appearance and subsequent disappearance, and models survival through $$ Pr\{T > t\} \simeq e^{-\lambda t}. $$ The exponential model is reported to capture the heavy tail of the lifetime distribution over medium time scales [2509.04695][2509.07154]. Forward/reverse asymmetry is also formalized in two ways. One study defines path-set discrepancy through the Jaccard distance $$ \delta(A,B) = 1 - \frac{|P_{A \to B} \cap P_{B \to A}|}{|P_{A \to B} \cup P_{B \to A}|}, $$ where $\delta=0$ denotes perfect symmetry and $\delta=1$ denotes no shared fingerprints. The other defines $$ \Delta(A,B) = |P_{A \to B} \setminus P_{B \to A}| + |P_{B \to A} \setminus P_{A \to B}|. $$ These are distinct but related measures of directional mismatch: $\delta$ normalizes overlap by union size, while $\Delta$ counts non-overlapping elements directly [2509.04695][2509.07154]. For performance, the single-path metrics are measured bandwidth $\phi_i$ and RTT $d_i$, while for two concurrent subflows on paths $i,j$ the throughput and latency are expressed as $$ \phi_{i+j} = \phi_i + \phi_j - I_{i,j}, $$ where $I_{i,j}$ captures interference, and $$ d_{i+j} = \max(d_i,d_j) + \sigma_{i,j}, $$ where $\sigma_{i,j}$ denotes added jitter due to resource contention. The other study reports aggregate throughput as $R_{\text{total}} = \sum_{i=1}^{n} R_i$ and packet delivery ratio as $$ PDR = (\#\text{packets received}) / (\#\text{packets sent}). $$ These definitions jointly frame SCIONLab as a testbed in which path availability and path quality are both stochastic objects subject to direct measurement [2509.04695][2509.07154]. ## 5. Empirical path diversity, lifetime, and asymmetry Across the four-node deployment, the aggregated path statistics indicate moderate diversity and nontrivial instability. The reported average number of distinct paths per ordered AS-pair is 3.4. The median path lifetime is approximately 8 hours, the 90th percentile lifetime is approximately 24 hours, and the average churn rate is 0.12 changes per hour, interpreted as roughly one change every 8 hours. The median forward/reverse Jaccard distance is 0.28, corresponding to approximately 72% path-set overlap between forward and reverse directions [2509.07154]. | Metric | Value | Context | |---|---:|---| | Avg. distinct paths per pair | 3.4 | Moderate path diversity | | Median path lifetime | $\approx 8$ hours | Half of paths persist beyond 8 h | | 90th percentile lifetime | $\approx 24$ hours | Most stable paths last at least 1 day | | Avg. churn rate | 0.12 changes/hour | Approximately 1 change every 8 h | | Median Jaccard distance $\delta$ | 0.28 | Approximately 72% forward/reverse overlap | The path-discrepancy phenomenon is characterized more explicitly in the same study. The distribution of $\delta$ across pairs is described as roughly Gaussian around 0.3 with $\sigma \approx 0.1$, and higher discrepancy correlates with higher churn: pairs with $\delta > 0.4$ exhibit $\bar{\lambda} \approx 0.2$ changes per hour. The interpretation given is that endpoints must independently discover and monitor both directions to ensure correct multipath operation [2509.07154]. The three-VM study reports substantially higher event-based churn for two primary destinations. For destination `17-ffaa:1:11e4`, it observed `A=557` additions and `R=577` removals over `T=640.5 h`, giving $\lambda \approx 1.75$ events per hour and empirical average path lifetime $\bar{T}=15.7$ h. For destination `18-ffaa:1:11e5`, it observed `A=1,254` and `R=1,259`, giving $\lambda \approx 3.92$ events per hour and mean lifetime $\bar{T}=8.6$ h. Figure 4’s histogram is reported to show that nearly 80% of all paths lasted less than 100,000 s, approximately 27 h, and the exponential model is said to capture the heavy tail of the lifetime distribution [2509.04695]. Directional asymmetry is also directly observed in path counts. In one sample, AS-3 saw 20 distinct SCION paths to AS-2, while AS-2 saw only 18 towards AS-3, yielding $\Delta=4$. Across the measurement suite, asymmetric path counts appeared in roughly 15% of all 30-minute intervals, persisted for hours at a time, and were attributed to per-AS path filtering policies in SCION’s control plane rather than transient failures; no one-to-one correlation was observed with external topology events such as underlay link flaps [2509.04695]. This result directly contradicts the common assumption that path-aware routing should expose the same path opportunities in both directions. ## 6. Multipath contention, throughput aggregation, and protocol consequences The testbed measurements show a consistent throughput–latency trade-off under concurrent subflows. In the four-node study, mean single-path throughput was 54 Mbps with mean RTT 42 ms, loss 0.6%, and jitter 2.1 ms. Under two-path concurrent transmission, mean throughput increased to 98 Mbps, while mean RTT increased to 48 ms, loss to 0.8%, and jitter to 3.7 ms. The same study reports an aggregate throughput versus latency curve for 1 to 3 concurrent subflows, with diminishing returns after 2 subflows [2509.07154]. A separate study examined `mp-prober` with `n=3` subflows, each pinned to a different control-plane–discovered path. Under single-path conditions, a path typically yielded median RTT approximately 410 ms, jitter approximately 5 ms, and packet loss approximately 0.5%. Under multipath conditions, each constituent subflow experienced median $\Delta RTT \approx +12$ ms, $\Delta j \approx +2$ ms, and additional packet loss $\Delta p_{\text{loss}} \approx +0.2\%$. At the same time, the combined throughput $R_{\text{total}}$ consistently exceeded the fastest single-path rate by 20–30%. The latency penalty was summarized empirically as $$ \Delta RTT(n) \approx \alpha \cdot (n-1), \qquad \alpha \simeq 6 \text{ ms/subflow}, $$ which captures the roughly linear increase in latency with added subflows [2509.04695]. Both studies attribute the performance degradation to contention effects rather than to a failure of path discovery. One reports that $I_{i,j}$, the cross-path interference term, is typically less than 10% of $\phi_i+\phi_j$ when RTT differences are less than 10 ms, and recommends per-path congestion windows with occasional resequencing buffers if $\sigma_{i,j}>5$ ms [2509.07154]. The other suggests shared queuing points either at the VM’s NIC or within common SCIONLab overlay links as the likely source of the observed RTT, jitter, and loss inflation [2509.04695]. The convergence of these observations indicates that multipath benefits on SCIONLab are real but not free: bandwidth aggregation is accompanied by measurable per-path quality degradation. These measurements lead to concrete protocol recommendations for MPQUIC and related multipath transports. One study recommends tuning subflow lifetime to the median path lifetime with `idle_timeout ≈ L_{50} / 2 ≈ 4 h`, triggering proactive path rediscovery at approximately $\bar{\lambda}^{-1} \approx 8$ h, probing chosen subflows every 30 minutes for latency and loss, limiting concurrent subflows to `M=2`, adapting congestion windows independently per path, and monitoring forward/reverse discrepancy with re-pairing if $\delta>0.5` [2509.07154]. The other recommends probing intervals at most $\tau_{\text{probe}} \le \bar{T}/3$—approximately 3 h for unstable links—retiring paths after no successful probe within $\tau_{\text{retire}} \approx 1$ h, exchanging explicit path lists in the handshake, avoiding reverse-path–dependent frames on asymmetric routes, assigning latency-critical streams to the single lowest-latency path, and dynamically selecting $k