fix(proto): Use correct info in retransmission of *_BLOCKED frames

[matheus23]

Description

Please merge this after #710

Prior to this change, retransmissions of PATHS_BLOCKED and PATH_CIDS_BLOCKED frames would use "up to date" information for the known maximum remote path ID and CID queue expected next seq number respectively.

This is weird, because these frames are informational and meant for debugging, and either we don't send them when they're not needed anymore (e.g. between originally trying to send them and retransmission the maximum remote path ID increased or the CID queue active seq number increased. In both of these cases we wouldn't actually be blocked anymore.), or we just retransmit them with with the "outdated" values that we sent them with on the first transmit.

This PR decides to go for the latter. This provides the appropriate debugging information to the remote that we were out of path CIDs at some point in time, even if that is now obsolete.

---

Apart from that this PR also fixes the fact that we never actually queued PATHS_BLOCKED frames in the first place...

Breaking Changes

None.

Notes & open questions

Arguably, we should not send any of these frames and I personally hate them, they haven't really helped me at all and only caused problems so far.

The only good reason I can find to keep sending them is that the spec forces the server side to correctly handle them (and produce protocol violations if they're sent incorrectly), and without actually sending them, we would never exercise these code paths and not make sure that said server side checks are correct. (Yes I think that's just unnecessary busywork and wasted bytes/datagrams.)

I've also added a test to check that we transmit & retransmit PATHS_BLOCKED frames. Unfortunately it's quite hard to check that the data that is actually sent is the same PATHS_BLOCKED frame as originally constructed. Instead I did a manual check by looking at the logs. Please trust me bro.

Change checklist

• Self-review.
• Tests if relevant.

[github-actions]

Documentation for this PR has been generated and is available at: https://n0-computer.github.io/noq/pr/716/docs/noq/

Last updated: 2026-06-19T10:01:40Z

[github-actions]

Performance Comparison Report

a3684a654c8d0dec8912120239723fc7860c75ff - artifacts

Raw Benchmarks (localhost)

Scenario	noq	upstream	Delta	CPU (avg/max)
large-single	5268.7 Mbps	7871.5 Mbps	-33.1%	93.9% / 98.2%
medium-concurrent	5310.1 Mbps	7680.7 Mbps	-30.9%	94.7% / 98.6%
medium-single	3806.6 Mbps	4749.1 Mbps	-19.8%	95.6% / 149.0%
small-concurrent	3726.7 Mbps	5239.7 Mbps	-28.9%	91.5% / 99.7%
small-single	3419.2 Mbps	4839.8 Mbps	-29.4%	91.3% / 102.0%

Netsim Benchmarks (network simulation)

Condition	noq	upstream	Delta
ideal	3142.7 Mbps	4050.9 Mbps	-22.4%
lan	782.4 Mbps	810.3 Mbps	-3.4%
lossy	69.8 Mbps	69.9 Mbps	~0%
wan	83.8 Mbps	83.8 Mbps	~0%

Summary

noq is 27.6% slower on average

---

1975de301ce50567b3f6277f19ea8c26ea5d5321 - artifacts

Raw Benchmarks (localhost)

Scenario	noq	upstream	Delta	CPU (avg/max)
large-single	5345.3 Mbps	7814.7 Mbps	-31.6%	96.0% / 97.8%
medium-concurrent	5639.9 Mbps	7728.7 Mbps	-27.0%	96.7% / 98.2%
medium-single	4102.7 Mbps	4749.1 Mbps	-13.6%	95.8% / 98.1%
small-concurrent	3828.3 Mbps	5397.5 Mbps	-29.1%	97.8% / 100.0%
small-single	3525.4 Mbps	4838.7 Mbps	-27.1%	95.7% / 98.0%

Netsim Benchmarks (network simulation)

Condition	noq	upstream	Delta
ideal	3044.7 Mbps	4042.6 Mbps	-24.7%
lan	782.4 Mbps	810.3 Mbps	-3.4%
lossy	69.9 Mbps	69.8 Mbps	~0%
wan	83.8 Mbps	83.8 Mbps	~0%

Summary

noq is 25.6% slower on average