fix(bbr3): bbr3 controller was not accounting correctly

[Arqu]

Description

Ensure the congestion controller is notified for per-packet send which BBR requires. on_sent does not carry the per packet info it needs.

BBR controller bench now goes form 1.3 to 55 MiB/s on my setup and matches quinn and s2n.

Breaking Changes

Notes & open questions

Change checklist

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

[github-actions]

Performance Comparison Report

dfc592ab98091ca2e473e70ce1862d73c76fd06b - artifacts

No results available

---

0e4782adaae2d2187c3604960c4456c9d2616071 - artifacts

Raw Benchmarks (localhost)

Scenario	noq	upstream	Delta	CPU (avg/max)
large-single	5401.3 Mbps	7949.8 Mbps	-32.1%	95.9% / 100.0%
medium-concurrent	5501.6 Mbps	7966.5 Mbps	-30.9%	95.6% / 147.0%
medium-single	3907.2 Mbps	4734.5 Mbps	-17.5%	89.1% / 97.2%
small-concurrent	3816.0 Mbps	5114.0 Mbps	-25.4%	92.8% / 101.0%
small-single	3522.3 Mbps	4811.2 Mbps	-26.8%	95.7% / 153.0%

Netsim Benchmarks (network simulation)

Condition	noq	upstream	Delta
ideal	3095.9 Mbps	4064.4 Mbps	-23.8%
lan	782.4 Mbps	810.4 Mbps	-3.5%
lossy	69.8 Mbps	55.9 Mbps	+25.0%
wan	83.8 Mbps	83.8 Mbps	~0%

Summary

noq is 26.4% slower on average

[github-actions]

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

Last updated: 2026-05-15T15:18:33Z

[flub]

Have you looked if the upstream PR has fixed this yet? Ideally we keep tracking upstream for now, while we haven't started working on this in earnest yet.

[Arqu]

The upstream quinn works fine, however we have slight drift from it. They use a Controller trait and override on_sent for BBR with their custom bw math

The noq implementation has drifted apart a little and has a separate hook for on_packet_sent which BBR was built around but never wired through. Ref

So whether we want to re-align with upstream is another question but in the meantime this is missing wiring which popped up while working on some other benchmarking.

Also we're fairly close to quinn main as it is right now, the above code has not changed in ~5 months so its us that deliberately drifted apart but haven't wired it in.

[flub]

Giving some more context to my question. In #611 we imported BBR3 in it's than-current state because we wanted to get the API-breaking changes in before noq 1.0. But we were aware that the upstream work was not yet finished.

My intention was that as long as we haven't started our independent work on BBR3 we would be able to keep pulling in changes from upstream that happened after that PR. And if possible I'd like to limit the changes to just that until that upstream PR is merged. I'm a bit worried about starting to make our own changes before than, unless we really plan starting to work on BBR3, but as far as I understand that's still probably a few months out.

So I would prefer at this stage to keep the changes to BBR3 to only be mechanical updates ported from the upstream branch. And if that bug is still present after doing so, then maybe we could suggest the change there before importing it into here.

[flub]

Checking the Controller trait it seems like we are still in sync? That is ultimately the most important thing for now. I'm not sure why you say the their and our trait drifted apart, did I miss something?