What Is Cuback? The Beginner's Guide to the ACK-Driven Rewrite of TCP CUBIC

CodexFuse Team · 2026-11-05T17:33:05.251Z · 28 min read min read

What Is Cuback? The Beginner's Guide to the ACK-Driven Rewrite of TCP CUBIC

What Is Cuback?

What is Cuback? It is an ACK-driven reformulation of CUBIC congestion control, specified in the individual IETF Internet-Draft draft-kazuho-ccwg-cuback-01, written by Kazuho Oku of Fastly and published on 2 November 2026. Instead of growing the congestion window as a cubic function of elapsed wall-clock time, as CUBIC does, Cuback expresses the same cubic growth as a function of how much data has been acknowledged since the congestion-avoidance epoch began.

The growth curve keeps the same shape. Only the clock changes, from wall-clock time to the ACK clock.

Cuback is a draft, not a standard, and it is not shipping in any kernel, operating system, or QUIC stack. Its contribution is narrower and more practical than a new algorithm: it makes CUBIC simpler to implement correctly, easier to test, and immune to a class of ACK-counting bugs that the author found in real stacks. If you run servers, write networking code, or operate hosting infrastructure, Cuback is worth understanding now, because the code your traffic already depends on is the code it aims to fix.

Congestion control decides how fast a sender may push data into a network without overwhelming it, so it sits underneath almost everything a server does. If you ever need to check a file's fingerprint while debugging a deployment, the SHA-256 hash generator is a free tool that does exactly that. And because congestion control runs on the machine that serves your traffic, VPS hosting is the natural companion topic: a private server you control is where CUBIC, and one day possibly Cuback, actually runs.

How Cuback Works in Five Steps

1. At the start of each congestion-avoidance epoch, three parameters are fixed and never change until the next congestion event: W_max, the window just before the last reduction; bandwidth, the rate the bottleneck delivers data; and cwnd_epoch, the window at the start of the epoch.
2. Two curves are defined over those frozen parameters. A_cubic(w) is the inverted cubic curve, and A_reno(w) is the inverted Reno-friendly growth curve.
3. A(w) is the smaller of the two curves. It is the total amount of data, in segments, that must be acknowledged for the congestion window to reach the value w.
4. D(w) is the gap between A(w+1) and A(w), with a floor of 2. It is the number of newly acknowledged segments needed to grow the window from w to w+1.
5. The sender accumulates acknowledged bytes exactly like Reno does, and bumps the window by one MSS each time the D(w) threshold is reached. There is no wall-clock epoch to pause and resume, because when acknowledgments stop arriving, growth stops naturally.

Cubic Congestion Control Explained: CUBIC in 60 Seconds

To understand Cuback, you first need CUBIC, because Cuback changes only one stage of it and keeps the rest. CUBIC is a standard TCP congestion-control algorithm that uses a cubic function instead of a linear congestion-window increase to improve scalability and stability over fast and long-distance networks. It has been adopted as the default TCP congestion-control algorithm by the Linux, Windows, and Apple stacks, and RFC 9438 calls it the currently most widely deployed standard for TCP congestion control.

The problem CUBIC solves is Reno's slow recovery on big pipes. Classical Reno grows its window by roughly one segment per round trip, so after a congestion event on a network with a large bandwidth-delay product, it takes far too long to climb back to full speed. CUBIC fixes this by defining window growth as a cubic function of elapsed time: W_cubic(t) = C times (t minus K) cubed, plus W_max.

Here W_max is the window size at the last congestion event, C is the constant 0.4, and K is the time needed to climb back to W_max.

The cubic curve has three regions, and each one has a job. The Reno-friendly region keeps CUBIC at least as fast as Reno where Reno already performs well, which is networks with short round trips and small bandwidth. The concave region sits below W_max, where growth slows as the window approaches the plateau around the last congestion point, the point where network utilisation is judged highest.

The convex region sits above W_max, where growth accelerates to probe for a new, higher maximum.

Two more CUBIC facts matter for everything that follows. First, when a packet is lost, CUBIC cuts the window by multiplying it by 0.7, while Reno cuts it by 0.5. Second, CUBIC is not TCP-only: RFC 9438 notes it can also be used for QUIC and SCTP as a default congestion controller.

CUBIC's history is long, which is part of why a rewrite is now interesting. Its predecessor, BIC-TCP, became the Linux default in 2005. CUBIC itself was described in a 2008 research paper, published as Informational RFC 8312 in 2017, and became a Standards Track RFC, RFC 9438, in August 2023.

