Implement QUIC Delay Control congestion controller

[DXist]

This is an attempt to implement QUIC Delay Control (QUIC-DC) congestion control algorithm.
For initial implementation, I used grok-code-fast-1 model and didn't change anything manually.

I asked Grok to add an example test to compare QUIC-DC with the Cubic congestion controller. The example contains scenarios where

• QUIC client connects directly to QUIC server on localhost.
• QUIC client connects directly to QUIC server via basic UDP proxy to simulate latency and resource constraints of a real network.
• QUIC client connects directly to QUIC server via ECN-capable UDP proxy - this is not implemented, the agent struggled to add the code to configure ECN bits

Client sends ~1MiB of pseudorandom data.

An example output from the test, captured in a virtual machine (Rancher Desktop):

We can see that QUIC-DC maintains a lower average RTT time than Cubic which is beneficial for voice/video data streaming scenarios.

Another measurement running natively on MacBookPro:

Results Table:
| CC     | Proxy | ECN | Delay | Loss | Data Transferred | Loss Ratio | RTT       | Transfer Duration |
|--------|-------|-----|-------|------|------------------|------------|-----------|-------------------|
| cubic  | None  | No  | 0     | 0    | 1048576          | 0.0000     | 0.54ms    | 0.00ms            |
| quicdc | None  | No  | 0     | 0    | 1048576          | 0.0000     | 0.83ms    | 0.00ms            |
| cubic  | Basic | No  | 1     | 0    | 1048576          | 0.0000     | 37.86ms   | 0.00ms            |
| quicdc | Basic | No  | 1     | 0    | 1048576          | 0.0000     | 15.46ms   | 0.00ms            |
| cubic  | ECN   | Yes | 1     | 0    | 1048576          | 0.0000     | 39.95ms   | 0.00ms            |
| quicdc | ECN   | Yes | 1     | 0    | 1048576          | 0.0000     | 12.04ms   | 0.00ms            |

[Ralith]

Please squash commits that correct issues in other commits in the same PR.

For initial implementation, I used grok-code-fast-1 model and didn't change anything manually.

I don't love spending my time reviewing raw LLM output. How carefully did you review this code yourself before submitting the PR?

[DXist]

I don't love spending my time reviewing raw LLM output. How carefully did you review this code yourself before submitting the PR?

I started to dive into the article and added excerpts to the comments on the code. I see that there is a difference in the calculation of one-way queueing delay OWQD. In the article, they use the difference between inter-arrival and inter-departure times of consecutive packets to get the current one-way delay variance.

This variance is then added to the previous estimate of OWQD. The generated code uses a smoothed RTT estimate from RTTEstimator. The QUIC-DC approach should give lower estimates of RTT:

The curves show
that QUIC-DC provides lower RTT values compared to the
other algorithms.

The reason to use OWQD to determine congestion instead of RTT:

A connection is primarily constrained by congestion on the
forward path; therefore, if RTT is used as a congestion signal,
queueing in the backward path caused by reverse traffic may
lead to a false indication of congestion. This, in turn, would
unnecessarily slow down the forward traffic — a behavior
that is indeed observed in TCP Vegas

So the current LLM-generated algorithm should overreact in case of queueing in the backward path for reverse traffic.