Specification of Christian's Congestion Control Code (C4)

3.1. Nominal rate

The nominal rate is an estimate of the bandwidth available to the flow. On initialization, the nominal rate is set to zero, and default values are used when setting the pacing rate and CWND for the flow.¶

C4 evaluates the nominal rate after acknowledgements are received using the number of bytes acknowledged since the packet was sent (bytes_acknowledged) and the time delay it took to process these packets.¶

That delay is normally set to the difference between the time at which the acknowledged packet was sent (time_sent), and the current time (current_time). However, that difference may sometimes be severely underestimated because of delay jitter and ACK compression. We also compute a "send delay" as the difference between the send time of the acknowledged packet and the send time of the oldest "delivered" packet.¶

delay_estimate = max (current_time - time_sent, send_delay)
rate_estimate = bytes_acknowledged /delay_estimate

If we are not in a congestion situation, we update the nominal rate:¶

if not congested and nominal_rate > rate_estimate:
    nominal_rate = rate_estimate

The data rate measurements can only cause increases in the nominal rate. The nominal rate is reduced following congestion events, as specified in Section 5.¶

The "congested" condition is defined as being in the recovery state and having either entered that state due to a congestion event, or having received a congestion event after entering recovery.¶

Updating the nominal rate in these conditions would cause a congestion bounce: the nominal rate is reduced because of a congestion event, C4 enters recovery, but then packets sent at the previous rate are received during recovery, generating a new estimate and resetting the nominal rate to a value close to the one that caused congestion.¶

3.2. Nominal max RTT

The nominal max RTT is an estimate of the maximum RTT that can occur on the path in the absence of queues. The RTT samples observed for the flow are the sum of four components:¶

• the latency of the path¶

• the jitter introduced by processes like link layer contention or link layer retransmission¶

• queuing delays caused by competing applications¶

• queuing delays introduced by C4 itself.¶

C4's goal is to obtain a estimate of the combination of path latency and maximum jitter. This is done by only taking measurements when C4 is sending data at a rate not higher than the nominal transmission rate, as happens for example in the recovery and cruising states. These measurements will happen during the following era. C4 captures them by recording the max RTT for packets sent in that era. C4 will also progressively reduce the value of the nominal max RTT over time, to account for changes in network conditions.¶

# on end of era

if alpha_previous <= 1.0:
    if era_min_rtt < running_min_rtt:
        running_min_rtt = era_min_rtt
    else:
        running_min_rtt =
           (7*running_min_rtt + era_min_rtt)/8

    if era_max_rtt > running_min_rtt + MAX_JITTER:
        # cap RTT increases to MAX_JITTER, i.e., 250ms
        era_max_rtt = running_min_rtt + MAX_JITTER
    if era_max_rtt > nominal_max_rtt:
        nominal_max_rtt = era_max_rtt
    else:
        nominal_max_rtt =
          (7*nominal_max_rtt + era_max_rtt)/8

The decrease over time is tuned so that jitter events will be remembered for several of the cruising-pushing-recovery cycles, which is enough time for the next jitter event to happen, at least on Wi-Fi networks.¶

3.3. Global variables

In addition to the nominal rate and nominal MAX RTT, C4 maintains a set of variables tracking the evolution of the flow:¶

• running min RTT, an approximation of the min RTT for the flow,¶

• number of eras without increase (see Section 4.2),¶

• current state of the algorithm, which can be Initial, Recovery, Cruising or Pushing.¶

• probe level.¶

The probe level determines how aggressive the pushing phase is, and also how long to wait between recovery and pushing.¶

3.4. Per era variables

C4 keeps variables per era:¶

era_sequence; /* sequence number of first packet sent in this era */
alpha_current; /* coefficient alpha used in the current state */
alpha_previous; /* coefficient alpha used in the previous era */
era_max_rtt; /* max RTT observed during this era */
era_min_rtt; /* min RTT observed during this era */

These variables are initialized at the beginning of the era.¶

4.1. Setting pacing rate, congestion window and quantum

If the nominal rate or the nominal max RTT are not yet assessed, C4 sets pacing rate, congestion window and pacing quantum to initial values:¶

• pacing rate: set to the data rate of the outgoing interface,¶

• congestion window: set to the equivalent of 10 packets,¶