That is 21 years from BIC-TCP's Linux debut to Cuback's draft, and 15 years from the CUBIC paper to the Standards Track RFC.

Why CUBIC Needed a Rewrite: Two Estimates and a Clock

CUBIC's design carries a hidden cost: during congestion avoidance, a sender maintains two independently evolving window estimates. One is the time-driven cubic window, which advances with wall-clock time. The other is the ACK-driven Reno-friendly window, which advances as acknowledgments arrive.

The sender must update both estimates on every acknowledgment and take the larger of the two.

That is not the whole burden. Because the cubic window advances with wall-clock time, the sender needs mutable epoch state and a small state machine that pauses the cubic clock when the sender stops being limited by the congestion window, and resumes it when transmission becomes window-limited again. RFC 9438 states the rule plainly: the elapsed time in the cubic function must not include periods when the window was not updated because of application-limited behaviour.

Correctly maintaining those states complicates implementations, and the complications interact with application-limited periods and other congestion-control transitions. A sender that pauses its clock a fraction too late, resumes it a fraction too early, or updates one estimate but not the other will grow its window at the wrong rate. The window is the single number that decides how much data is in flight, so a wrong rate means either wasted capacity or a self-inflicted queue.

Cuback's answer is to delete the machinery rather than repair it. It expresses both the cubic and the Reno-friendly growth functions in terms of the amount of data that must be acknowledged for the window to reach a given value. The parameters that define those functions are set at the beginning of a congestion-avoidance epoch and stay immutable for the whole epoch.

Window growth then becomes a pure function of the current window and those frozen parameters, with no separately evolving estimates to keep in sync.

The remaining runtime state is essentially the same as in Reno. The sender tracks how many additional bytes need to be acknowledged before increasing the window by one MSS. In both Reno and Cuback, acknowledged bytes are accumulated until enough have been received to grow the window by one segment.

The difference lies only in how the required number of acknowledged bytes is calculated: Reno derives it directly from the current window, while Cuback obtains it by evaluating the pure functions in the draft.

The ACK-Ratio Bug That Pushed the Author to Write Cuback

The draft did not appear out of nowhere. In a post to the IETF Congestion Control Working Group mailing list, Kazuho Oku pointed out that sections 4.4 and 4.5 of RFC 9438 do not account for segments_acked when increasing the window outside the Reno-friendly region. A literal implementation therefore makes CUBIC's growth rate depend on the receiver's ACK ratio, and the unfairness gets worse as acknowledgments become less frequent.

The mechanism is easy to see. RFC 9438's per-ACK increase outside the Reno-friendly region approximates the intended growth toward its target over one round trip only when there are roughly one ACK per segment, that is, roughly cwnd ACK events per round trip. If the receiver acknowledges every second packet instead of every packet, the sender takes fewer steps toward the target in the same round trip.

The window grows more slowly than the specification intended, for no reason connected to congestion.

The author ran a simulation to measure the effect. On a simulated 100 Mbps bottleneck with a full round-trip time of 80 ms, a CUBIC flow competing against an otherwise identical CUBIC flow using ACK1, meaning acknowledge every packet, obtained these shares of the bottleneck: ACK1 took 50.0 percent, ACK2 took 45.29 percent, and ACK10 took 10.07 percent. ACK2 matters most, because acknowledging at least every second packet is the conventional delayed-ACK behaviour recommended by both TCP and QUIC version 1.

The author summarised the ACK2 case in his own words, writing that under stable conditions and with the receiver using the default ACK2 policy, a literal implementation of RFC 9438 gets about 17 percent less throughput than a stack that does not have this bug. That 17 percent figure is the author's paraphrase of his simulation, and the table behind it shows 45.29 percent against 50.0 percent. Both are his words, and this article quotes them as his.

The bug's scope is narrower than it first sounds, and the author said so himself. The issue does not exist in the Linux TCP stack or in Google Quiche, because both account for the amount of newly acknowledged segments. But there also seem to be multiple QUIC stacks that contain this bug, and attempts to reduce acknowledgments will make the downside more prominent.

The fix the author proposed in the post was a one-line change: multiply the increase by segments_acked.

Cuback goes further than that one-line fix. By defining growth purely in terms of acknowledged data, it removes the ACK-ratio dependence by construction rather than by patching one formula. The draft itself does not cite the mailing-list post, so the connection between the post and the draft is this article's inference, and it is labelled as such.

What is certain is that the post and the draft attack the same class of error: growth that depends on how often the receiver happens to acknowledge.

