fix(proto): Properly clear retransmits of PATHS_BLOCKED and PATH_CIDS_BLOCKED

[matheus23]

Description

Clears the retransmits of said packets when we get "unblocked". I.e. previously this could happen:

1. Client side runs out of max path ID or path CIDs
2. Client schedules PATHS_BLOCKED or PATH_CIDS_BLOCKED
3. These packets get lost
4. Client meanwhile receives MAX_PATH_ID or PATH_NEW_CONNECTION_ID frames, which unblocks the client
5. Client will eventually detect the loss and retransmits PATHS_BLOCKED or PATH_CIDS_BLOCKED, even though it's unblocked.

This PR makes sure that on step 4 above, the client will clear the retransmits of PATHS_BLOCKED or PATH_CIDS_BLOCKED to ensure that step 5 doesn't happen (even if it's not necessarily "dangerous" for these frames to be received by the server).

Breaking Changes

None.

Notes & open questions

One could argue that we shouldn't do this "retransmits surgery", but we already do so in Connection::abandon_path.
This exact argument is exactly why this is draft: I'm investigating how this interacts with our loss detection, but arguably it was working for us so far (... right? right? 👀).

Change checklist

• Self-review.
• Documentation updates following the style guide, if relevant.
• Tests if relevant.
• All breaking changes documented.

[github-actions]

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

Last updated: 2026-06-18T10:26:25Z

[github-actions]

Performance Comparison Report

cbb45a7ab8931d65e3392b0db4660e112d041a54 - artifacts

Raw Benchmarks (localhost)

Scenario	noq	upstream	Delta	CPU (avg/max)
large-single	5308.4 Mbps	7935.3 Mbps	-33.1%	93.3% / 98.2%
medium-concurrent	5448.1 Mbps	7809.6 Mbps	-30.2%	94.1% / 101.0%
medium-single	3662.2 Mbps	4493.2 Mbps	-18.5%	93.8% / 102.0%
small-concurrent	3765.0 Mbps	5137.3 Mbps	-26.7%	98.2% / 157.0%
small-single	3503.1 Mbps	4573.5 Mbps	-23.4%	98.1% / 155.0%

Netsim Benchmarks (network simulation)

Condition	noq	upstream	Delta
ideal	3094.3 Mbps	4047.3 Mbps	-23.5%
lan	782.5 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 26.4% slower on average

[flub]

fwiw, I'm still dubious of this approach compared to retransmitting the exact same frames. I don't think this is worth digging through all the sent_packets, it is very expensive.

It also is kind of informative even if by now it is no longer blocked. The receiver will still know that at some point the peer was blocked by that seq.

[matheus23]

Not following this approach.
These are debugging-only frames. With #716 we instead send retransmit them with the original values. This ensures they arrive "as a debugging tool", potentially giving information about being blocked at some point in time.