• congestion quantum: set to zero.¶

If the nominal rate or the nominal max RTT are both assessed, C4 sets pacing rate, and congestion window to values that depends on these variables and on a coefficient alpha_current:¶

if (c4_state == initial):
    margin = 0
else:
    margin = min(nominal_max_rtt/4, 15_milliseconds)

pacing_rate = alpha_current * nominal_rate
cwnd = max ((pacing_rate+margin) * nominal_max_rtt, 2*MTU)

The "margin" coefficient accounts for errors on the estimate of the nominal max rtt, which could cause C4 to be stuck operating at a too low data rate. It is only applied outside of the initial phase.¶

The coefficient alpha for the different states is:¶

Setting the pacing quantum is a tradeoff between two requirements. Using a large quantum enables applications to send large batches of packets in a single transaction, which improves performance. But sending large batches of packets creates "instant queues" and causes some Active Queue Management mechanisms to mark packets as ECN/CE, or drop them. As a compromise, we set the quantum to 4 milliseconds worth of transmission, while capping it to 64KB.¶

quantum = max ( min (pacing_rate*4_milliseconds, 64KB), 2*MTU)

4.2. Initial state

When the flow is first initialized, it enters the Initial state, during which it does a first assessment of the "nominal rate" and "nominal max RTT". The coefficient alpha_current is set to 2. The "nominal rate" and "nominal max RTT" are initialized to zero, which will cause pacing rate to be set to a default initial value. The nominal max RTT will be set to the first assessed RTT value, but is not otherwise changed before the end of the initial phase. The CWND will be set to the default initial value, corresponding to 10 packets.¶

During the initial state, the nominal rate is updated after receiving acknowledgements, see Section 3.1. The value of CWND is increased after each acknowledgement by the number of bytes newly acknowledged by this acknowledgement.¶

C4 will exit the Initial state and enter Recovery if the nominal rate does not increase for 3 consecutive eras, omitting the eras for which the transmission was "application limited".¶

C4 exit the Initial when receiving a congestion signal if the following conditions are true:¶

1- If the signal is due to "delay" or "ECN", C4 will only exit the initial state if the nominal_rate did not increase in the last 2 eras.¶

2- If the signal is due to "loss", C4 will only exit the initial state if more than 20 packets have been received.¶

The restriction on delay signals and ECN is meant to prevent spurious exit due to delay jitter or competing connections. The restriction on loss signals is meant to ensure that enough packets have been received to properly assess the loss rate.¶

On exiting the Initial state, C4 computes an estimate of the nominal max RTT as the quotient of the half the last CWND divided by the last nominal rate, and updates the "nominal max RTT" accordingly. The probe level is set to 1.¶

4.3. Recovery state

The recovery state is entered from the Initial or Pushing state, or from the Cruising state in case of congestion. The coefficient alpha_current is set to 15/16. Because the multiplier is lower than 1, the new value of CWND may well be lower than the current number of bytes in transit. C4 will wait until acknowledgements are received and the number of bytes in transit is lower than CWND to send new packets.¶

The Recovery ends when the first packet sent during that state is acknowledged. That means that acknowledgement and congestion signals received during recovery are the consequence of packets sent before. C4 assumes that whatever corrective action is required by these events will be taken prior to entering recovery, and that events arriving during recovery are duplicate of the prior events and can be ignored.¶

Rate increases are detected when acknowledgements received during recovery reflect a successful "push" during the Pushing phase. The prior "Pushing" is considered successful if it did not trigger any congestion event, and if the data rate increases sufficiently between the end of previous Recovery and the end of this one, with sufficiently being defined as:¶

• Any increase if the prior pushing rate (alpha_prior) was 17/16 or less,¶

• An increase of at least 1/4th of the expected increase otherwise, for example an increase of 1/16th if alpha_previous was 5/4.¶

The probe level is updated as follow:¶

• If the prior pushing was successful, and did not trigger an excessive rate of ECN/CE marks, the probe level is increased by 1.¶

• If the prior pushing was successful but did trigger an excessive rate of ECN/CE marks, the probe level remains unchanged.¶

• If the prior pushing was not successful but did not trigger an excessive rate of ECN/CE marks, the probe level left unchanged if it was 0, set to 1 otherwise.¶

