CUBIC update to RFC 9438 tracking issue

[omansfeld]

As suggested by @larseggert the big PR #2535 is becoming unwieldy so I'm splitting it into multiple smaller ones and tracking them here.

I'm trying to keep the PRs as independent as possible so they can be landed one-by-one. That means that there will likely be some merge conflicts between them though, because they sometimes have to touch the same things -- I will address those as they emerge.

My plan for PRs is as follows:

• refactor(transport/cc): streamline test value setters/getters #2968
  • all others will depend on this one
• feat(transport/cubic): multiplicative decrease updates #2970
• cubic: reno region updates #2973
  • feat(transport/cubic): simplify byte tracking across acks #3043 has been split out to further de-risk and land later
• feat(transport/cubic): cubic region RFC9438 updates #2983
  • refactor(transport/cubic): only convert max_datagram_size_f64 once #2994
  • refactor(transport/cubic): use saturating_duration_since for t #2997
• feature(transport/cubic): dynamic changing of alpha value #2985 will also be tackled later

I'll update this issue description as we go along.

Update 2025-10-15: Everything merged and leftovers are tracked in #3053. I will close this issue.

[larseggert]

Before we start reviewing/merging PRs that change behavior, I'd like to discuss better (CI) testing for CC, and getting that merged first.

This isn't (only) about making sure we have good LoC coverage, but making sure we have test cases that validate correct behavior in CC edge cases.

We probably need quite a few of these tests, so implementing them all in straight up Rust is going to be very wordy. Wondering if we can extend the simulator so one can feed it a test case with a script (think something like packetdrill) and have it execute that.

[omansfeld]

Before we start reviewing/merging PRs that change behavior, I'd like to discuss better (CI) testing for CC, and getting that merged first.

This isn't (only) about making sure we have good LoC coverage, but making sure we have test cases that validate correct behavior in CC edge cases.

We probably need quite a few of these tests, so implementing them all in straight up Rust is going to be very wordy. Wondering if we can extend the simulator so one can feed it a test case with a script (think something like packetdrill) and have it execute that.

I agree it would be good to have confidence in our CI around CC and methods to properly evaluate CC -- for the upcoming work on Slow Start (#2858) , too.

Extending the simulator with e.g. packetdrill does sound like a new project-size effort to me though (packetdrill doesn't support quic for example, so would also need to be extended), so I'm wondering what the best way forward is.

We also do have quite a few CC tests (bottom of classic_cc.rs and in neqo-transport/src/cc/tests/cubic.rs), so could you give some edge cases you're missing as an example?

[larseggert]

Extending the simulator with e.g. packetdrill

I didn't mean to integrate some other tool here. I was thinking supporting the scripting of test cases in a language similar to https://github.com/larseggert/qvalve.

[omansfeld]

Extending the simulator with e.g. packetdrill

I didn't mean to integrate some other tool here. I was thinking supporting the scripting of test cases in a language similar to larseggert/qvalve.

Ah, gotcha, misunderstood your previous comment. I created #2986 to continue discussions.

I think blocking CUBIC on this makes sense. And we had already talked about doing similar things for #2858, so might as well land CUBIC when we have more insights and confidence in it through more tests and so forth.

The split up PRs are now all up and (theoretically) ready for review. Splitting it took a bit longer then expected, but I guess that's a learning for next time not to let it get to this point.

So this is probably a good milestone to pause work on CUBIC and start on #2986 and then #2858.