diff --git a/doc/c4-design.md b/doc/c4-design.md index 74280c9..c850e7b 100644 --- a/doc/c4-design.md +++ b/doc/c4-design.md @@ -410,9 +410,17 @@ delay component ever higher -- and eventually resulting in To avoid that, we can have periodic periods in which the endpoint sends data at deliberately slower than the -rate estimate. This enables us to get a "clean" measurement +rate estimate. This would enable a "clean" measurement of the Max RTT. +However, tests showed that only measuring +the Max RTT during recovery periods is not reactive enough. +For example, if the underlying RTT changes, we would need to wait +up to 6 RTT before registering the change. In practice, we can +measure the Max RTT in both the "recovery" and "cruising" +periods, i.e., all the periods in which data is sent at most +at the "nominal data rate". + If we are dealing with jitter, the clean Max RTT measurements will include whatever jitter was happening at the time of the measurement. It is not sufficient to measure the Max RTT once, @@ -437,10 +445,12 @@ packets sent during the recovery period. * if `max_rtt_sample` is larger than `nominal_max_rtt`, set `nominal_max_rtt` to that value. * else, set `nominal_max_rtt` to: + ~~~ nominal_max_rtt = gamma*max_rtt_sample + (1-gamma)*nominal_max_rtt ~~~ + The `gamma` coefficient is set to `1/8` in our initial trials. ### Preventing Runaway Max RTT @@ -552,7 +562,7 @@ that happened as follow: continue to be acknowledged during recovery. * if enough packets are acknowledged, they will cause a rate measurement close to the previous nominal rate. -* if C4 accepts this new nomnal rate, the flow will +* if C4 accepts this new nominal rate, the flow will bounce back to the previous transmission rate, erasing the effects of the congestion signal. @@ -694,7 +704,7 @@ state. On entering recovery, C4 reduces the `nominal_rate` by a factor "beta": ~~~ - // on congestion detected: + # on congestion detected: nominal_rate = (1-beta)*nominal_rate ~~~ The cofficient `beta` differs depending on the nature of the congestion @@ -752,7 +762,7 @@ and only lasts for one round trip. That limited increase is not expected to increase the size of queues by more than a small fraction of the bandwidth\*delay product. It might cause a slight increase of the measured RTT for a short period, or -perhaps cause some ECN signalling, but it should not cause packet +perhaps cause some ECN signaling, but it should not cause packet losses -- unless competing connections have caused large queues. If there was no extra capacity available, C4 does not increase the nominal CWND and @@ -827,7 +837,7 @@ connection was saturating the path, any additional traffic did cause queuing or losses, and the second connection had no chance to grow. -This "second comer shut down" effect happend particularly often +This "second comer shut down" effect happened particularly often on high jitter links. The established connections had tuned their timers or congestion window to account for the high jitter. The second connection was basing their timers on their first @@ -903,9 +913,9 @@ and pushing will only result in slow increases increases, maybe 6.25% after 6 RT This means we would only double the bandwidth after about 68 RTT, or increase from 10 to 65 Mbps after 185 RTT -- by which time the LEO station might have connected to a different orbiting satellite. To go faster, we implement -a "cascade": if the previous pushing at 6.25% was successful, the next +a "cascade": if the previous pushes at 6.25% was successful, the next pushing will use 25% (see {{variable-pushing}}), or an intermediate -value if the observed ratio of ECN marks is greater than 0. If three successive pushings +value if the observed ratio of ECN marks is greater than 0. If three successive pushes all result in increases of the nominal rate, C4 will reenter the "startup" mode, during which each RTT can result in a 100% increase of rate and CWND. @@ -1010,9 +1020,9 @@ increasing the send rate by 25% does not always result in a 25% increase of the acknowledged rate. Delay jitter, for example, may result in lower measurement. We initially computed the threshold for detecting "significant" increase as 1/2 of the increase in -the sending rate, but multiple simulation shows that was too high and +the sending rate, but multiple simulation shows that was too high and caused lower performance. We now set that threshold to 1/4 of the -increase in he sending rate. +increase in the sending rate. ## Pushing rate and Cascades @@ -1026,7 +1036,7 @@ at a high rate increases the chance of building queues, overfilling the buffers, causing losses, and thus causing Cubic to back off. Pushing at a lower rate like 6.25% would not have that effect, and C4 would keep using a lower share of the network. This is why we will always -push at 25% in the "pig war" mode. +pushed at 25% in the "pig war" mode. The computation of the interval between pushes is tied to the need to compete nicely, and follows the general idea that diff --git a/doc/c4-design.txt b/doc/c4-design.txt index 0440ae4..ae0ed0c 100644 --- a/doc/c4-design.txt +++ b/doc/c4-design.txt @@ -5,9 +5,9 @@ Network Working Group C. Huitema Internet-Draft Private Octopus Inc. Intended status: Informational S. Nandakumar -Expires: 22 April 2026 C. Jennings +Expires: 5 June 2026 C. Jennings Cisco - 19 October 2025 + 2 December 2025 Design of Christian's Congestion Control Code (C4) @@ -43,7 +43,7 @@ Status of This Memo time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 22 April 2026. + This Internet-Draft will expire on 5 June 2026. Copyright Notice @@ -53,9 +53,9 @@ Copyright Notice -Huitema, et al. Expires 22 April 2026 [Page 1] +Huitema, et al. Expires 5 June 2026 [Page 1] -Internet-Draft C4 Design October 2025 +Internet-Draft C4 Design December 2025 This document is subject to BCP 78 and the IETF Trust's Legal @@ -79,39 +79,39 @@ Table of Contents 3.2. Monitoring the nominal max RTT . . . . . . . . . . . . . 8 3.2.1. Preventing Runaway Max RTT . . . . . . . . . . . . . 9 3.2.2. Initial Phase and Max RTT . . . . . . . . . . . . . . 10 - 3.3. Monitoring the nominal rate . . . . . . . . . . . . . . . 10 + 3.3. Monitoring the nominal rate . . . . . . . . . . . . . . . 11 3.3.1. Rate measurement . . . . . . . . . . . . . . . . . . 11 - 3.3.2. Avoiding Congestion Bounce . . . . . . . . . . . . . 11 + 3.3.2. Avoiding Congestion Bounce . . . . . . . . . . . . . 12 3.3.3. Not filtering the measurements . . . . . . . . . . . 12 - 4. Competition with other algorithms . . . . . . . . . . . . . . 13 - 4.1. No need for slowdowns . . . . . . . . . . . . . . . . . . 13 - 5. React quickly to changing network conditions . . . . . . . . 13 - 5.1. Do not react to Probe Time Out . . . . . . . . . . . . . 14 - 5.2. Update the Nominal Rate after Pushing . . . . . . . . . . 15 - 6. Driving for fairness . . . . . . . . . . . . . . . . . . . . 15 - 6.1. Absence of constraints is unfair . . . . . . . . . . . . 16 - 6.2. Introducing a sensitivity curve . . . . . . . . . . . . . 17 - 6.3. Cascade of Increases . . . . . . . . . . . . . . . . . . 18 - 7. Supporting Application Limited Connections . . . . . . . . . 18 - 7.1. Coordinated Pushing . . . . . . . . . . . . . . . . . . . 19 - 7.2. Variable Pushing Rate . . . . . . . . . . . . . . . . . . 19 - 7.3. Pushing rate and Cascades . . . . . . . . . . . . . . . . 20 - 8. State Machine . . . . . . . . . . . . . . . . . . . . . . . . 21 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 - 11. Informative References . . . . . . . . . . . . . . . . . . . 22 - Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 24 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 + 3.4. Early Congestion Modification . . . . . . . . . . . . . . 13 + 4. Competition with other algorithms . . . . . . . . . . . . . . 14 + 4.1. No need for slowdowns . . . . . . . . . . . . . . . . . . 14 + 5. React quickly to changing network conditions . . . . . . . . 14 + 5.1. Do not react to Probe Time Out . . . . . . . . . . . . . 15 + 5.2. Update the Nominal Rate after Pushing . . . . . . . . . . 16 + 6. Driving for fairness . . . . . . . . . . . . . . . . . . . . 16 + 6.1. Absence of constraints is unfair . . . . . . . . . . . . 17 + 6.2. Introducing a sensitivity curve . . . . . . . . . . . . . 18 + 6.3. Cascade of Increases . . . . . . . . . . . . . . . . . . 19 + 7. Supporting Application Limited Connections . . . . . . . . . 19 + 7.1. Coordinated Pushing . . . . . . . . . . . . . . . . . . . 20 + 7.2. Variable Pushing Rate . . . . . . . . . . . . . . . . . . 21 + 7.3. Pushing rate and Cascades . . . . . . . . . . . . . . . . 22 + 8. State Machine . . . . . . . . . . . . . . . . . . . . . . . . 22 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 + 11. Informative References . . . . . . . . . . . . . . . . . . . 24 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 26 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 - -Huitema, et al. Expires 22 April 2026 [Page 2] +Huitema, et al. Expires 5 June 2026 [Page 2] -Internet-Draft C4 Design October 2025 +Internet-Draft C4 Design December 2025 1. Introduction @@ -165,9 +165,9 @@ Internet-Draft C4 Design October 2025 -Huitema, et al. Expires 22 April 2026 [Page 3] +Huitema, et al. Expires 5 June 2026 [Page 3] -Internet-Draft C4 Design October 2025 +Internet-Draft C4 Design December 2025 2. Studying the reaction to delays @@ -221,9 +221,9 @@ Internet-Draft C4 Design October 2025 -Huitema, et al. Expires 22 April 2026 [Page 4] +Huitema, et al. Expires 5 June 2026 [Page 4] -Internet-Draft C4 Design October 2025 +Internet-Draft C4 Design December 2025 In our initial deployments, we detected competition when delay based @@ -277,9 +277,9 @@ Internet-Draft C4 Design October 2025 -Huitema, et al. Expires 22 April 2026 [Page 5] +Huitema, et al. Expires 5 June 2026 [Page 5] -Internet-Draft C4 Design October 2025 +Internet-Draft C4 Design December 2025 2.2. Handling Chaotic Delays @@ -333,9 +333,9 @@ Internet-Draft C4 Design October 2025 -Huitema, et al. Expires 22 April 2026 [Page 6] +Huitema, et al. Expires 5 June 2026 [Page 6] -Internet-Draft C4 Design October 2025 +Internet-Draft C4 Design December 2025 Using the pacing rate that way prevents the larger window to cause @@ -389,9 +389,9 @@ Internet-Draft C4 Design October 2025 -Huitema, et al. Expires 22 April 2026 [Page 7] +Huitema, et al. Expires 5 June 2026 [Page 7] -Internet-Draft C4 Design October 2025 +Internet-Draft C4 Design December 2025 3. Simplifying the initial design @@ -445,14 +445,21 @@ Internet-Draft C4 Design October 2025 -Huitema, et al. Expires 22 April 2026 [Page 8] +Huitema, et al. Expires 5 June 2026 [Page 8] -Internet-Draft C4 Design October 2025 +Internet-Draft C4 Design December 2025 To avoid that, we can have periodic periods in which the endpoint - sends data at deliberately slower than the rate estimate. This - enables us to get a "clean" measurement of the Max RTT. + sends data at deliberately slower than the rate estimate. This would + enable a "clean" measurement of the Max RTT. + + However, tests showed that only measuring the Max RTT during recovery + periods is not reactive enough. For example, if the underlying RTT + changes, we would need to wait up to 6 RTT before registering the + change. In practice, we can measure the Max RTT in both the + "recovery" and "cruising" periods, i.e., all the periods in which + data is sent at most at the "nominal data rate". If we are dealing with jitter, the clean Max RTT measurements will include whatever jitter was happening at the time of the measurement. @@ -479,15 +486,26 @@ Internet-Draft C4 Design October 2025 * if max_rtt_sample is larger than nominal_max_rtt, set nominal_max_rtt to that value. - * else, set nominal_max_rtt to: ~~~ nominal_max_rtt = - gamma_max_rtt_sample + (1-gamma)_nominal_max_rtt ~~~ The gamma - coefficient is set to 1/8 in our initial trials. + * else, set nominal_max_rtt to: + + nominal_max_rtt = gamma*max_rtt_sample + + (1-gamma)*nominal_max_rtt + + The gamma coefficient is set to 1/8 in our initial trials. 3.2.1. Preventing Runaway Max RTT Computing Max RTT the way we do bears the risk of "run away increase" of Max RTT: + + + +Huitema, et al. Expires 5 June 2026 [Page 9] + +Internet-Draft C4 Design December 2025 + + * C4 notices high jitter, increases Nominal Max RTT accordingly, set CWND to the product of the increased Nominal Max RTT and Nominal Rate @@ -499,13 +517,6 @@ Internet-Draft C4 Design October 2025 because of the queue, interprets that as "more jitter", increases Max RTT and fills the queue some more. - - -Huitema, et al. Expires 22 April 2026 [Page 9] - -Internet-Draft C4 Design October 2025 - - * Repeat until the queue become so large that packets are dropped and cause a congestion event. @@ -541,6 +552,16 @@ Internet-Draft C4 Design October 2025 Empirically, we detect high jitter in that case if the "running min RTT" is less that 2/5th of the "nominal max RTT". + + + + + +Huitema, et al. Expires 5 June 2026 [Page 10] + +Internet-Draft C4 Design December 2025 + + 3.3. Monitoring the nominal rate The nominal rate is measured on each acknowledgement by dividing the @@ -554,14 +575,6 @@ Internet-Draft C4 Design October 2025 is a deliberate choice, as decreases in measurement are ambiguous. They can result from the application being rate limited, or from measurement noises. Following those causes random decrease over - - - -Huitema, et al. Expires 22 April 2026 [Page 10] - -Internet-Draft C4 Design October 2025 - - time, which can be detrimental for rate limited applications. If the network conditions have changed, the rate will be reduced if congestion signals are received, as explained in Section 5. @@ -596,6 +609,15 @@ Internet-Draft C4 Design October 2025 This is in line with the specification of rate measurement in [I-D.ietf-ccwg-bbr]. + + + + +Huitema, et al. Expires 5 June 2026 [Page 11] + +Internet-Draft C4 Design December 2025 + + We use the data rate measurement to update the nominal rate, but only if not congested (see Section 3.3.2) @@ -607,24 +629,16 @@ Internet-Draft C4 Design October 2025 In our early experiments, we observed a "congestion bounce" that happened as follow: - * congestion is detected, the nomnal rate is reduced, and C4 enters + * congestion is detected, the nominal rate is reduced, and C4 enters recovery. - - - -Huitema, et al. Expires 22 April 2026 [Page 11] - -Internet-Draft C4 Design October 2025 - - * packets sent at the data rate that caused the congestion continue to be acknowledged during recovery. * if enough packets are acknowledged, they will cause a rate measurement close to the previous nominal rate. - * if C4 accepts this new nomnal rate, the flow will bounce back to + * if C4 accepts this new nominal rate, the flow will bounce back to the previous transmission rate, erasing the effects of the congestion signal. @@ -640,7 +654,7 @@ Internet-Draft C4 Design October 2025 3.3.3. Not filtering the measurements There is some noise in the measurements of the data rate, and we - protect against that noise by retaining the maximum of the ack__delay + protect against that noise by retaining the maximum of the ack_delay and the send_delay. During early experiments, we considered smoothing the measurements for eliminating that noise. @@ -652,6 +666,14 @@ Internet-Draft C4 Design October 2025 Instead of trying to average the data rates, we can average their inverse, i.e., the quotients of the delay by the bytes received, the times per byte. Then we can obtain smoothed data rates as the + + + +Huitema, et al. Expires 5 June 2026 [Page 12] + +Internet-Draft C4 Design December 2025 + + inverse of these times per byte, effectively computing an harmonic average of measurements over time. We could for example compute an exponentially weighted moving average of the time per byte, and use @@ -665,13 +687,47 @@ Internet-Draft C4 Design October 2025 operation, and does not cause the response delays that filtering would. +3.4. Early Congestion Modification + + We want C4 to handle Early Congestion Notification in a manner + compatible with the L4S design. For that, we monitor the evolving + ratio of CE marks that the L4S specification designates as alpha (we + use ecn_alpha here to avoid confusion), and we detect congestion if + the ratio grows over a threshold. + + We did not find a recommended algorithm for computing ecn_alpha in + either [RFC9330] or [RFC9331], but we could get some concrete + suggestions in [I-D.briscoe-iccrg-prague-congestion-control]. That + draft, now obsolete, suggests updating the ratio once per RTT, as the + exponential weighted average of the fraction of CE marks per packet: + + frac = nb_CE / (nb_CE + nb_ECT1) + ecn_alpha += (frac - ecn_alpha)/16 + + This kind of averaging introduces a reaction delay. The draft + suggests mitigating that delay by preempting the averaging if the + fraction is large: + + if frac > 0.5: + ecn_alpha = frac + + We followed that design, but decided to update the coefficient after + each acknowledgement, instead of after each RTT. This is in line + with our implementation of "delayed acknowledgements" in QUIC, which + results in a small number of acknowledgements per RTT. + + The reaction of C4 to an excess of CE marks is similar to the + reaction to excess delays or to packet losses, see Section 5. + + -Huitema, et al. Expires 22 April 2026 [Page 12] + +Huitema, et al. Expires 5 June 2026 [Page 13] -Internet-Draft C4 Design October 2025 +Internet-Draft C4 Design December 2025 4. Competition with other algorithms @@ -725,9 +781,9 @@ Internet-Draft C4 Design October 2025 -Huitema, et al. Expires 22 April 2026 [Page 13] +Huitema, et al. Expires 5 June 2026 [Page 14] -Internet-Draft C4 Design October 2025 +Internet-Draft C4 Design December 2025 1. Excessive increase of measured RTT (above the nominal Max RTT), @@ -740,7 +796,7 @@ Internet-Draft C4 Design October 2025 If any of these signals is detected, C4 enters a "recovery" state. On entering recovery, C4 reduces the nominal_rate by a factor "beta": - // on congestion detected: + # on congestion detected: nominal_rate = (1-beta)*nominal_rate The cofficient beta differs depending on the nature of the congestion @@ -781,9 +837,9 @@ Internet-Draft C4 Design October 2025 -Huitema, et al. Expires 22 April 2026 [Page 14] +Huitema, et al. Expires 5 June 2026 [Page 15] -Internet-Draft C4 Design October 2025 +Internet-Draft C4 Design December 2025 and only react to those losses that are detected by gaps in @@ -804,7 +860,7 @@ Internet-Draft C4 Design October 2025 expected to increase the size of queues by more than a small fraction of the bandwidth*delay product. It might cause a slight increase of the measured RTT for a short period, or perhaps cause some ECN - signalling, but it should not cause packet losses -- unless competing + signaling, but it should not cause packet losses -- unless competing connections have caused large queues. If there was no extra capacity available, C4 does not increase the nominal CWND and the connection continues with the previous value. @@ -837,9 +893,9 @@ Internet-Draft C4 Design October 2025 -Huitema, et al. Expires 22 April 2026 [Page 15] +Huitema, et al. Expires 5 June 2026 [Page 16] -Internet-Draft C4 Design October 2025 +Internet-Draft C4 Design December 2025 proportional to its size. This drives very good long term fairness, @@ -886,16 +942,16 @@ Internet-Draft C4 Design October 2025 connection was saturating the path, any additional traffic did cause queuing or losses, and the second connection had no chance to grow. - This "second comer shut down" effect happend particularly often on + This "second comer shut down" effect happened particularly often on high jitter links. The established connections had tuned their timers or congestion window to account for the high jitter. The second connection was basing their timers on their first -Huitema, et al. Expires 22 April 2026 [Page 16] +Huitema, et al. Expires 5 June 2026 [Page 17] -Internet-Draft C4 Design October 2025 +Internet-Draft C4 Design December 2025 measurements, before any of the big jitter events had occured. This @@ -934,25 +990,31 @@ Internet-Draft C4 Design October 2025 loss_threshold = 0.02 + 0.50 * (1-sensitivity); + For the CE mark threshold, the rule is: + + loss_threshold = 1/32 + 1/32 * (1-sensitivity); + This very simple change allowed us to stabilize the results. In our competition tests we see sharing of resource almost equitably between C4 connections, and reasonably between C4 and Cubic or C4 and BBR. We do not observe the shutdown effects that we saw before. - There is no doubt that the current curve will have to be refined. We - have a couple of such tests in our test suite with total capacity - higher than 20Mbps, and for those tests the dependency on initial - conditions remain. We will revisit the definition of the curve, - probably to have the sensitivity follow the logarithm of data rate. -Huitema, et al. Expires 22 April 2026 [Page 17] + +Huitema, et al. Expires 5 June 2026 [Page 18] -Internet-Draft C4 Design October 2025 +Internet-Draft C4 Design December 2025 + + There is no doubt that the current curve will have to be refined. We + have a couple of such tests in our test suite with total capacity + higher than 20Mbps, and for those tests the dependency on initial + conditions remain. We will revisit the definition of the curve, + probably to have the sensitivity follow the logarithm of data rate. 6.3. Cascade of Increases @@ -970,11 +1032,12 @@ Internet-Draft C4 Design October 2025 the bandwidth after about 68 RTT, or increase from 10 to 65 Mbps after 185 RTT -- by which time the LEO station might have connected to a different orbiting satellite. To go faster, we implement a - "cascade": if the previous pushing at 6.25% was successful, the next - pushing will use 25% (see Section 7.2). If three successive pushings - all result in increases of the nominal rate, C4 will reenter the - "startup" mode, during which each RTT can result in a 100% increase - of rate and CWND. + "cascade": if the previous pushes at 6.25% was successful, the next + pushing will use 25% (see Section 7.2), or an intermediate value if + the observed ratio of ECN marks is greater than 0. If three + successive pushes all result in increases of the nominal rate, C4 + will reenter the "startup" mode, during which each RTT can result in + a 100% increase of rate and CWND. 7. Supporting Application Limited Connections @@ -996,20 +1059,18 @@ Internet-Draft C4 Design October 2025 reducing the nominal values in reaction to congestion notifications much reduces that risk. - The second feature is the "make before break" nature of the rate - updates discussed in Section 5.2. This reduces the risk of using - rates that are too large and would cause queues or losses, and thus - makes C4 a good choice for multimedia applications. - - - -Huitema, et al. Expires 22 April 2026 [Page 18] +Huitema, et al. Expires 5 June 2026 [Page 19] -Internet-Draft C4 Design October 2025 +Internet-Draft C4 Design December 2025 + The second feature is the "make before break" nature of the rate + updates discussed in Section 5.2. This reduces the risk of using + rates that are too large and would cause queues or losses, and thus + makes C4 a good choice for multimedia applications. + C4 adds two more features to handle multimedia applications well: coordinated pushing (see Section 7.1), and variable pushing rate (see Section 7.2). @@ -1047,6 +1108,20 @@ Internet-Draft C4 Design October 2025 data, and will only enter the the pushing state when the last period was not application limited. + + + + + + + + + +Huitema, et al. Expires 5 June 2026 [Page 20] + +Internet-Draft C4 Design December 2025 + + 7.2. Variable Pushing Rate C4 tests for available bandwidth at regular pushing intervals (see @@ -1058,14 +1133,6 @@ Internet-Draft C4 Design October 2025 other hand, not pushing at all would not be a good option, because the connection could end up stuck using only a fraction of the available capacity. We thus have to find a compromise between - - - -Huitema, et al. Expires 22 April 2026 [Page 19] - -Internet-Draft C4 Design October 2025 - - operating at low capacity and risking building queues. We manage that compromise by adopting a variable pushing rate: @@ -1077,6 +1144,12 @@ Internet-Draft C4 Design October 2025 CWIN, the next pushing will happen at 25%, otherwise it will remain at 6.25% + If the observed ratio of ECN-CE marks is greater than zero, we will + use it to modulate the amount of pushing. We leave the pushing rate + at 6.25% if the previous pushing attempt was not successful, but + otherwise we pick a value intermediate between 25% (if 0 ECN marks) + and 6.25% (if the ratio of ECN marks approaches the threshold). + As explained in Section 6.3, if three consecutive pushing attempts result in significant increases, C4 detects that the underlying network conditions have changed, and will reenter the startup state. @@ -1087,23 +1160,8 @@ Internet-Draft C4 Design October 2025 jitter, for example, may result in lower measurement. We initially computed the threshold for detecting "significant" increase as 1/2 of the increase in the sending rate, but multiple simulation shows that - was too high and and caused lower performance. We now set that - threshold to 1/4 of the increase in he sending rate. - -7.3. Pushing rate and Cascades - - The choice of a 25% push rate was motivated by discussions of BBR - design. Pushing has two parallel functions: discover the available - capacity, if any; and also, push back against other connections in - case of competition. Consider for example competition with Cubic. - The Cubic connection will only back off if it observes packet losses, - which typically happen when the bottleneck buffers are full. Pushing - at a high rate increases the chance of building queues, overfilling - the buffers, causing losses, and thus causing Cubic to back off. - Pushing at a lower rate like 6.25% would not have that effect, and C4 - would keep using a lower share of the network. This is why we will - always push at 25% in the "pig war" mode. - + was too high and caused lower performance. We now set that threshold + to 1/4 of the increase in the sending rate. @@ -1115,12 +1173,24 @@ Internet-Draft C4 Design October 2025 +Huitema, et al. Expires 5 June 2026 [Page 21] + +Internet-Draft C4 Design December 2025 -Huitema, et al. Expires 22 April 2026 [Page 20] - -Internet-Draft C4 Design October 2025 +7.3. Pushing rate and Cascades + The choice of a 25% push rate was motivated by discussions of BBR + design. Pushing has two parallel functions: discover the available + capacity, if any; and also, push back against other connections in + case of competition. Consider for example competition with Cubic. + The Cubic connection will only back off if it observes packet losses, + which typically happen when the bottleneck buffers are full. Pushing + at a high rate increases the chance of building queues, overfilling + the buffers, causing losses, and thus causing Cubic to back off. + Pushing at a lower rate like 6.25% would not have that effect, and C4 + would keep using a lower share of the network. This is why we will + always pushed at 25% in the "pig war" mode. The computation of the interval between pushes is tied to the need to compete nicely, and follows the general idea that the average growth @@ -1151,6 +1221,19 @@ Internet-Draft C4 Design October 2025 have resulted in increases of "nominal rate", or enters "cruising" otherwise. + + + + + + + + +Huitema, et al. Expires 5 June 2026 [Page 22] + +Internet-Draft C4 Design December 2025 + + * "cruising": the connection is sending using the "nominal_rate" and "nominal_max_rtt" value. If congestion is detected, the connection exits cruising and enters "recovery" after lowering the @@ -1165,19 +1248,6 @@ Internet-Draft C4 Design October 2025 These transitions are summarized in the following state diagram. - - - - - - - - -Huitema, et al. Expires 22 April 2026 [Page 21] - -Internet-Draft C4 Design October 2025 - - Start | v @@ -1209,6 +1279,17 @@ Internet-Draft C4 Design October 2025 | | +<------------------+ + + + + + + +Huitema, et al. Expires 5 June 2026 [Page 23] + +Internet-Draft C4 Design December 2025 + + 9. Security Considerations We do not believe that C4 introduce new security issues. Or maybe @@ -1227,19 +1308,12 @@ Internet-Draft C4 Design October 2025 DOI 10.17487/RFC9000, May 2021, . - - -Huitema, et al. Expires 22 April 2026 [Page 22] - -Internet-Draft C4 Design October 2025 - - [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-14, 2 September 2025, + Draft, draft-ietf-moq-transport-15, 20 October 2025, . + transport-15>. [RFC9438] Xu, L., Ha, S., Rhee, I., Goel, V., and L. Eggert, Ed., "CUBIC for Fast and Long-Distance Networks", RFC 9438, @@ -1249,9 +1323,9 @@ Internet-Draft C4 Design October 2025 [I-D.ietf-ccwg-bbr] Cardwell, N., Swett, I., and J. Beshay, "BBR Congestion Control", Work in Progress, Internet-Draft, draft-ietf- - ccwg-bbr-03, 7 July 2025, + ccwg-bbr-04, 20 October 2025, . + bbr-04>. [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, @@ -1263,6 +1337,15 @@ Internet-Draft C4 Design October 2025 RFC 6582, DOI 10.17487/RFC6582, April 2012, . + + + + +Huitema, et al. Expires 5 June 2026 [Page 24] + +Internet-Draft C4 Design December 2025 + + [RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows", RFC 3649, DOI 10.17487/RFC3649, December 2003, . @@ -1278,18 +1361,6 @@ Internet-Draft C4 Design October 2025 start", Computer Networks vol. 55, no. 9, pp. 2092-2110 , June 2011, . - - - - - - - -Huitema, et al. Expires 22 April 2026 [Page 23] - -Internet-Draft C4 Design October 2025 - - [Cubic-QUIC-Blog] Huitema, C., "Implementing Cubic congestion control in Quic", Christian Huitema's blog , November 2019, @@ -1306,9 +1377,15 @@ Internet-Draft C4 Design October 2025 Balasubramanian, P., Ertugay, O., Havey, D., and M. Bagnulo, "LEDBAT++: Congestion Control for Background Traffic", Work in Progress, Internet-Draft, draft-irtf- - iccrg-ledbat-plus-plus-03, 9 September 2025, + iccrg-ledbat-plus-plus-04, 18 November 2025, . + ledbat-plus-plus-04>. + + [RFC9330] Briscoe, B., Ed., De Schepper, K., Bagnulo, M., and G. + White, "Low Latency, Low Loss, and Scalable Throughput + (L4S) Internet Service: Architecture", RFC 9330, + DOI 10.17487/RFC9330, January 2023, + . [RFC9331] De Schepper, K. and B. Briscoe, Ed., "The Explicit Congestion Notification (ECN) Protocol for Low Latency, @@ -1316,6 +1393,22 @@ Internet-Draft C4 Design October 2025 DOI 10.17487/RFC9331, January 2023, . + + + + +Huitema, et al. Expires 5 June 2026 [Page 25] + +Internet-Draft C4 Design December 2025 + + + [I-D.briscoe-iccrg-prague-congestion-control] + De Schepper, K., Tilmans, O., Briscoe, B., and V. Goel, + "Prague Congestion Control", Work in Progress, Internet- + Draft, draft-briscoe-iccrg-prague-congestion-control-04, + 24 July 2024, . + [ICCRG-LEO] Lai, Z., Li, Z., Wu, Q., Li, H., and Q. Zhang, "Mind the Misleading Effects of LEO Mobility on End-to-End @@ -1338,14 +1431,6 @@ Authors' Addresses Suhas Nandakumar Cisco - - - -Huitema, et al. Expires 22 April 2026 [Page 24] - -Internet-Draft C4 Design October 2025 - - Email: snandaku@cisco.com @@ -1368,33 +1453,4 @@ Internet-Draft C4 Design October 2025 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Huitema, et al. Expires 22 April 2026 [Page 25] +Huitema, et al. Expires 5 June 2026 [Page 26] diff --git a/doc/c4-spec.md b/doc/c4-spec.md index df94dab..1bc8536 100644 --- a/doc/c4-spec.md +++ b/doc/c4-spec.md @@ -318,10 +318,20 @@ to values that depends on these variables and on a coefficient `alpha_current`: ~~~ -pacing_rate = alpha_current_ * nominal_rate -cwnd = max (pacing_rate * nominal_max_rtt, 2*MTU) +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: state | alpha | comments @@ -560,6 +570,7 @@ only react to those losses that are detected by gaps in acknowledgements. ## Detecting Excessive CE Marks {#process-ecn} +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 @@ -652,17 +663,19 @@ This document has no IANA actions. TODO acknowledge. # Changes since previous versions +{:numbered="false"} This section should be deleted before publication as an RFC ## Changes since draft-huitema-ccwg-c4-spec-00 +{:numbered="false"} Added the specification of reaction to ECN in {{process-ecn}} and in {{rate-reduction}}. Update section {{c4-pushing}} to modulate pushing rate based on observed rate of ECN/CE marks. -In {{set_pace}}, the computation of the "quantum" changed -from: +Added the RTT margin consideration in {{set_pace}}, and +changed the computation of the "quantum" from: ~~~ quantum = max ( min (cwnd / 4, 64KB), 2*MTU) diff --git a/doc/c4-spec.txt b/doc/c4-spec.txt index cc4ca10..5700a25 100644 --- a/doc/c4-spec.txt +++ b/doc/c4-spec.txt @@ -5,9 +5,9 @@ Network Working Group C. Huitema Internet-Draft Private Octopus Inc. Intended status: Experimental S. Nandakumar -Expires: 22 April 2026 C. Jennings +Expires: 5 June 2026 C. Jennings Cisco - 19 October 2025 + 2 December 2025 Specification of Christian's Congestion Control Code (C4) @@ -40,7 +40,7 @@ Status of This Memo time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 22 April 2026. + This Internet-Draft will expire on 5 June 2026. Copyright Notice @@ -53,9 +53,9 @@ Copyright Notice -Huitema, et al. Expires 22 April 2026 [Page 1] +Huitema, et al. Expires 5 June 2026 [Page 1] -Internet-Draft C4 Specification October 2025 +Internet-Draft C4 Specification December 2025 Please review these documents carefully, as they describe your rights @@ -80,20 +80,23 @@ Table of Contents 4.3.1. Restarting Initial if High Jitter . . . . . . . . . . 10 4.4. Cruising state {#c4-cruising } . . . . . . . . . . . . . 10 4.5. Pushing state . . . . . . . . . . . . . . . . . . . . . . 10 - 5. Handling of congestion signals . . . . . . . . . . . . . . . 10 + 5. Handling of congestion signals . . . . . . . . . . . . . . . 11 5.1. Variable Sensitivity . . . . . . . . . . . . . . . . . . 11 - 5.2. Detecting Excessive Delays . . . . . . . . . . . . . . . 11 + 5.2. Detecting Excessive Delays . . . . . . . . . . . . . . . 12 5.3. Detecting Excessive Losses . . . . . . . . . . . . . . . 12 5.3.1. Do not react to Probe Time Out . . . . . . . . . . . 12 - 5.4. Detecting Excessive CE Marks . . . . . . . . . . . . . . 12 - 5.5. Rate Reduction on Congestion . . . . . . . . . . . . . . 12 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 - 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 - 8.2. Informative References . . . . . . . . . . . . . . . . . 13 - Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 + 5.4. Detecting Excessive CE Marks . . . . . . . . . . . . . . 13 + 5.5. Applying congestion signals . . . . . . . . . . . . . . . 13 + 5.5.1. Rate Reduction on Congestion . . . . . . . . . . . . 13 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 + 8.2. Informative References . . . . . . . . . . . . . . . . . 14 + Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15 + Changes since previous versions . . . . . . . . . . . . . . . . . 15 + Changes since draft-huitema-ccwg-c4-spec-00 . . . . . . . . . . 15 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction @@ -102,18 +105,19 @@ Table of Contents specifically multimedia applications using QUIC [RFC9000] and the Media over QUIC transport [I-D.ietf-moq-transport]. - The two main variables describing the state of a flow are the - "nominal rate" (see Section 3.1) and the "nominal max RTT" (see - Section 3.2). C4 organizes the management of the flow through a - series of states: Initial, during which the first assessment of -Huitema, et al. Expires 22 April 2026 [Page 2] + +Huitema, et al. Expires 5 June 2026 [Page 2] -Internet-Draft C4 Specification October 2025 +Internet-Draft C4 Specification December 2025 + The two main variables describing the state of a flow are the + "nominal rate" (see Section 3.1) and the "nominal max RTT" (see + Section 3.2). C4 organizes the management of the flow through a + series of states: Initial, during which the first assessment of nominal-rate and nominal max RTT are obtained, Recovery in which a flow is stabilized after the Initial or Pushing phase, Cruising during which a flow uses the nominal rate, and Pushing during which @@ -158,24 +162,25 @@ Internet-Draft C4 Specification October 2025 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. -Huitema, et al. Expires 22 April 2026 [Page 3] +Huitema, et al. Expires 5 June 2026 [Page 3] -Internet-Draft C4 Specification October 2025 +Internet-Draft C4 Specification December 2025 + + 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 the oldest + time of the acknowledged packet and the send time of the oldest "delivered" packet. delay_estimate = max (current_time - time_sent, send_delay) @@ -214,18 +219,15 @@ Internet-Draft C4 Specification October 2025 * queuing delays caused by competing applications - * queuing delays introduced by C4 itself. - - - - -Huitema, et al. Expires 22 April 2026 [Page 4] +Huitema, et al. Expires 5 June 2026 [Page 4] -Internet-Draft C4 Specification October 2025 +Internet-Draft C4 Specification December 2025 + * 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 @@ -275,11 +277,9 @@ Internet-Draft C4 Specification October 2025 - - -Huitema, et al. Expires 22 April 2026 [Page 5] +Huitema, et al. Expires 5 June 2026 [Page 5] -Internet-Draft C4 Specification October 2025 +Internet-Draft C4 Specification December 2025 3.4. Per era variables @@ -333,9 +333,9 @@ Internet-Draft C4 Specification October 2025 -Huitema, et al. Expires 22 April 2026 [Page 6] +Huitema, et al. Expires 5 June 2026 [Page 6] -Internet-Draft C4 Specification October 2025 +Internet-Draft C4 Specification December 2025 Start @@ -389,14 +389,22 @@ Internet-Draft C4 Specification October 2025 -Huitema, et al. Expires 22 April 2026 [Page 7] +Huitema, et al. Expires 5 June 2026 [Page 7] -Internet-Draft C4 Specification October 2025 +Internet-Draft C4 Specification December 2025 - pacing_rate = alpha_current_ * nominal_rate - cwnd = max (pacing_rate * nominal_max_rtt, 2*MTU) - quantum = max ( min (cwnd / 4, 64KB), 2*MTU) + 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: @@ -415,6 +423,16 @@ Internet-Draft C4 Specification October 2025 Table 1 + 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. + + quantum = max ( min (pacing_rate*4_milliseconds, 64KB), 2*MTU) + 4.2. Initial state When the flow is initialized, it enters the Initial state, during @@ -424,6 +442,14 @@ Internet-Draft C4 Specification October 2025 pacing rate and CWND to be set default initial values. The nominal max RTT will be set to the first assessed RTT value, but is not otherwise changed during the initial phase. The nominal rate is + + + +Huitema, et al. Expires 5 June 2026 [Page 8] + +Internet-Draft C4 Specification December 2025 + + updated after receiving acknowledgements, see {#nominal-rate}. C4 will exit the Initial state and enter Recovery if the nominal rate @@ -439,17 +465,6 @@ Internet-Draft C4 Specification October 2025 2- If the signal is due to "loss", C4 will only exit the initial state if more than 20 packets have been received. - - - - - - -Huitema, et al. Expires 22 April 2026 [Page 8] - -Internet-Draft C4 Specification October 2025 - - The restriction on delay signals is meant to prevent spurious exit due to delay jitter. The restriction on loss signals is meant to ensure that enough packets have been received to properly assess the @@ -483,6 +498,14 @@ Internet-Draft C4 Specification October 2025 * Any increase if the prior pushing rate (alpha_prior) was 17/16 or less, + + + +Huitema, et al. Expires 5 June 2026 [Page 9] + +Internet-Draft C4 Specification December 2025 + + * 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. @@ -494,18 +517,6 @@ Internet-Draft C4 Specification October 2025 Reception of a congestion signal during the Initial phase does not cause a change in the nominal_rate or nominal_max_RTT. - - - - - - - -Huitema, et al. Expires 22 April 2026 [Page 9] - -Internet-Draft C4 Specification October 2025 - - 4.3.1. Restarting Initial if High Jitter The "nominal max RTT" is not updated during the Initial phase, @@ -532,9 +543,24 @@ Internet-Draft C4 Specification October 2025 4.5. Pushing state - The Pushing state is entered from the Cruising state. The - coefficient alpha_current is set to 5/4 if the previous pushing - attempt was successful (see Section 4.3), or 17/16 if it was not. + The Pushing state is entered from the Cruising state. + + The coefficient alpha_current depend on whether the previous pushing + attempt was successful (see Section 4.3), and also of the current + value of ecn_alpha (see Section 5.4): + + if not previous_attempt_successful: + alpha_current = 17/16 + else: + alpha_current = 17/16 + + 17/16 * (1 - ecn_alpha / ecn_threshold) + + + +Huitema, et al. Expires 5 June 2026 [Page 10] + +Internet-Draft C4 Specification December 2025 + C4 exits the pushing state after one era, or if a congestion signal is received before that. In an exception to standard congestion @@ -555,13 +581,6 @@ Internet-Draft C4 Specification October 2025 3. Excessive rate of ECN/CE marks - - -Huitema, et al. Expires 22 April 2026 [Page 10] - -Internet-Draft C4 Specification October 2025 - - C4 monitors successive RTT measurements and compare them to a reference value, defined as the sum of the "nominal max rtt" and a "delay threshold". C4 monitors the arrival of packet losses computes @@ -590,6 +609,15 @@ Internet-Draft C4 Specification October 2025 * linear interpolation between 0 and 0.92 for values between 50,000 and 1,000,000B/s. + + + + +Huitema, et al. Expires 5 June 2026 [Page 11] + +Internet-Draft C4 Specification December 2025 + + * linear interpolation between 0.92 and 1 for values between 1,000,000 and 10,000,000B/s. @@ -610,14 +638,6 @@ Internet-Draft C4 Specification October 2025 rtt_sample > nominal_max_rtt + delay_threshold - - - -Huitema, et al. Expires 22 April 2026 [Page 11] - -Internet-Draft C4 Specification October 2025 - - 5.3. Detecting Excessive Losses C4 maintains an average loss rate, updated for every packet as: @@ -647,17 +667,69 @@ Internet-Draft C4 Specification October 2025 and only react to those losses that are detected by gaps in acknowledgements. + + +Huitema, et al. Expires 5 June 2026 [Page 12] + +Internet-Draft C4 Specification December 2025 + + 5.4. Detecting Excessive CE Marks - TBD. The plan is to mimic the L4S specification. + 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: -5.5. Rate Reduction on Congestion + ecn_threshold = (2-sensitivity)*3/32 - On entering recovery, C4 reduces the nominal_rate by the factor - "beta" corresponding to the congestion signal: + 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. + +5.5.1. Rate Reduction on Congestion + + On entering recovery from the cruising state, C4 reduces the + nominal_rate by the factor "beta" corresponding to the congestion + signal: nominal_rate = (1-beta)*nominal_rate + + + + +Huitema, et al. Expires 5 June 2026 [Page 13] + +Internet-Draft C4 Specification December 2025 + + The coefficient beta differs depending on the nature of the congestion signal. For packet losses, it is set to 1/4, similar to the value used in Cubic. @@ -666,21 +738,14 @@ Internet-Draft C4 Specification October 2025 the measured RTT and the target RTT divided by the acceptable margin, capped to 1/4: - - - -Huitema, et al. Expires 22 April 2026 [Page 12] - -Internet-Draft C4 Specification October 2025 - - beta = min(1/4, (rtt_sample - (nominal_max_rtt + delay_threshold)/ - delay_threshod)) + delay_threshold)) + + If the signal is an ECN/CE rate, the coefficient is proportional to + the difference between ecn_alpha and ecn_threshold, capped to '1/4': - If the signal is an ECN/CE rate, this is still TBD. We could use a - proportional reduction coefficient in line with [RFC9331], but we - should use the sensitivity coefficient to modulate that signal. + beta = min(1/4, (ecn_alpha - ecn_threshold)/ ecn_threshold)) 6. Security Considerations @@ -713,23 +778,21 @@ Internet-Draft C4 Specification October 2025 DOI 10.17487/RFC9000, May 2021, . - [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-14, 2 September 2025, - . - - - -Huitema, et al. Expires 22 April 2026 [Page 13] +Huitema, et al. Expires 5 June 2026 [Page 14] -Internet-Draft C4 Specification October 2025 +Internet-Draft C4 Specification December 2025 + [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-15, 20 October 2025, + . + [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, @@ -740,6 +803,28 @@ Acknowledgments TODO acknowledge. +Changes since previous versions + + This section should be deleted before publication as an RFC + +Changes since draft-huitema-ccwg-c4-spec-00 + + 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. + Authors' Addresses Christian Huitema @@ -749,6 +834,14 @@ Authors' Addresses Suhas Nandakumar Cisco + + + +Huitema, et al. Expires 5 June 2026 [Page 15] + +Internet-Draft C4 Specification December 2025 + + Email: snandaku@cisco.com @@ -781,4 +874,23 @@ Authors' Addresses -Huitema, et al. Expires 22 April 2026 [Page 14] + + + + + + + + + + + + + + + + + + + +Huitema, et al. Expires 5 June 2026 [Page 16] diff --git a/doc/c4-tests.md b/doc/c4-tests.md index 6718448..62cba3a 100644 --- a/doc/c4-tests.md +++ b/doc/c4-tests.md @@ -233,6 +233,14 @@ The goal of the test is to verify that C4 react properly exercises the "slow down" mechanism to discover the new RTT. +## L4S and ECN {#ecn} + +The "ECN" test simulates a 20 Mbps link, +with an 80ms RTT, and a bottleneck buffer capacity corresponding +to 1 BDP. The test verifies that 100 simulated downloads of +10 MB all complete in less than 5.6 seconds. + + ## Handling of High Jitter Environments {#c4-wifi} In the design of C4, we have been paying special attention to @@ -280,7 +288,7 @@ The "bad Wi-Fi" test simulates a connection experiencing a high level of jitter. The average jitter is set to 7ms, which implies multiple spikes of 100 to 200ms every second. The data rate is set to 10Mbps, and the base RTT before jitter is set to 2ms, i.e., simulating a local server. The test -pass if 100 different 10MB downloads each complete in less than 4.3 seconds. +pass if 100 different 10MB downloads each complete in less than 4.5 seconds. ### Wifi fade trial {#wifi-fade} @@ -433,7 +441,7 @@ the same jitter characteristics as in the "bad Wi-Fi" test (see {{bad-wifi}}). The background connection tries to download 10MB, the main connection downloads 4MB. The test pass if in each of 100 trials the main connection completes -in less than 11 seconds after the beginning of the trial. +in less than 12.5 seconds after the beginning of the trial. ## Competition with BBR @@ -491,7 +499,6 @@ tries to download 10MB, the main connection downloads 4MB. The test pass if in each of 100 trials the main connection completes in less than 13.5 seconds after the beginning of the trial. - ## Handling of Multimedia Applications C4 is specifically designed to properly handle multimedia applications. We test @@ -559,7 +566,7 @@ that changes to a 100ms RTT after 1 second. The test lasts for 10 video groups of frames, i.e. 10 seconds. The measurements start 5 seconds after the start of the connection. The expected average delay is set to 110ms, -and the maximum delay is set to 120ms. The test is successful if +and the maximum delay is set to 126ms. The test is successful if 100 trials are all successful. ### Media over varying Wi-Fi diff --git a/doc/c4-tests.txt b/doc/c4-tests.txt index c46da30..00b257e 100644 --- a/doc/c4-tests.txt +++ b/doc/c4-tests.txt @@ -5,9 +5,9 @@ Network Working Group C. Huitema Internet-Draft Private Octopus Inc. Intended status: Informational S. Nandakumar -Expires: 13 April 2026 C. Jennings +Expires: 5 June 2026 C. Jennings Cisco - 10 October 2025 + 2 December 2025 Testing of Christian's Congestion Control Code (C4) @@ -40,7 +40,7 @@ Status of This Memo time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 13 April 2026. + This Internet-Draft will expire on 5 June 2026. Copyright Notice @@ -53,9 +53,9 @@ Copyright Notice -Huitema, et al. Expires 13 April 2026 [Page 1] +Huitema, et al. Expires 5 June 2026 [Page 1] -Internet-Draft C4 Tests October 2025 +Internet-Draft C4 Tests December 2025 Please review these documents carefully, as they describe your rights @@ -70,56 +70,57 @@ Table of Contents 2. Simulations . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Testing strategy . . . . . . . . . . . . . . . . . . . . 3 2.2. Reaction to network events . . . . . . . . . . . . . . . 4 - 2.2.1. Simulation of a simple 20Mbps connection . . . . . . 4 + 2.2.1. Simulation of a simple 20Mbps connection . . . . . . 5 2.2.2. Simulation of a simple 200Mbps connection . . . . . . 5 2.2.3. Simulation of a geostationary satellite connection . 5 2.2.4. Low and up . . . . . . . . . . . . . . . . . . . . . 5 - 2.2.5. Drop and back . . . . . . . . . . . . . . . . . . . . 5 + 2.2.5. Drop and back . . . . . . . . . . . . . . . . . . . . 6 2.2.6. Black Hole . . . . . . . . . . . . . . . . . . . . . 6 2.2.7. Short to long . . . . . . . . . . . . . . . . . . . . 6 - 2.3. Handling of High Jitter Environments . . . . . . . . . . 6 - 2.3.1. Bad Wi-Fi test . . . . . . . . . . . . . . . . . . . 7 - 2.3.2. Wifi fade trial . . . . . . . . . . . . . . . . . . . 7 - 2.3.3. Wifi suspension trial . . . . . . . . . . . . . . . . 7 - 2.4. Competition with itself . . . . . . . . . . . . . . . . . 8 - 2.4.1. Two short C4 simultaneous connections . . . . . . . . 8 - 2.4.2. Short background C4 connection first . . . . . . . . 8 - 2.4.3. Short background C4 connection last . . . . . . . . . 8 - 2.4.4. Two long C4 connections . . . . . . . . . . . . . . . 8 - 2.4.5. Long background C4 connection last . . . . . . . . . 9 - 2.4.6. Compete with C4 over bad Wi-Fi . . . . . . . . . . . 9 - 2.5. Competition with Cubic . . . . . . . . . . . . . . . . . 9 - 2.5.1. Two short C4 and Cubic connections . . . . . . . . . 9 - 2.5.2. Two long C4 and Cubic connections . . . . . . . . . . 10 - 2.5.3. Long Cubic background connection last . . . . . . . . 10 - 2.5.4. Compete with Cubic over bad Wi-Fi . . . . . . . . . . 10 - 2.6. Competition with BBR . . . . . . . . . . . . . . . . . . 10 - 2.6.1. Two short C4 and BBR connections . . . . . . . . . . 11 - 2.6.2. Two long C4 and BBR connections . . . . . . . . . . . 11 - 2.6.3. Long BBR background connection last . . . . . . . . . 11 - 2.6.4. Compete with BBR over bad Wi-Fi . . . . . . . . . . . 11 - 2.7. Handling of Multimedia Applications . . . . . . . . . . . 11 - 2.7.1. Media on High Speed Connection . . . . . . . . . . . 12 - 2.7.2. Media on 10 Mbps Connection . . . . . . . . . . . . . 12 - 2.7.3. Media for 20 seconds . . . . . . . . . . . . . . . . 13 - 2.7.4. Media over varying RTT . . . . . . . . . . . . . . . 13 - 2.7.5. Media over varying Wi-Fi . . . . . . . . . . . . . . 13 - 2.7.6. Media with Wi-Fi suspensions . . . . . . . . . . . . 13 - 2.7.7. Media over bad Wi-Fi . . . . . . . . . . . . . . . . 14 - - - -Huitema, et al. Expires 13 April 2026 [Page 2] + 2.3. L4S and ECN . . . . . . . . . . . . . . . . . . . . . . . 6 + 2.4. Handling of High Jitter Environments . . . . . . . . . . 7 + 2.4.1. Bad Wi-Fi test . . . . . . . . . . . . . . . . . . . 7 + 2.4.2. Wifi fade trial . . . . . . . . . . . . . . . . . . . 8 + 2.4.3. Wifi suspension trial . . . . . . . . . . . . . . . . 8 + 2.5. Competition with itself . . . . . . . . . . . . . . . . . 8 + 2.5.1. Two short C4 simultaneous connections . . . . . . . . 8 + 2.5.2. Short background C4 connection first . . . . . . . . 9 + 2.5.3. Short background C4 connection last . . . . . . . . . 9 + 2.5.4. Two long C4 connections . . . . . . . . . . . . . . . 9 + 2.5.5. Long background C4 connection last . . . . . . . . . 9 + 2.5.6. Compete with C4 over bad Wi-Fi . . . . . . . . . . . 9 + 2.6. Competition with Cubic . . . . . . . . . . . . . . . . . 10 + 2.6.1. Two short C4 and Cubic connections . . . . . . . . . 10 + 2.6.2. Two long C4 and Cubic connections . . . . . . . . . . 10 + 2.6.3. Long Cubic background connection last . . . . . . . . 10 + 2.6.4. Compete with Cubic over bad Wi-Fi . . . . . . . . . . 10 + 2.7. Competition with BBR . . . . . . . . . . . . . . . . . . 11 + 2.7.1. Two short C4 and BBR connections . . . . . . . . . . 11 + 2.7.2. Two long C4 and BBR connections . . . . . . . . . . . 11 + 2.7.3. Long BBR background connection last . . . . . . . . . 11 + 2.7.4. Compete with BBR over bad Wi-Fi . . . . . . . . . . . 12 + 2.8. Handling of Multimedia Applications . . . . . . . . . . . 12 + 2.8.1. Media on High Speed Connection . . . . . . . . . . . 13 + 2.8.2. Media on 10 Mbps Connection . . . . . . . . . . . . . 13 + 2.8.3. Media for 20 seconds . . . . . . . . . . . . . . . . 13 + 2.8.4. Media over varying RTT . . . . . . . . . . . . . . . 13 + 2.8.5. Media over varying Wi-Fi . . . . . . . . . . . . . . 13 + 2.8.6. Media with Wi-Fi suspensions . . . . . . . . . . . . 14 + + + +Huitema, et al. Expires 5 June 2026 [Page 2] -Internet-Draft C4 Tests October 2025 +Internet-Draft C4 Tests December 2025 + 2.8.7. Media over bad Wi-Fi . . . . . . . . . . . . . . . . 14 3. Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.1. Loopback tests . . . . . . . . . . . . . . . . . . . . . 14 3.2. Webex prototype deployments . . . . . . . . . . . . . . . 14 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 - 6. Informative References . . . . . . . . . . . . . . . . . . . 14 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 + 6. Informative References . . . . . . . . . . . . . . . . . . . 15 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 @@ -154,6 +155,21 @@ Internet-Draft C4 Tests October 2025 congestion control protocols, including Cubic and BBR. We added an implementation of C4. + + + + + + + + + + +Huitema, et al. Expires 5 June 2026 [Page 3] + +Internet-Draft C4 Tests December 2025 + + That implementation is designed so that the same code can be used in execution over the network and in simulations, the main difference being a replacement of the socket API by a simulation API. When @@ -163,13 +179,6 @@ Internet-Draft C4 Tests October 2025 mechanism, we can simulate in a fraction of a second a connection that would last 10 seconds in "real time". - - -Huitema, et al. Expires 13 April 2026 [Page 3] - -Internet-Draft C4 Tests October 2025 - - Our basic test is to run a simulation, measure the simulated duration of a connection, and compare that to the expected nominal value. When we were developing the C4, we used that for detecting possible @@ -208,23 +217,21 @@ Internet-Draft C4 Tests October 2025 * a sudden increase in path latency, from "short" to "long" -2.2.1. Simulation of a simple 20Mbps connection - - This scenario simulates a 10MB download over a 20 Mbps link, with an - 80ms RTT, and a bottlneck buffer capacity corresponding to 1 BDP. - The test verifies that 100 simulations all complete in less than 5 - seconds. - +Huitema, et al. Expires 5 June 2026 [Page 4] + +Internet-Draft C4 Tests December 2025 -Huitema, et al. Expires 13 April 2026 [Page 4] - -Internet-Draft C4 Tests October 2025 +2.2.1. Simulation of a simple 20Mbps connection + This scenario simulates a 10MB download over a 20 Mbps link, with an + 80ms RTT, and a bottlneck buffer capacity corresponding to 1 BDP. + The test verifies that 100 simulations all complete in less than 5 + seconds. In a typical simulation, we see a initial phase complete in less than 800ms, followed by a recovery phase in which the transmission rate @@ -259,28 +266,30 @@ Internet-Draft C4 Tests October 2025 of the path. At the beginning of the simulation, the simulated bandwidth is set at 5 Mbps. It increases to 10 Mbps after 2.5 seconds. The RTT remains constant at 100ms. The test verifies that - 100 simulations of a 7MB download all complete in less than 7.6 + 100 simulations of a 7MB download all complete in less than 7.9 seconds. The goal of the test is to verify that C4 promptly discovers the increase in bandwidth, and increases the transmission rate. -2.2.5. Drop and back - The "low and up" scenario simulates a sudden decrease in the capacity - of the path, followed by return to normal. At the beginning of the - simulation, the simulated bandwidth is set at 10 Mbps. It decreases - to 5 Mbps after 1.5 second, then returns to 10 Mbps after 2 seconds. - The RTT remains constant at 100ms. The test verifies that 100 - simulations of a 7MB download all complete in less than 8 seconds. -Huitema, et al. Expires 13 April 2026 [Page 5] +Huitema, et al. Expires 5 June 2026 [Page 5] -Internet-Draft C4 Tests October 2025 +Internet-Draft C4 Tests December 2025 + +2.2.5. Drop and back + + The "low and up" scenario simulates a sudden decrease in the capacity + of the path, followed by return to normal. At the beginning of the + simulation, the simulated bandwidth is set at 10 Mbps. It decreases + to 5 Mbps after 1.5 second, then returns to 10 Mbps after 2 seconds. + The RTT remains constant at 100ms. The test verifies that 100 + simulations of a 7MB download all complete in less than 8.15 seconds. The goal of the test is to verify that C4 adapts promptly to changes in the available bandwidth on a path. @@ -308,7 +317,28 @@ Internet-Draft C4 Tests October 2025 The goal of the test is to verify that C4 react properly exercises the "slow down" mechanism to discover the new RTT. -2.3. Handling of High Jitter Environments +2.3. L4S and ECN + + The "ECN" test simulates a 20 Mbps link, with an 80ms RTT, and a + bottleneck buffer capacity corresponding to 1 BDP. The test verifies + that 100 simulated downloads of 10 MB all complete in less than 5.6 + seconds. + + + + + + + + + + +Huitema, et al. Expires 5 June 2026 [Page 6] + +Internet-Draft C4 Tests December 2025 + + +2.4. Handling of High Jitter Environments In the design of C4, we have been paying special attention to "bad Wi-Fi" environments, in which the usual delays of a few milliseconds @@ -330,14 +360,6 @@ Internet-Draft C4 Tests October 2025 * A Poisson arrival arrival model with lambda = 12, and an interval length of 7.5ms to account for Wi-Fi packet restransmission. - - - -Huitema, et al. Expires 13 April 2026 [Page 6] - -Internet-Draft C4 Tests October 2025 - - We combine these generators models by using a coefficient "x" that indicates the general degree of collisions and repetitions: @@ -354,16 +376,25 @@ Internet-Draft C4 Tests October 2025 have been using this simulation of jitter to test our implementation of multiple congestion control algorithms. -2.3.1. Bad Wi-Fi test +2.4.1. Bad Wi-Fi test The "bad Wi-Fi" test simulates a connection experiencing a high level of jitter. The average jitter is set to 7ms, which implies multiple spikes of 100 to 200ms every second. The data rate is set to 10Mbps, and the base RTT before jitter is set to 2ms, i.e., simulating a local server. The test pass if 100 different 10MB downloads each - complete in less than 4.3 seconds. + complete in less than 4.5 seconds. + + -2.3.2. Wifi fade trial + + +Huitema, et al. Expires 5 June 2026 [Page 7] + +Internet-Draft C4 Tests December 2025 + + +2.4.2. Wifi fade trial The "Wi-Fi fade" trial simulates varying conditions. The connection starts with a data rate of 20Mbps, an 80ms latency, and Wi-Fi jitter @@ -372,7 +403,7 @@ Internet-Draft C4 Tests October 2025 rate and jitter return to the original condition. The test pass if 100 different 10MB downloads each complete in less than 6.2 seconds. -2.3.3. Wifi suspension trial +2.4.3. Wifi suspension trial The "Wi-Fi suspension" test simulates a connection experiencing multiple "suspensions". For every 1.8 second of a 2 second interval, @@ -383,18 +414,7 @@ Internet-Draft C4 Tests October 2025 anyhow. The test pass if 100 different 10MB downloads each complete in less than 5.4 seconds. - - - - - - -Huitema, et al. Expires 13 April 2026 [Page 7] - -Internet-Draft C4 Tests October 2025 - - -2.4. Competition with itself +2.5. Competition with itself In accordance with [RFC9743], we design series of tests of multiple competing flows all using C4. We want to test different conditions, @@ -407,71 +427,86 @@ Internet-Draft C4 Tests October 2025 only be achieved if the main connection gets "about half" of the bandwidth. -2.4.1. Two short C4 simultaneous connections +2.5.1. Two short C4 simultaneous connections Our first test simulates two C4 connections starting at the same time and using the same path. The path has a 20Mbps data rate and 80ms RTT. The background connection tries to download 10MB, the main connection downloads 5MB. The test pass if in 100 trials the main - connection completes in less than 5.75 seconds. + connection completes in less than 6.7 seconds. + + + + + + + + -2.4.2. Short background C4 connection first + + +Huitema, et al. Expires 5 June 2026 [Page 8] + +Internet-Draft C4 Tests December 2025 + + +2.5.2. Short background C4 connection first The "background first" test simulates two C4 connections using the same path with the background connection starting 0.5 seconds before the main connection. The path has a 20Mbps data rate and 80ms RTT. The background connection tries to download 10MB, the main connection downloads 5MB. The test pass if in 100 trials the main connection - completes in less than 6.65 seconds after the beginning of the trial. + completes in less than 8.15 seconds after the beginning of the trial. -2.4.3. Short background C4 connection last +2.5.3. Short background C4 connection last The "background last" simulates two C4 connections using the same path with the background connection starting at the 0.5 seconds after the main connection. The path has a 50Mbps data rate and 30ms RTT. The background connection tries to download 20MB, the main connection downloads 10MB. The test pass if in 100 trials the main connection - completes in less than 3.6 seconds after the beginning of the trial. + completes in less than 4.1 seconds after the beginning of the trial. -2.4.4. Two long C4 connections +2.5.4. Two long C4 connections The long connection test simulates two C4 connections starting at the same time and using the same path. The path has a 20Mbps data rate and 80ms RTT. The background connection tries to download 30MB, the main connection downloads 20MB. The test pass if in 100 trials the - main connection completes in less than 22.4 seconds. - - - + main connection completes in less than 22.8 seconds. - -Huitema, et al. Expires 13 April 2026 [Page 8] - -Internet-Draft C4 Tests October 2025 - - -2.4.5. Long background C4 connection last +2.5.5. Long background C4 connection last The long "background last" test simulates two C4 connections using the same path with the background connection starting 1 second after the main connection. The path has a 10Mbps data rate and 70ms RTT. The background connection tries to download 15MB, the main connection downloads 10MB. The test pass if in 100 trials the main connection - completes in less than 22 seconds after the beginning of the trial. + completes in less than 22.2 seconds after the beginning of the trial. -2.4.6. Compete with C4 over bad Wi-Fi +2.5.6. Compete with C4 over bad Wi-Fi The "compete over bad Wi-Fi" test simulates two C4 connections using the same "bad Wi-Fi" path and starting, with the main connection starting 1 second after the background connection. The path has a 10Mbps data rate and 2ms RTT, plus Wi-Fi jitter set to 7ms average -- the same jitter characteristics as in the "bad Wi-Fi" test (see - Section 2.3.1). The background connection tries to download 10MB, + Section 2.4.1). The background connection tries to download 10MB, the main connection downloads 4MB. The test pass if in each of 100 trials the main connection completes in less than 13 seconds after the beginning of the trial. -2.5. Competition with Cubic + + + + +Huitema, et al. Expires 5 June 2026 [Page 9] + +Internet-Draft C4 Tests December 2025 + + +2.6. Competition with Cubic In accordance with [RFC9743], we design series of tests of multiple competing flows using C4 and Cubic. We want to test different @@ -484,7 +519,7 @@ Internet-Draft C4 Tests October 2025 only be achieved if the main connection gets "about half" of the bandwidth. -2.5.1. Two short C4 and Cubic connections +2.6.1. Two short C4 and Cubic connections Our first test simulates two C4 and Cubic connections starting at the same time and using the same path. The path has a 20Mbps data rate @@ -492,21 +527,7 @@ Internet-Draft C4 Tests October 2025 10MB, the main connection downloads 5MB. The test pass if in 100 trials the main connection completes in less than 6.7 seconds. - - - - - - - - - -Huitema, et al. Expires 13 April 2026 [Page 9] - -Internet-Draft C4 Tests October 2025 - - -2.5.2. Two long C4 and Cubic connections +2.6.2. Two long C4 and Cubic connections The long connection test simulates two C4 and Cubic connections starting at the same time and using the same path. The path has a @@ -515,7 +536,7 @@ Internet-Draft C4 Tests October 2025 in 100 trials the main connection completes in less than 22.2 seconds. -2.5.3. Long Cubic background connection last +2.6.3. Long Cubic background connection last The long "background last" test simulates two C4 and Cubic connections using the same path with the background Cubic connection @@ -525,19 +546,27 @@ Internet-Draft C4 Tests October 2025 trials the main connection completes in less than 22 seconds after the beginning of the trial. -2.5.4. Compete with Cubic over bad Wi-Fi +2.6.4. Compete with Cubic over bad Wi-Fi The "compete over bad Wi-Fi" test simulates two C4 and Cubic connections using the same "bad Wi-Fi" path, with the main connection starting 1 second after the background connection. The path has a 10Mbps data rate and 2ms RTT, plus Wi-Fi jitter set to 7ms average -- the same jitter characteristics as in the "bad Wi-Fi" test (see - Section 2.3.1). The background connection tries to download 10MB, + Section 2.4.1). The background connection tries to download 10MB, + + + +Huitema, et al. Expires 5 June 2026 [Page 10] + +Internet-Draft C4 Tests December 2025 + + the main connection downloads 4MB. The test pass if in each of 100 - trials the main connection completes in less than 11 seconds after + trials the main connection completes in less than 12.5 seconds after the beginning of the trial. -2.6. Competition with BBR +2.7. Competition with BBR In accordance with [RFC9743], we design series of tests of multiple competing flows using C4 and BBR. We want to test different @@ -550,19 +579,7 @@ Internet-Draft C4 Tests October 2025 only be achieved if the main connection gets "about half" of the bandwidth. - - - - - - - -Huitema, et al. Expires 13 April 2026 [Page 10] - -Internet-Draft C4 Tests October 2025 - - -2.6.1. Two short C4 and BBR connections +2.7.1. Two short C4 and BBR connections Our first test simulates two C4 and BBR connections starting at the same time and using the same path. The path has a 20Mbps data rate @@ -570,7 +587,7 @@ Internet-Draft C4 Tests October 2025 the main connection downloads 5MB. The test pass if in 100 trials the main connection completes in less than 6.7 seconds. -2.6.2. Two long C4 and BBR connections +2.7.2. Two long C4 and BBR connections The long connection test simulates two C4 and BBR connections starting at the same time and using the same path. The path has a @@ -578,7 +595,7 @@ Internet-Draft C4 Tests October 2025 download 30MB, the main connection downloads 20MB. The test pass if in 100 trials the main connection completes in less than 23 seconds. -2.6.3. Long BBR background connection last +2.7.3. Long BBR background connection last The long "background last" test simulates two C4 and BBR connections using the same path with the background BBR connection starting 1 @@ -588,19 +605,32 @@ Internet-Draft C4 Tests October 2025 main connection completes in less than 23 seconds after the beginning of the trial. -2.6.4. Compete with BBR over bad Wi-Fi + + + + + + + + +Huitema, et al. Expires 5 June 2026 [Page 11] + +Internet-Draft C4 Tests December 2025 + + +2.7.4. Compete with BBR over bad Wi-Fi The "compete over bad Wi-Fi" test simulates two C4 and BBR connections using the same "bad Wi-Fi" path, with the main connection starting 1 second after the background BBR connection. The path has a 10Mbps data rate and 2ms RTT, plus Wi-Fi jitter set to 7ms average -- the same jitter characteristics as in the "bad Wi-Fi" test (see - Section 2.3.1). The background connection tries to download 10MB, + Section 2.4.1). The background connection tries to download 10MB, the main connection downloads 4MB. The test pass if in each of 100 trials the main connection completes in less than 13.5 seconds after the beginning of the trial. -2.7. Handling of Multimedia Applications +2.8. Handling of Multimedia Applications C4 is specifically designed to properly handle multimedia applications. We test that function by running simulations of a call @@ -609,15 +639,6 @@ Internet-Draft C4 Tests October 2025 * a simulated audio stream sending 80 bytes simulated audio segments every 20 ms. - - - - -Huitema, et al. Expires 13 April 2026 [Page 11] - -Internet-Draft C4 Tests October 2025 - - * a simulated compressed video stream, sending 30 frames per second, organized as groups of 30 frames each starting with a 37500 bytes simulated I-Frame followed by 149 3750 bytes P-frames. @@ -646,7 +667,14 @@ Internet-Draft C4 Tests October 2025 and for the simulated compressed video measured after the start time are below the specified values. -2.7.1. Media on High Speed Connection + + +Huitema, et al. Expires 5 June 2026 [Page 12] + +Internet-Draft C4 Tests December 2025 + + +2.8.1. Media on High Speed Connection The "high speed" media test verifies how C4 handles media on a 100 Mbps connection with a 30ms RTT. The test lasts for 5 video groups @@ -655,7 +683,7 @@ Internet-Draft C4 Tests October 2025 and the maximum delay is set to 79ms. The test is successful if 100 trials are all successful. -2.7.2. Media on 10 Mbps Connection +2.8.2. Media on 10 Mbps Connection The "high speed" media test verifies how C4 handles media on a 10 Mbps connection with a 40ms RTT. The test lasts for 5 video groups @@ -664,17 +692,7 @@ Internet-Draft C4 Tests October 2025 and the maximum delay is set to 160ms. The test is successful if 100 trials are all successful. - - - - - -Huitema, et al. Expires 13 April 2026 [Page 12] - -Internet-Draft C4 Tests October 2025 - - -2.7.3. Media for 20 seconds +2.8.3. Media for 20 seconds The "20 seconds" media test verifies that media performance does not degrade over time, simulating a 100Mbps connection with a 30ms RTT. @@ -683,35 +701,43 @@ Internet-Draft C4 Tests October 2025 expected average delay is set to 33ms, and the maximum delay is set to 80ms. The test is successful if 100 trials are all successful. -2.7.4. Media over varying RTT +2.8.4. Media over varying RTT The "varying RTT" media test verifies that media performance does not degrade over time, simulating a 100Mbps connection with a 30ms RTT, that changes to a 100ms RTT after 1 second. The test lasts for 10 video groups of frames, i.e. 10 seconds. The measurements start 5 seconds after the start of the connection. The expected average - delay is set to 110ms, and the maximum delay is set to 120ms. The + delay is set to 110ms, and the maximum delay is set to 126ms. The test is successful if 100 trials are all successful. -2.7.5. Media over varying Wi-Fi +2.8.5. Media over varying Wi-Fi The "varying Wi-Fi" media test verifies that media performance does not degrade too much on a connection that has the kind of jitter - discussed in Section 2.3. The connection has the characteristics - similar to the "fading Wi-Fi" scenario described in Section 2.3.2. + discussed in Section 2.4. The connection has the characteristics + similar to the "fading Wi-Fi" scenario described in Section 2.4.2. The connection starts with a data rate of 20Mbps, 40ms RTT, and Wi-Fi jitter with average 1ms. After 1 second, the data rate drops to 2Mbps and the jitter average increases to 12ms. The test lasts for 5 video groups of frames, i.e. 5 seconds. The measurements start 200ms after the start of the connection. The expected average delay is set + + + +Huitema, et al. Expires 5 June 2026 [Page 13] + +Internet-Draft C4 Tests December 2025 + + to 110ms, and the maximum delay is set to 350ms. The test is successful if 100 trials are all successful. -2.7.6. Media with Wi-Fi suspensions +2.8.6. Media with Wi-Fi suspensions The "varying Wi-Fi" media test verifies that media performance does not degrade too much on a connection experiences suspensions as - discussed in Section 2.3.3. For every 1.8 second of a 2 second + discussed in Section 2.4.3. For every 1.8 second of a 2 second interval, the data rate is set to 20Mbps, and the base RTT before jitter is set to 10ms. For the last 200ms of these intervals, the data rate is set to 0. The test lasts for 5 video groups of frames, @@ -720,29 +746,19 @@ Internet-Draft C4 Tests October 2025 maximum delay is set to 202ms. The test is successful if 100 trials are all successful. - - - - - -Huitema, et al. Expires 13 April 2026 [Page 13] - -Internet-Draft C4 Tests October 2025 - - -2.7.7. Media over bad Wi-Fi +2.8.7. Media over bad Wi-Fi The "bad Wi-Fi" media test verifies that media performance does not degrade too much on a connection that has the kind of jitter - discussed in Section 2.3. The connection has the characteristics - similar to the "bad Wi-Fi" scenario described in Section 2.3.1. The + discussed in Section 2.4. The connection has the characteristics + similar to the "bad Wi-Fi" scenario described in Section 2.4.1. The average jitter is set to 7ms, which implies multiple spikes of 100 to 200ms every second. The data rate is set to 20Mbps, and the base RTT before jitter is set to 2ms, i.e., simulating a local server. The test lasts for 5 video groups of frames, i.e. 5 seconds. The measurements start 200ms after the start of the connection. The - expected average delay is set to 75ms, and the maximum delay is set - to 360ms. The test is successful if 100 trials are all successful. + expected average delay is set to 105ms, and the maximum delay is set + to 410ms. The test is successful if 100 trials are all successful. 3. Tests @@ -763,6 +779,13 @@ Internet-Draft C4 Tests October 2025 We did not include specific security oriented tests in this document. + + +Huitema, et al. Expires 5 June 2026 [Page 14] + +Internet-Draft C4 Tests December 2025 + + 5. IANA Considerations This document has no IANA actions. @@ -774,24 +797,12 @@ Internet-Draft C4 Tests October 2025 DOI 10.17487/RFC9000, May 2021, . - - - - - - - -Huitema, et al. Expires 13 April 2026 [Page 14] - -Internet-Draft C4 Tests October 2025 - - [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-14, 2 September 2025, + Draft, draft-ietf-moq-transport-15, 20 October 2025, . + transport-15>. [I-D.ietf-tsvwg-careful-resume] Kuhn, N., Stephan, E., Fairhurst, G., Secchi, R., and C. @@ -825,6 +836,12 @@ Authors' Addresses Email: huitema@huitema.net + +Huitema, et al. Expires 5 June 2026 [Page 15] + +Internet-Draft C4 Tests December 2025 + + Suhas Nandakumar Cisco Email: snandaku@cisco.com @@ -837,4 +854,43 @@ Authors' Addresses -Huitema, et al. Expires 13 April 2026 [Page 15] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Huitema, et al. Expires 5 June 2026 [Page 16] diff --git a/sim_specs/c4_ecn.txt b/sim_specs/c4_ecn.txt index ee0c251..e4d9a40 100644 --- a/sim_specs/c4_ecn.txt +++ b/sim_specs/c4_ecn.txt @@ -2,7 +2,7 @@ main_cc_algo: c4 main_start_time: 0 main_scenario_text: =b1:*1:397:10000000; nb_connections: 1 -main_target_time: 5000000 +main_target_time: 5600000 data_rate_in_gbps: 0.02 latency: 40000 l4s_max: 15000 diff --git a/sim_specs/c4_media_short_long.txt b/sim_specs/c4_media_short_long.txt index c7b289b..b8e00ff 100644 --- a/sim_specs/c4_media_short_long.txt +++ b/sim_specs/c4_media_short_long.txt @@ -11,6 +11,6 @@ qlog_dir: cclog qperf_log: c4_media_sl_qperflog.csv media_stats_start: 5000000 media_latency_average: 110000 -media_latency_max: 125000 +media_latency_max: 126000 media_excluded: vhigh, vmid, vlast link_scenario: 1000000:U0.01:D0.1:L15000:Q100000;60000000:U0.01:D0.1:L50000:Q200000 \ No newline at end of file diff --git a/sim_specs/c4_wifi_bad.txt b/sim_specs/c4_wifi_bad.txt index c3e972f..e8eeb99 100644 --- a/sim_specs/c4_wifi_bad.txt +++ b/sim_specs/c4_wifi_bad.txt @@ -3,7 +3,7 @@ main_cc_options: main_start_time: 0 main_scenario_text: =b1:*1:397:4000000; nb_connections: 1 -main_target_time: 4300000 +main_target_time: 4500000 data_rate_in_gbps: 0.01 latency: 1000 jitter: 7000 diff --git a/sim_specs/c4_wifi_bad_cubic.txt b/sim_specs/c4_wifi_bad_cubic.txt index 6a1f15b..6fe01d9 100644 --- a/sim_specs/c4_wifi_bad_cubic.txt +++ b/sim_specs/c4_wifi_bad_cubic.txt @@ -6,7 +6,7 @@ nb_connections: 2 background_cc_algo: cubic background_start_time: 0 background_scenario_text: =b1:*1:397:10000000; -main_target_time: 12100000 +main_target_time: 12500000 data_rate_in_gbps: 0.01 latency: 1000 jitter: 7000