mirror of
https://github.com/jmcorgan/fips.git
synced 2026-07-30 19:46:15 +00:00
Johnathan Corgan
e9ca741e53
Four scenarios exist to test cost-based parent selection and each named its expected outcome in a comment that nothing read. Add a tree_parents assertion mapping a node to the parent it must have in the final tree snapshot, and encode it for the two scenarios whose stated outcome the implementation meets: cost-avoidance (n04 takes the fiber n03) and bottleneck-parent (n06 takes the fiber n03, n09 keeps its only parent n05). Both hold in all six provably-completed archived runs. The other two are left unasserted on purpose, and each for a different reason worth keeping distinct. mixed-technology says n06 and n08 should both pick the fiber parent n03. They do not. Across the five completed archived runs n06 picks n10 three times and n08 picks n04 four times. Encoding the criterion as written would red the scenario most runs, and encoding the observed behaviour would bless something nobody specified, so the disagreement is recorded at the site as an open question. n06 preferring n10 may well be correct and the comment stale, since n10 reaches it by fiber too. depth-vs-cost is different: its validation line does not name an outcome at all, saying only that the choice "reflects the actual cost tradeoff", which either answer satisfies. The corpus shows both occurring under one seed, three runs to two. That scenario needs a protocol decision about which parent is correct before it can have an assertion. Compare parents by address resolved from the snapshot's own my_node_addr, and fail rather than skip when a node is absent from the snapshot or still claims to be its own root. Those two states are the common ones in the older corpus and both produce the same "no match" a wrong parent does, so only separating them keeps a harness problem from reading as a routing verdict.
89 lines
2.5 KiB
YAML
89 lines
2.5 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
|
|
|
|
logging:
|
|
rust_log: "info"
|
|
output_dir: "./sim-results"
|