mirror of
https://github.com/jmcorgan/fips.git
synced 2026-07-30 19:46:15 +00:00
Johnathan Corgan
5d3a3d7cad
Five scenarios named by the audit carried no assertions at all, so a run in which the mesh never formed exited 0 and reported green. Add a baseline assertion covering how many nodes answered, how many distinct roots they agreed on, how many took a parent, and optionally how many sessions were established, and apply it to those five plus the two cost scenarios left unasserted by the previous commit. For ethernet-only, ethernet-mesh, tcp-mesh, smoke-10, mixed-technology and depth-vs-cost the values are not calibrated: one root and N-1 parented nodes is what a spanning tree is, and all provably-completed archived runs of each show exactly that. churn-mixed is different and says so at the site. A scenario that stops and starts nodes on purpose does not hold a single tree, and its six completed runs end with two or three roots and seven or eight of ten nodes parented, so its floors sit one step outside the observed range. That leaves them catching a mesh that collapsed rather than one that churned, which is the most a sample of six supports. This gives Ethernet transport its only assertion anywhere in CI. The three tests in src/node/tests/ethernet.rs are ignored for requiring CAP_NET_RAW and neither runner passes --ignored, so until now nothing exercised that transport with a verdict attached. The floor is deliberately weak and deliberately not a substitute: it says the mesh formed, not that it formed the tree the scenario describes. Where those differ the scenario now says so in its own comments.
104 lines
3.1 KiB
YAML
104 lines
3.1 KiB
YAML
# Cost-Based Parent Selection: Deeper Fiber Beats Shallow Bluetooth
|
|
#
|
|
# Topology (explicit 4-node):
|
|
#
|
|
# n01 (root)
|
|
# / \
|
|
# fiber BT
|
|
# / \
|
|
# n02 n04 (test subject)
|
|
# | /
|
|
# fiber fiber
|
|
# | /
|
|
# n03
|
|
#
|
|
# n04 has two candidate parents:
|
|
# - n01 (root, depth 0) via Bluetooth L2CAP: effective_depth = 0 + ~1.4 = ~1.4
|
|
# - n03 (depth 2) via fiber: effective_depth = 2 + ~1.01 = ~3.01
|
|
#
|
|
# Without cost-based selection, n04 would pick n01 (depth 0 < depth 2).
|
|
# With cost-based selection and these Bluetooth impairments, n04 may
|
|
# still pick n01 since the Bluetooth cost (~1.4) is modest. This tests
|
|
# that the cost formula correctly weighs depth against link quality.
|
|
#
|
|
# Validation: tree snapshot shows n04's parent selection reflects the
|
|
# actual cost tradeoff between depth and link quality.
|
|
#
|
|
# NO PARENT IS ASSERTED HERE, and unlike the other cost scenarios that is
|
|
# not because the implementation disagrees with the comment. It is because
|
|
# the validation line above does not name an outcome: "reflects the actual
|
|
# cost tradeoff" is satisfied by either answer, so there is nothing to
|
|
# encode. The comment above even says n04 "may still pick n01".
|
|
#
|
|
# The corpus agrees that both answers occur. Across the five provably
|
|
# completed archived runs, n04's parent is n01 in three and n03 in two,
|
|
# with the same seed each time, so the choice is not deterministic under
|
|
# this configuration.
|
|
#
|
|
# Pinning whichever answer is more common would convert an unspecified
|
|
# behaviour into a regression guard for something nobody decided, and
|
|
# would go red roughly two runs in five besides. What this scenario needs
|
|
# first is a decision about which parent is correct given the stated
|
|
# effective depths, and that is a protocol question, not a harness one.
|
|
|
|
scenario:
|
|
name: "depth-vs-cost"
|
|
seed: 42
|
|
duration_secs: 45
|
|
|
|
topology:
|
|
algorithm: explicit
|
|
num_nodes: 4
|
|
params:
|
|
adjacency:
|
|
- [n01, n02]
|
|
- [n02, n03]
|
|
- [n03, n04]
|
|
- [n01, n04]
|
|
subnet: "172.20.0.0/24"
|
|
ip_start: 10
|
|
|
|
netem:
|
|
enabled: true
|
|
default_policy:
|
|
# Fiber-like
|
|
delay_ms: [1, 5]
|
|
jitter_ms: [0, 1]
|
|
loss_pct: [0, 0.5]
|
|
link_policies:
|
|
# Bluetooth (L2CAP) link from n01 to n04
|
|
- edges: ["n01-n04"]
|
|
policy:
|
|
delay_ms: [15, 40]
|
|
jitter_ms: [5, 15]
|
|
loss_pct: [2, 8]
|
|
|
|
link_flaps:
|
|
enabled: false
|
|
|
|
traffic:
|
|
enabled: true
|
|
max_concurrent: 1
|
|
interval_secs: {min: 15, max: 30}
|
|
duration_secs: {min: 5, max: 10}
|
|
parallel_streams: 2
|
|
|
|
# Baseline: the mesh came up, agreed on a root, and took parents. This
|
|
# asserts nothing about which parent n04 chooses, which is unspecified;
|
|
# it exists so that a run in which the mesh never formed cannot report
|
|
# success, which until now it could,
|
|
# because this scenario carried no assertions at all.
|
|
#
|
|
# Four nodes, one root, three parented and four sessions in all five
|
|
# provably-completed archived runs.
|
|
assertions:
|
|
baseline:
|
|
min_nodes_reporting: 4
|
|
max_roots: 1
|
|
min_nodes_parented: 3
|
|
min_sessions: 2
|
|
|
|
logging:
|
|
rust_log: "info"
|
|
output_dir: "./sim-results"
|