How the ACK-Driven Cubic Works: A(w) and D(w)

Cuback's core idea fits in two functions. A(w) is the total amount of data, measured in segments, that must be acknowledged for the congestion window to reach the value w. D(w) is the amount of newly acknowledged data needed to grow the window from w to w+1.

The sender counts acknowledged segments, and every time the count reaches D(w), the window grows by one MSS.

A(w) is the smaller of two curves, and the min is doing real work. A_cubic(w) is the cubic curve turned inside out: instead of asking what window a given time produces, it asks how much acknowledged data a given window requires. A_reno(w) is the Reno-friendly curve expressed the same way.

Taking the smaller of the two mirrors CUBIC taking the larger of its two window estimates, and it is what keeps Cuback at least as fast as Reno where Reno performs well.

The three per-epoch parameters are frozen when congestion avoidance begins. W_max is the window just before the reduction at the congestion event, which is the same as cwnd_prior. Bandwidth is cwnd_prior divided by the smoothed round-trip time, an estimate of the rate at which the bottleneck delivers data, in segments per second.

Cwnd_epoch is the window at the start of the congestion-avoidance stage. None of the three changes until the next congestion event.

The constants are the same ones CUBIC uses, with the same values: beta_cubic is 0.7, alpha_cubic is 0.529, and C is 0.4. The alpha value is not arbitrary. It comes from the formula 3 times (1 minus beta_cubic) divided by (1 plus beta_cubic), which is 3 times 0.3 divided by 1.7, or 0.9 divided by 1.7, which equals 0.52941 and rounds to the draft's 0.529.

The D(w) function has a floor of 2 segments, and that floor is a safety bound. It caps growth at half the congestion window per round trip, which is the counterpart of CUBIC's rule that its target must stay within 1.5 times the current window. In Reno, the equivalent threshold is the window itself: Reno needs cwnd acknowledged segments to grow by one MSS, so at a window of 1,000 segments, Reno needs 1,000 acknowledgments per increase.

Because growth is driven purely by acknowledgments, there is no clock to pause and resume. An idle sender accrues no growth, while a sender that keeps delivering data below its window grows only in proportion to the data it delivered. The application-limited overgrowth that CUBIC's pause rule exists to prevent cannot arise, because a gap in acknowledgments accrues no growth to catch up on later.

The draft also keeps a rate-limited increase rule, drawn from a separate draft on rate-limited increase, so that a sender returning from an idle period cannot jump its window in one burst.

Two edge cases show how carefully the draft preserves CUBIC's behaviour. If a congestion event turns out to be spurious and the sender reverts its window and slow-start threshold, it must also restore W_max, bandwidth, and cwnd_epoch to the values they held before the event. And fast convergence applies exactly as in RFC 9438: on a congestion event, if the window is below W_max, W_max is reduced first, to the window times (1 plus beta_cubic) divided by 2.

A Worked Example: The Draft's Own Test Vectors

A pure function has a property a state machine does not: you can check it directly from its inputs and outputs, without running a sequence of transitions. That is why the draft ships test vectors, and why they are Cuback's most citable asset. Appendix B of the draft gives two vectors, one for each curve, and both use the recommended constants with alpha_cubic taken as the exact 3 times (1 minus beta) over (1 plus beta) rather than the rounded 0.529.

The first vector exercises the Reno-friendly curve with small numbers. The epoch starts at a window of 7 segments, the prior window was 10, the round-trip time is 0.1 seconds, and the bandwidth is 100 segments per second. While the window is below the prior window of 10, D(w) equals w divided by alpha_cubic, so D(7) is 7 divided by 0.52941, which is 13.2222 acknowledged segments.

D(8) is 15.1111, and D(9) is 17.0000. At w equal to 10, alpha becomes 1, so D(10) is 10.0000 and D(11) is 11.0000.

Notice what the table shows. Growing from 7 to 8 segments costs about 13 acknowledged segments, while Reno at a window of 7 would need only 7. Cuback pays more per step here because it is tracking the cubic curve's shape even in the Reno-friendly region, and the numbers are small enough to verify by hand.

The cumulative column is the running total: 13.2222 plus 15.1111 is 28.3333, plus 17 is 45.3333, and so on.

The second vector exercises the cubic curve with large numbers. The epoch starts at a window of 600 segments, the prior window was 1,000, the round-trip time is 0.1 seconds, and the bandwidth is 10,000 segments per second. The constant K, the time to climb back to W_max, is the cube root of (1,000 minus 600) divided by 0.4, which is the cube root of 1,000, or exactly 10 seconds.