• If the prior pushing was not successful and did trigger an excessive rate of ECN/CE marks, the probe level is set to 0.¶

C4 re-enters "Initial" at the end of the recovery period if the probe level as reached a value 4 or larger, or if high jitter requires restarting the Initial phase (see Section 4.3.1. Otherwise, C4 enters cruising.¶

Reception of a congestion signal during the Initial phase does not cause a change in the nominal_rate or nominal_max_RTT.¶

running_min_rtt < nominal_max_rtt*2/5

4.4. Cruising state {#c4-cruising }

The Cruising state is entered from the Recovery state. The coefficient alpha_current is set to 1.¶

C4 will transition from Cruising state to Pushing state after a number of eras that depend on the probe level:¶

• 1 era if the probe level is 0,¶

• 4 eras if the probe level is 1,¶

• 1 era if the probe level is 2 or 3.¶

C4 will transition to Recovery before that if a congestion signal is received before transition to Pushing.¶

4.5. Pushing state

The Pushing state is entered from the Cruising state.¶

The coefficient alpha_current depend on the probe level:¶

• If the probe level is 0, alpha_current is set to 33/32.¶

• If the probe level is 1, alpha_current is set to 17/16.¶

• If the probe level is 2 or higher, alpha_current is set to 5/4.¶

C4 exits the pushing state after one era, or if a congestion signal is received before that. In an exception to standard congestion processing, the reduction in nominal_rate and nominal_max_RTT are not applied if the congestion signal is tied to a packet sent during the Pushing state.¶

5.1. Variable Sensitivity

The three congestion detection thresholds are function of the "sensitivity" coefficient, which increases with the nominal rate of the flow. Flows operating at a low data rate have a low sensitivity coefficient and reacts slower to congestion signals than flows operating at a higher rate. If multiple flows share the same bottleneck, the flows with higher data rate will detect congestion signals and back off faster than flow operating at lower rate. This will drive these flows towards sharing the available resource evenly.¶

The sensitivity coefficient varies from 0 to 1, according to a simple curve:¶

• set sensitivity to 0 if data rate is lower than 50000 B/s¶

• linear interpolation between 0 and 0.92 for values between 50,000 and 1,000,000 B/s.¶

• linear interpolation between 0.92 and 1 for values between 1,000,000 and 10,000,000 B/s.¶

• set sensitivity to 1 if data rate is higher than 10,000,000 B/s¶

The sensitivity index is then used to set the value of delay and loss and CE thresholds.¶

5.2. Detecting Excessive Delays

The delay threshold is function of the nominal max RTT and the sensitivity coefficient:¶

    delay_fraction = 1/16 + (1 - sensitivity)*3/16
    delay_threshold = min(25ms, delay_fraction*nominal_max_rtt)

A delay congestion signal is detected if:¶

    rtt_sample > nominal_max_rtt + delay_threshold

5.3. Detecting Excessive Losses

C4 maintains an average loss rate, updated for every packet as:¶

    if packet_is_lost:
        loss = 1
    else:
        loss = 0
    smoothed_loss_rate = (loss + 15*smoothed_loss_rate)/16

The loss threshold is computed as:¶

    loss_threshold = 0.02 + 0.50 * (1-sensitivity);

A loss is detected if the smoothed loss rate is larger than the threshold. In that case, the coefficient beta is set to 1/4.¶

5.4. Detecting Excessive CE Marks

The way we handle ECN signals is designed to be compatible with L4S [RFC9331]. When the path supports ECN marking, C4 monitors the arrival of ECN/CE and ECN/ECT(1) marks by computing the ratio ecn_alpha. Congestion is detected when that ratio exceeds ecn_threshold, which varies depending on the sensitivity coefficient:¶

ecn_threshold = (2-sensitivity)*3/32

The ratio ecn_alpha is updated each time an acknowledgement is received, as follow:¶

delta_ce = increase in the reported CE marks
delta_ect1 = increase in the reported ECT(1) marks
frac = delta_ce / (delta_ce + delta_ect1)

if frac >= 0.5:
    ecn_alpha = frac
else:
    ecn_alpha += (frac - ecn_alpha)/16

if ecn_alpha > ecn_threshold:
    report congestion

Congestion detection causes C4 to enter recovery. The ration ecn_alpha is set to zero on exit of recovery.¶

5.5. Applying congestion signals

On congestion signal, if C4 was not in recovery state, it will enter recovery.¶

As stated in Section 4.2 and Section 4.5, detecting a congestion in the Initial or Pushing state does not cause a change in the nominal_rate or nominal_max_RTT, because the pacing rate in these states is larger than the nominal_rate. Rate reduction only happens if recovery was entered from the Cruising state.¶

    nominal_rate = (1-beta)*nominal_rate

    beta = min(1/4,
              (rtt_sample - (nominal_max_rtt + delay_threshold)/
               delay_threshold))

    beta = min(1/4, (ecn_alpha - ecn_threshold)/ ecn_threshold)

6.1. Rate measurement should be conservative

The standard algorithm for rate measurement is to consider the amount of data acknowledged in an interval of time, and divide that amount by the duration of the interval. This algorithm can result in over-estimates of the rate in presence of data jitter. These excessive estimates could cause C4 to set a nominal rate higher than the network path bandwidth, resulting in queue build-up and excessive delays.¶

There are two known ways to reduce the effect of jitter: filter out measurements in which the data rate measured through acknowledgements is larger than the send rate; and, make sure that the measurement interval are long enough so jitter only has a small influence. Cautious implementations should use both strategies.¶

6.2. Pacing and CPU load

C4 relies on pacing during to avoid sending data too fast during the recovery, cruising and pushing states. Pacing is often implemented using a "leaky bucket" algorithm, which refills the bucket at the pacing rate, allows transmission as long as there are enough tokens in the bucket, and forces transmission to wait when all tokens are consumed. The wait time is computed based on the pacing rate and the number of desired tokens, and is implemented using operating system commands such as select(), poll(), epoll() or sleep(). In high CPU load conditions, we observe that these commands often return after more than the specified wait time, resulting in a lower sending rate than the desired pacing rate.¶

This phenomenom is particularly visible in low-latency paths. The generic solution would probably be to estimate how much slower the actual pacing is compared to the desired rate, and increase the programmed pacing rate by a value proportional to these measurements. This generic solution is not yet specified. In between, implementations had success with a simple fix: increase the pacing rate 3/64th in "cruising" state when the RTT is less than 1ms. This definitely improved performance in low-latency environment, in particular loopback interfaces.¶

6.3. Nominal max RTT on low latency links

When doing tests on low latency links, we observed on some systems a lot of measurement jitter. The measured RTT is the sum of the actual RTT and some system wakeup delay, which can vary between a few microseconds and maybe 1 millisecond. The default algorithm will adapt the nominal RTT after each roundtrip, which can lead to excessively low values, causing a slowdown of the transmission. A solution is to set a "floor" value to the nominal max RTT, updating it to the maximum of the measured value and the floor. Setting the floor value to 1ms did improve performance.¶

9.1. Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

9.2. Informative References

[RFC9000]

Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/info/rfc9000>.

[I-D.ietf-moq-transport]

Nandakumar, S., Vasiliev, V., Swett, I., and A. Frindell, "Media over QUIC Transport", Work in Progress, Internet-Draft, draft-ietf-moq-transport-16, 13 January 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-moq-transport-16>.

[RFC9331]

De Schepper, K. and B. Briscoe, Ed., "The Explicit Congestion Notification (ECN) Protocol for Low Latency, Low Loss, and Scalable Throughput (L4S)", RFC 9331, DOI 10.17487/RFC9331, January 2023, <https://www.rfc-editor.org/info/rfc9331>.

Changes since draft-huitema-ccwg-c4-spec-00

Rewrote the description of the Initial state in Section 4.2 to remove dependency on nominal max RTT.¶

Added the specification of reaction to ECN in Section 5.4 and in Section 5.5.1. Update section Section 4.5 to modulate pushing rate based on observed rate of ECN/CE marks.¶

Added the RTT margin consideration in Section 4.1, and changed the computation of the "quantum" from:¶

quantum = max ( min (cwnd / 4, 64KB), 2*MTU)

to:¶

quantum = max ( min (pacing_rate*4_milliseconds, 64KB), 2*MTU)

The old formula caused long bursts of packets that would trigger packet drops or ECN/CE marking by active queue management algorithms.¶