joule-contrib: a retransmission of a packet not yet seen is recovered; the SRT tests count the first sends lost #510

Merged

dcharlot merged 2 commits from fix/srt-tests-first-send-losses into main 2026-10-27 12:18:43 -04:00

Conversation 0 Commits 2 Files changed 7 +98 -13

dcharlot commented 2026-10-27 07:39:04 -04:00

Owner

Copy link

What

These are two fixes found while chasing an SRT ingest test that failed on #505's linux-arm64 leg (4 recoveries where it required 6).

1. A retransmission of a packet not yet seen is recovered, not a first try (live-contribution §6.1)

A receiver marked a packet as recovered only when a later arrival had shown its gap. Since #503, a sender re-sends its newest packet when its acknowledgements stall (§4.1). That probe arrives before anything shows the gap, so the SRT receiver took it, R flag set, as the next packet in order. It then counted a first try for a packet whose first send was lost. The signed link record came up short on recoveries.

Both receivers now treat an arrival flagged as a retransmission, of a sequence number not yet seen and not known to be missing, as found missing on arrival. It is counted as recovered, with a recovery time of 0 µs. The flag is SRT's R flag or RIST's retransmission SSRC. §6.1's definitions and the CHANGELOG say so.

2. The SRT tests count the first sends that were lost, instead of assuming a burst's size

Both tests drop a run of datagrams by index and required that many recoveries. Control packets (ACKACKs, keepalives) take some of those indexes as the timing falls. The lossy proxy now keeps the datagrams it drops (Counts::dropped_log, protocol-agnostic). The tests read from it the sequence numbers whose first send was lost, and require exactly that many recovered. srt_link also requires a loss run at least as long as the longest run of them.

Evidence (Framework box, x86_64 Linux; four at once pinned to two cores)

Run	Result
losses_each_way_are_recovered_within_the_window	32/32
an_srt_publisher_reaches_a_relay_subscriber_with_every_receipt	32/32
Same ingest test before the receiver fix	0/32: recovered 6–9 against more first sends lost
Falsification: receiver fix disabled	8/8 fail (7 recovered, 9 first sends lost)
Falsification: proxy records nothing	srt_link fails ("the path lost first sends of data: {}")

The job's suites pass:

Suite	Tests
joule-contrib --all-targets	30
joule-contrib --all-targets --features rist	43
joule-moq-ingest --all-targets	73
joule-moq-ingest --all-targets --features rist	75

The link-vector corpus is unchanged (101 files). Clippy reports nothing in the changed files. The comparative-prose, vanity, spec-refs and section-refs checks pass.

🤖 Generated with Claude Code

## What These are two fixes found while chasing an SRT ingest test that failed on #505's linux-arm64 leg (4 recoveries where it required 6). ### 1. A retransmission of a packet not yet seen is recovered, not a first try (live-contribution §6.1) A receiver marked a packet as recovered only when a later arrival had shown its gap. Since #503, a sender re-sends its newest packet when its acknowledgements stall (§4.1). That probe arrives before anything shows the gap, so the SRT receiver took it, R flag set, as the next packet in order. It then counted a first try for a packet whose first send was lost. The signed link record came up short on recoveries. Both receivers now treat an arrival flagged as a retransmission, of a sequence number not yet seen and not known to be missing, as found missing on arrival. It is counted as recovered, with a recovery time of 0 µs. The flag is SRT's R flag or RIST's retransmission SSRC. §6.1's definitions and the CHANGELOG say so. ### 2. The SRT tests count the first sends that were lost, instead of assuming a burst's size Both tests drop a run of datagrams by index and required that many recoveries. Control packets (ACKACKs, keepalives) take some of those indexes as the timing falls. The lossy proxy now keeps the datagrams it drops (`Counts::dropped_log`, protocol-agnostic). The tests read from it the sequence numbers whose first send was lost, and require exactly that many recovered. `srt_link` also requires a loss run at least as long as the longest run of them. ## Evidence (Framework box, x86_64 Linux; four at once pinned to two cores) | Run | Result | |---|---| | `losses_each_way_are_recovered_within_the_window` | 32/32 | | `an_srt_publisher_reaches_a_relay_subscriber_with_every_receipt` | 32/32 | | Same ingest test before the receiver fix | 0/32: recovered 6–9 against more first sends lost | | Falsification: receiver fix disabled | 8/8 fail (7 recovered, 9 first sends lost) | | Falsification: proxy records nothing | `srt_link` fails ("the path lost first sends of data: {}") | The job's suites pass: | Suite | Tests | |---|---| | `joule-contrib --all-targets` | 30 | | `joule-contrib --all-targets --features rist` | 43 | | `joule-moq-ingest --all-targets` | 73 | | `joule-moq-ingest --all-targets --features rist` | 75 | The link-vector corpus is unchanged (101 files). Clippy reports nothing in the changed files. The comparative-prose, vanity, spec-refs and section-refs checks pass. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

dcharlot added 2 commits 2026-10-27 07:39:04 -04:00

SRT tests: count the first sends the proxy dropped, rather than assume a burst's size ... 0a02974ab3

an_srt_publisher_reaches_a_relay_subscriber_with_every_receipt required at
least six recoveries from a burst of six dropped datagrams, and
losses_each_way_are_recovered_within_the_window five from five. A burst
drops datagrams by index, and the control packets between data packets
(ACKACKs, keepalives) take some of those indexes as the timing falls: CI's
linux-arm64 leg saw 4 recoveries on #505 with every payload delivered and
nothing dropped.

The lossy proxy now keeps the datagrams it drops (Counts::dropped_log, the
first 4096), protocol-agnostic. The two tests read from it the sequence
numbers whose first send was lost and require exactly that many recovered,
and srt_link a loss run at least as long as the longest run of them.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

joule-contrib: a retransmission of a packet not yet seen is recovered, not a first try (live-contribution §6.1) ... f441c8b906

A receiver marked a packet recovered only when a later arrival had shown its
gap. A sender's probe of a stalled tail (§4.1) re-sends the newest packet
before anything shows the gap, so the SRT receiver took it, R flag and all,
as the next packet in order and counted a first try for a packet whose first
send was lost. The counted recoveries came up short of the first sends the
path dropped (6-9 short-counted in 32 contended runs of the SRT ingest test).

Both receivers now treat an arrival flagged as a retransmission (SRT's R
flag, RIST's retransmission SSRC) of a sequence number not yet seen and not
known missing as found missing on arrival: recovered, with a recovery of 0
µs. §6.1 says so, and the CHANGELOG.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

dcharlot merged commit 2a6a0a8829 into main 2026-10-27 12:18:43 -04:00

dcharlot referenced this pull request from a commit 2026-10-27 12:18:44 -04:00

Merge pull request 'joule-contrib: a retransmission of a packet not yet seen is recovered; the SRT tests count the first sends lost' (#510) from fix/srt-tests-first-send-losses into main

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

Transaction-Science/open-standards!510

No description provided.