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.
141 lines
4.1 KiB
YAML
141 lines
4.1 KiB
YAML
# Mixed Technology: 10-node heterogeneous network
|
|
#
|
|
# Explicit topology with Bluetooth (L2CAP), WiFi, and fiber links.
|
|
# Tests that cost-based parent selection produces a tree favoring
|
|
# low-cost paths when multiple link technologies coexist.
|
|
#
|
|
# Topology:
|
|
#
|
|
# n01 (root)
|
|
# / | \
|
|
# f f f
|
|
# / | \
|
|
# n02 n03 n04
|
|
# | \ | \ | \
|
|
# f BT f f BT f
|
|
# | \ | | \ |
|
|
# n05 n06 n07 n08 n09
|
|
# \ /
|
|
# wifi---wifi
|
|
# n10
|
|
#
|
|
# Edges and link types:
|
|
# Fiber: n01-n02, n01-n03, n01-n04, n02-n05, n03-n07, n04-n09
|
|
# Bluetooth: n02-n06, n04-n08
|
|
# WiFi: n03-n06, n08-n10
|
|
# Fiber: n03-n08, n06-n10
|
|
#
|
|
# Test subjects:
|
|
# - n06 has fiber (n03) and Bluetooth (n02) parents — should pick n03
|
|
# - n08 has fiber (n03) and Bluetooth (n04) parents — should pick n03
|
|
#
|
|
# Netem mutation shifts fiber-only links between normal and degraded.
|
|
#
|
|
# NEITHER TEST SUBJECT IS ASSERTED, because the implementation does not do
|
|
# what the two lines above say. Across the five archived runs that carry a
|
|
# status.txt and are therefore provably completed, n06's parent is n10 in
|
|
# three and n03 in two, and n08's is n04 in four and n03 in one. Encoding
|
|
# either as written would red the scenario most runs; encoding what it
|
|
# actually does would pin behaviour nobody specified and would silently
|
|
# bless it.
|
|
#
|
|
# So this is an open question rather than a missing assertion: either
|
|
# cost-based selection is not preferring fiber here, or the criteria were
|
|
# written for a topology this file no longer has. n06 taking n10 is the
|
|
# more interesting half — n10 reaches n06 by fiber, so the choice may be
|
|
# defensible and the comment simply stale. It needs someone to work out
|
|
# which, and until then this scenario proves nothing about parent choice.
|
|
#
|
|
# That leaves this scenario asserting nothing about its own subject. The
|
|
# baseline block further down holds it to forming a tree and carrying
|
|
# traffic, which is a floor and not a substitute: nothing here checks that
|
|
# the tree it forms is the one these comments describe.
|
|
|
|
scenario:
|
|
name: "mixed-technology"
|
|
seed: 42
|
|
duration_secs: 90
|
|
|
|
topology:
|
|
algorithm: explicit
|
|
num_nodes: 10
|
|
params:
|
|
adjacency:
|
|
- [n01, n02]
|
|
- [n01, n03]
|
|
- [n01, n04]
|
|
- [n02, n05]
|
|
- [n02, n06]
|
|
- [n03, n06]
|
|
- [n03, n07]
|
|
- [n03, n08]
|
|
- [n04, n08]
|
|
- [n04, n09]
|
|
- [n06, n10]
|
|
- [n08, n10]
|
|
subnet: "172.20.0.0/24"
|
|
ip_start: 10
|
|
|
|
netem:
|
|
enabled: true
|
|
default_policy:
|
|
# Fiber-like defaults
|
|
delay_ms: [1, 5]
|
|
jitter_ms: [0, 1]
|
|
loss_pct: [0, 0.5]
|
|
link_policies:
|
|
# Bluetooth (L2CAP) links
|
|
- edges: ["n02-n06", "n04-n08"]
|
|
policy:
|
|
delay_ms: [15, 40]
|
|
jitter_ms: [5, 15]
|
|
loss_pct: [2, 8]
|
|
# WiFi links (moderate latency, low loss)
|
|
- edges: ["n03-n06", "n08-n10"]
|
|
policy:
|
|
delay_ms: [5, 20]
|
|
jitter_ms: [2, 5]
|
|
loss_pct: [1, 3]
|
|
mutation:
|
|
interval_secs: {min: 30, max: 60}
|
|
fraction: 0.2
|
|
policies:
|
|
normal:
|
|
delay_ms: [1, 10]
|
|
loss_pct: [0, 1]
|
|
degraded:
|
|
delay_ms: [50, 100]
|
|
jitter_ms: [10, 30]
|
|
loss_pct: [3, 8]
|
|
|
|
link_flaps:
|
|
enabled: false
|
|
|
|
traffic:
|
|
enabled: true
|
|
max_concurrent: 3
|
|
interval_secs: {min: 10, max: 30}
|
|
duration_secs: {min: 5, max: 15}
|
|
parallel_streams: 4
|
|
|
|
# Baseline: the mesh came up, agreed on a root, and took parents. This
|
|
# asserts nothing about parent choice, which this scenario cannot
|
|
# currently assert; 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.
|
|
#
|
|
# Ten nodes, one root, nine parented and six to eight sessions across
|
|
# the five provably-completed archived runs. The session floor is set
|
|
# below the observed minimum deliberately: it is here to catch a mesh
|
|
# that carries no traffic at all, not to pin a throughput.
|
|
assertions:
|
|
baseline:
|
|
min_nodes_reporting: 10
|
|
max_roots: 1
|
|
min_nodes_parented: 9
|
|
min_sessions: 3
|
|
|
|
logging:
|
|
rust_log: "info"
|
|
output_dir: "./sim-results"
|