The symmetry in this table is the cubic curve showing through. Climbing the 50 segments below W_max costs 50,000 acknowledged segments, and climbing the 50 above it costs exactly the same 50,000. The curve is point-symmetric about W_max, and A(w) divided by bandwidth recovers K, which is a neat cross-check for any implementation.

These are computed values from the draft's own formulas, not measurements from a running network, and any implementer can reproduce them exactly.

Cuback vs CUBIC: The Same Curve, a Different Clock

Cuback and CUBIC are the same algorithm seen through two different clocks. CUBIC asks how much time has passed since the epoch began and reads the window off a cubic function of that time. Cuback asks how much data has been acknowledged since the epoch began and reads the required acknowledgments off the inverted cubic function.

The cuback cubic congestion control comparison below puts the two side by side. The curve is identical. The input changes from seconds to segments.

The curve is identical. The input changes from seconds to segments.

That single change ripples through the whole implementation. CUBIC keeps two window estimates alive and takes the larger, while Cuback keeps none and evaluates a pure function. CUBIC must pause and resume a wall-clock epoch around application-limited periods, while Cuback has no clock to pause.

CUBIC aims its growth at a target one round trip ahead to spread out bursts after acknowledgment gaps, while Cuback needs no smoothing because its increase is proportional to the acknowledgment stream by construction.

One difference deserves a closer look, because it shows Cuback is not a line-for-line translation. In the Reno-friendly region, CUBIC and Cuback both increase the window by one segment for every cwnd divided by alpha_cubic segments acknowledged. They differ only in where that region is entered.

Because Cuback's standalone recurrence uses the smaller divisor, it advances faster while the cubic curve governs, and a Cuback sender enters the Reno-friendly region somewhat earlier than a sender following RFC 9438.

What Stays Exactly the Same

The draft's own scope warning is unambiguous: Cuback alters only the congestion-avoidance stage of CUBIC, and all other behaviour specified in RFC 9438 applies unchanged. That boundary is what makes Cuback a reformulation rather than a new algorithm, and it is worth stating plainly, because a new name invites the assumption of a new system.

The one addition is a bookkeeping rule, not a behaviour change. When a congestion event turns out to be spurious and the sender reverts its window and slow-start threshold, it must also restore W_max, bandwidth, and cwnd_epoch to the values they held before the event. That follows directly from the frozen-parameter design: if the epoch is being undone, its parameters go back too.

This conservatism is deliberate. By changing only congestion avoidance, Cuback lets an implementer reuse the rest of a CUBIC stack and test the new stage in isolation against the draft's vectors. It also means that every claim about CUBIC's deployment, fairness, and history still applies to the system Cuback lives inside, because Cuback is that system with one stage rewritten.

Why Newcomers Converge Faster and Short Flows Finish Earlier

Cuback's one qualitative performance claim is about newcomers. When a new flow joins a high-capacity path that already carries an established flow, it acquires its share more rapidly than it would under CUBIC, so short flows complete earlier. The draft presents this as an analytic consequence of the ACK clock, not as a measured benchmark, and there are no lab results, percentages, or throughput measurements for Cuback itself anywhere in the document.

The mechanism is a compounding loop. Cuback derives its growth rate from the window and round-trip time recorded at the previous congestion event. Because the cubic function gives a flow with a smaller window a larger proportional increase, a newcomer gains share.

Its ACK rate, and hence its ACK clock, then runs faster than originally anticipated. That gain compounds over successive round trips, and it reduces the time to complete short flows such as the delivery of HTTP objects.

The draft states the rule precisely in its discussion section. The curve advances at the ratio of the rate the flow is currently achieving to the rate recorded at the last congestion event. A flow that has since doubled its share traverses the curve twice as fast as elapsed time would carry it, while one that has halved its share moves half as fast.

The advantage therefore decays as the achieved rate converges on the recorded rate, which is exactly what a fair-sharing algorithm should do.

That framing matters for anyone running a site. Most web traffic is short flows: a page, an image, an API response. A congestion-control change that helps a newcomer reach its fair share in fewer round trips is a change that shortens those flows, even though the steady-state throughput of a long flow barely moves.

But until an implementation exists and someone measures it, the newcomer advantage remains a reasoned claim from the draft's author, not a result.

What Does Cuback Cost? Cube Roots and the 3 Percent Figure

