FastDDS discovery cache behavior change in ROS 2 when nodes terminate abruptly

Goal: identify FastDDS configuration parameters that minimize the duration of stale participant entries after a node is terminated abruptly without generating excessive multicast traffic.

Constraints include variation across DDS implementations (FastDDS vs CycloneDDS), dependence on network latency, and the trade‑off between rapid dead‑node detection and heartbeat overhead.

Which FastDDS discovery cache parameters control the retention timeout for non‑graceful exits? How does the LivelinessPolicy interact with the cache when a process is killed? What trade‑offs arise when tuning the lease duration on high‑latency links?