We sometimes increase the congestion window by 2*mss going against RFC 9002
We sometimes increase twice: https://github.com/mozilla/neqo/blob/ea3f7a521f9971cb43ceb099d81b802d96ae939b/neqo-transport/src/cc/classic_cc.rs#L256-L264
RFC 9002 only permits one increase:
A sender in congestion avoidance uses an Additive Increase Multiplicative Decrease (AIMD) approach that MUST limit the increase to the congestion window to at most one maximum datagram size for each congestion window that is acknowledged.
(https://datatracker.ietf.org/doc/html/rfc9002#section-7.3.3-2)
See https://github.com/mozilla/neqo/pull/2535#discussion_r2281629718 for context.
I'm not sure if it is actually a problem going against the RFC here, or if it even applies, since were doing CUBIC, so I'd be happy to hear opinions.
Obviously our code has worked for the past ~4 years, so I'm not sure if introducing change here for the sake of following the spec would be worth the risk.
Note that we are increasing twice per ACK, while the RFC restricts increasing once per congestion window.
(Not to say that we should change it.)
For future reference, it might make sense to look at the way we set the congestion window in general, too (only increasing in max_datagram_size blocks, calculating the acked bytes needed instead of just returning the target, ... ). See https://github.com/mozilla/neqo/pull/2535#discussion_r2183246465 for some context.