Correct RSSI monitor busy and liveness timing

[bengineerd]

Description

Fix RSSI monitor liveness and local-BUSY ACK timing.

RssiMonitor previously treated received ACK-only and BUSY-only traffic as server liveness, which allowed control traffic to reset the server null-timeout counter even when the peer was no longer sending DATA or NULL keepalive segments. It also stopped the ACK timeout counter when no new receive sequence number was pending, which prevented a receiver that remained locally busy from periodically advertising BUSY after the first busy ACK was sent.

This changes the server null-timeout refresh condition to DATA or NULL receipt only, and lets local BUSY drive periodic ACK requests at Retransmission Timeout/2 when there is no newly pending receive sequence number to acknowledge.

Details

This fix is necessary because RSSI liveness is meant to prove that the peer is still sending sequenced DATA/NULL traffic. ACK-only or BUSY-only control traffic can show that something is still responding, but it should not keep the server-side null-timeout detector alive indefinitely. Likewise, BUSY flow control relies on repeated BUSY advertisement so the peer transmitter does not advance into retransmit/close behavior while the receiver remains busy.

This behavior is called out in the SLAC RSSI protocol page:

• In the Null Timeout section, the server closes the connection if no DATA or NULL segments arrive within the negotiated Null Timeout.
• In the BUSY flow-control section, a busy receiver should either put BUSY on outgoing data or periodically send ACK segments with BUSY set, with Retransmission Timeout/2 as the recommended period.

This has usually worked until now because common deployments do not sit for long periods in ACK/BUSY-only traffic with no DATA or NULL keepalive, and local BUSY is often transient. A rising local-BUSY edge already generated an immediate ACK, so short backpressure events were covered. The missing behavior shows up in directed tests that keep the receiver busy after that first ACK or continue sending control-only traffic while DATA/NULL liveness is absent.

The Rogue RSSI controller already follows this split in ~/rogue/src/rogue/protocols/rssi/Controller.cpp:

• received ACKs release transmit-buffer entries, and received BUSY only updates the remote-busy state;
• DATA or NULL in the expected sequence is what advances the receive sequence and is queued toward the application path, with NULL later dropped at the application boundary;
• in open state, Rogue sends an ACK frame when an ACK is pending or local busy persists past the cumulative-ACK timeout, and transportTx() marks that outgoing ACK busy while preserving the last acknowledged receive sequence when the local endpoint is busy.

So this PR changes the RTL monitor to match the Rogue implementation and the SLAC RSSI protocol intent: ACK/BUSY-only control traffic does not count as DATA/NULL liveness, and persistent local BUSY is periodically re-advertised.

Validation:

./.venv/bin/vsg -c vsg-linter.yml -f protocols/rssi/v1/rtl/RssiMonitor.vhd protocols/rssi/v1/wrappers/RssiMonitorWrapper.vhd
./.venv/bin/python -B -m pytest -q -p no:cacheprovider tests/protocols/rssi/test_RssiMonitor.py
1 passed
./.venv/bin/python -B -m pytest -q -p no:cacheprovider tests/protocols/rssi
3 passed, 20 skipped

Related

Stacked on #1453.