Every simplification has a price, and Cuback's is arithmetic. A_reno is plain arithmetic, but A_cubic needs a cube root, and cube roots are more expensive than the additions and multiplications CUBIC's per-ACK update uses. The draft answers this directly, and its answer is the only quantified Cuback number in the document.

Naively, each window increase evaluates three roots: K, A_cubic(w), and A_cubic(w+1). The draft notes that storing the data still needed to grow the window by one segment, rather than recomputing D(w) on every acknowledgment, moves the evaluation from once per acknowledgment to once per increase. Optimisations can then leave a single cube root per increase.

The draft prices the worst case against encryption, which is the right comparison for a transport stack. Calculating a cube root to the accuracy required here runs in about nine cycles on contemporary hardware, against roughly nine hundred cycles to encrypt a 1,460-byte segment through an AES-GCM-128 pipeline at 1.6 bytes per cycle. Three roots at nine cycles each is 27 cycles, and 1,460 divided by 1.6 is about 913 cycles, so 27 divided by 913 is about 2.96 percent, which the draft rounds to around 3 percent.

That is the worst case, with the window growing by one segment for every segment acknowledged. During congestion avoidance the window typically grows far more slowly than that, so the real overhead is smaller.

The draft also supplies a public-domain cube-root approximation with a maximum relative error of about 3.5e-5 and a slope error below 8.5e-4, holding each per-segment increase to roughly 0.1 percent, and running in about nine cycles on a Zen 3 core. These figures are the author's assertions, not independently measured here, and this article attributes them to the draft. They are included because they show the author's working: the cost was measured against the workload, not waved away.

Where Does Cuback Fit? Cuback TCP and QUIC

Cuback is a TCP story first, because CUBIC is a TCP story first. CUBIC is the default congestion-control algorithm in the Linux, Windows, and Apple TCP stacks, and RFC 9438 notes it can also be used for QUIC and SCTP as a default congestion controller. Cuback changes only the congestion-avoidance stage, so it applies wherever CUBIC applies, in principle.

In practice it applies nowhere yet, because no kernel, QUIC stack, or operating system ships it, and there is no setting to enable it.

That gap between principle and practice is the honest position. Fastly's own documentation lists cubic as the default congestion algorithm on its edge, alongside reno and bbr, and cites the older RFC 8312 for CUBIC rather than RFC 9438. Cuback does not appear on that page at all.

The author's employer ships CUBIC by default; it does not ship Cuback.

The QUIC angle is where the draft's motivation bites hardest. The ACK-ratio bug the author found in his mailing-list post does not exist in the Linux TCP stack or in Google Quiche, but it does seem to exist in multiple QUIC stacks, and efforts to reduce acknowledgments would make the downside more prominent. A QUIC implementation that adopts Cuback would get the fix by construction, because growth would be defined in acknowledged segments from the start.

That is a reason for QUIC implementers to read the draft, not a claim that any of them has.

For readers mapping the protocol landscape, Cuback sits beside other modern transport work rather than competing with it. What MASQUE is explains a different layer of the same world: proxying that is aware of QUIC, rather than the congestion control running inside the connection. The two drafts solve different problems, and neither replaces the other.

The Cuback Draft: Status, Timeline, and What Is Missing

Cuback is an individual Internet-Draft, which means it carries one author's name, not a working group's adoption. Its filename is draft-kazuho-ccwg-cuback, where "ccwg" is the working-group tag for the Congestion Control Working Group that discusses it, not part of the algorithm's name. The draft is discussed on the ccwg mailing list, its source lives in a public GitHub repository, and it is intended for the Standards Track.

None of that makes it a standard. Intended status is the author's aspiration, not the IETF's approval.

The timeline is short, which is the point of covering it now. The GitHub repository was created on 27 August 2026. Revision -00 was published on 25 September 2026.

Revision -01, the current revision as of 5 November 2026, was published on 2 November 2026, three days before this article, and 38 days after the -00. The -01 expires on 6 May 2027, which is 185 days after its publication, inside the six-month maximum lifetime of an Internet-Draft. A -02, a working-group adoption, or expiry follows after that.

What is missing is as informative as what is present. The Security Considerations section reads, in full, "TODO Security". The acknowledgments read "TODO acknowledge".

There are no IANA actions. The GitHub repository holds only the draft source, a Makefile, a licence, and contribution notes: 36 commits, 0 stars, 0 forks, 2 tags, and no code implementation in the listing. Those placeholders are a visible sign of how early-stage this draft is, and this article mentions them once for exactly that reason.

