Are there known conditions where MsQUIC would exhibit the CUBIC CWND pattern?

[Hex27]

I've been messing around with a rickety virtual environment between some Ubuntu machines for a project, and I've found it quite difficult to get a cubic CWND pattern out from the API's network statistics connection parameter - most of my attempts look something like a weird sawtooth:

In the same environment, the TCP implementation in Ubuntu 20.04 does exhibit the cubic pattern as I was hoping to trigger:

In conditions without loss, MsQUIC's CWND behaves as expected:

Granted, its possible that the dirt in my test environment is causing something weird to happen, I'm simulating congestion with traffic control's red in Ubuntu and the nodes themselves use a wild mix of virtual and physical interfaces.

Given all that:

1. Is it normal for MsQUIC's Congestion Window to respond to congestion events like a sawtooth? If it's not, are there situations where it would do that?
2. When exactly does MsQUIC treat a lost packet as spuriously lost? Do spuriously lost packets contribute to any congestion events?
3. Under what sort of conditions can I observe the cubic graph from MsQUIC's congestion window?

[nibanks]

Yes, we do get Cubic curves with MsQuic, but cubic curves can take a long time (10+ seconds sometimes), which might be why you don't see it in your traces. It could also be a result of a fairly small buffer in the middle, resulting in loss much faster.

Spurious loss is generally only from random reordering.

[Hex27]

Oh, I do indeed have a small virtual queue for the simulated congestion.

Why would it lead to a linear pattern? Does it have something to do with the "Reno-Friendly region"?

[nibanks]

The smaller the queue, the faster it fills up, the faster you get loss. The Cubic curve is the region where Cubic slowly sends more and more, until it gets loss. It usually takes minutes of slow ramp up to see the curve. But if your queue is so small that it has loss almost instantly. then no curve.

[Hex27]

Just for general information for anyone reading in the future, yes, the lack of the cubic curve was indeed caused by the short queue used to simulate congestion.

Based on what I can see, that's because the TCP-Friendly region was being run, and that causes a sawtooth pattern that looked like this:

After commenting that branch out and recompiling msquic, the cubic pattern does come out:

To be clear, that's probably not anything wrong with msquic, my test environment is not pristine and the application queuing the QUIC traffic is a basement experiment that was not rigorously built for benchmarking flow, it was just a brew of weird circumstances for the AIMD window to be larger than the Cubic window.