November 2026 has produced a small cluster of new IETF drafts, and Cuback is one of them. Other drafts from the same window covered on this site include MCP over MoQ and what A-SIP is, which shows the working groups are busy, not that any single draft is destined for adoption.

The honest summary is this: Cuback is a careful, well-specified reformulation of the internet's most widely deployed congestion-control algorithm, written by an engineer who found a real bug in how that algorithm is implemented, and it is three days old. Watch the -02.

Sources

1. Kazuho Oku, "CUBACK: CUBIC Driven by the ACK Clock", draft-kazuho-ccwg-cuback-01, Internet-Draft, 2 November 2026, https://datatracker.ietf.org/doc/draft-kazuho-ccwg-cuback/ — the primary source for the definition, the A(w) and D(w) mechanism, the test vectors, the overhead figures, and the draft's status and expiry.

2. L. Xu, S.

Ha, I. Rhee, V. Goel, and L.

Eggert, "CUBIC for Fast and Long-Distance Networks", RFC 9438, Standards Track, August 2023, https://www.rfc-editor.org/rfc/rfc9438.txt — the source for CUBIC's definition, its deployment as the default in Linux, Windows, and Apple, the cubic window function, the three regions, the 0.7 decrease factor, and the history from BIC-TCP through RFC 8312.

3. Kazuho Oku, "CWND increase in CUBIC and ACK policy", post to the IETF Congestion Control Working Group mailing list, https://mailarchive.ietf.org/arch/msg/ccwg/ZTYECT1NQijwwxq2sDLE0scbQAg/ — the source for the ACK-ratio bug, the 100 Mbps and 80 ms simulation figures of 50.0 percent, 45.29 percent, and 10.07 percent, and the author's "about 17 percent less throughput" paraphrase. The exact posting date is not shown on the fetched page, so no date is stated for it.

4. Kazuho Oku, draft-kazuho-ccwg-cuback source repository, https://github.com/kazuho/draft-kazuho-ccwg-cuback — the source for the repository's creation on 27 August 2026, its 36 commits, 0 stars, 0 forks, and the absence of any code implementation in the listing.

5. Fastly documentation, "client.socket.congestion_algorithm", https://www.fastly.com/documentation/reference/vcl/variables/client-connection/client-socket-congestion-algorithm/ — context only: Fastly offers cubic as the default, alongside reno and bbr, and cites RFC 8312 for CUBIC. Cuback is not mentioned on the page.

6. IETF author-tools diff, draft-kazuho-ccwg-cuback-00 to -01, https://author-tools.ietf.org/iddiff?url2=draft-kazuho-ccwg-cuback-01 — the source for the -00 publication date of 25 September 2026 and its expiry on 29 March 2027.

Frequently Asked Questions

Is Cuback in Linux yet?

No. Cuback is an individual Internet-Draft, revision -01, published on 2 November 2026. No kernel, operating system, QUIC stack, or vendor ships it, and there is no setting to enable it.

CUBIC remains the default congestion-control algorithm in Linux, Windows, and Apple, as specified by RFC 9438.

Is Cuback a new congestion-control algorithm?

No, it is a reformulation of CUBIC. It keeps CUBIC's growth curve, its constants of beta_cubic 0.7, alpha_cubic 0.529, and C 0.4, its 0.7 decrease factor, and every stage other than congestion avoidance. What changes is the clock: growth is driven by acknowledged data instead of elapsed wall-clock time, which removes the two-estimate bookkeeping and the pause-and-resume state machine.

Does Cuback change slow start or loss recovery?

No. The draft states that Cuback alters only the congestion-avoidance stage of CUBIC, and all other behaviour in RFC 9438 applies unchanged. Slow start, loss recovery, multiplicative decrease, and fast convergence all stay exactly as CUBIC defines them.

When will Cuback become an RFC?

There is no date, and none can be given honestly. It is an individual draft, not a working-group-adopted work item, and revision -01 expires on 6 May 2027. What happens next depends on discussion in the Congestion Control Working Group: a -02 revision, working-group adoption, or expiry are all possible.

The draft's own boilerplate warns that Internet-Drafts are work in progress and may be updated, replaced, or obsoleted at any time.

Why should a hosting operator care about a draft?

Because CUBIC runs the TCP connections your servers already serve, and the ACK-ratio bug the author found affects real QUIC stacks today. Cuback is the proposed fix at the design level, and its test vectors give implementers something verifiable to build against. There is nothing to deploy today, but the draft is the earliest signal of how the internet's default congestion control might get simpler and more correct.