Most people do not know this, but TCP CUBIC is the dominant congestion control algorithm used in modern TCP/IP networks. It is designed to efficiently utilize high-speed, long-distance links while maintaining fairness across flows with different round-trip times (RTTs). Today, it is the default congestion control algorithm in most Linux systems, and since most servers in data centers that provide various Internet services are Linux based, this makes TCP CUBIC one of the most widely deployed transport behaviors on the Internet.
As a reminder to my reader, it is very difficult to tell which version of congestion control algorithm (CCA) is in play. TCP has no version field in the header. The 3-way handshake does not clearly reveal the CCA. I will talk more about this later.
TCP CUBIC does not stand for an acronym. The name comes directly from the cubic mathematical function used to control how the congestion window grows over time. But I am getting ahead of myself.
Why TCP CUBIC Was Created
Earlier TCP congestion control algorithms such as Reno and New Reno rely on linear growth of the congestion window (cwnd). While effective in early Internet conditions, they struggle in modern networks characterized by:
- High bandwidth (multi-gigabit links)
- High latency (long-distance paths)
- Large Bandwidth-Delay Product (BDP)
In these environments, linear growth for today’s networks is too slow, leading to poor link utilization and inefficient throughput. TCP CUBIC was developed to address this limitation by introducing a non-linear growth function that allows much faster scaling while preserving stability.
The Core Concept: Cubic Window Growth
At the heart of TCP CUBIC is a mathematical function that governs how the congestion window grows over time.
W(t) = C(t – K)^3 + W_{max}
Where:
- W(t) = congestion window size at time t
- C = scaling constant
- K = time offset based on the previous maximum window
- Wₘₐₓ = window size just before the last packet loss
Let’s restate that in more practical terms:
- After a packet loss, TCP reduces its sending rate – think of it as backing off
- Then it begins increasing the congestion window again
- Instead of linear growth, it follows a cubic curve
This creates three distinct phases:
- Fast recovery toward the previous maximum (Wₘₐₓ)
- Slow probing near the previous maximum (stability region)
- Accelerated growth beyond the previous maximum (bandwidth exploration)
How TCP CUBIC Responds to Congestion
TCP CUBIC is still fundamentally a loss-based congestion control algorithm. Let’s break it down:
When No Congestion Is Detected
- The congestion window increases according to the cubic function
- Throughput ramps up quickly, especially on high-speed links
When Packet Loss Occurs
- CUBIC interprets loss as congestion
- The congestion window is reduced (multiplicative decrease)
- The algorithm stores the previous maximum window (Wₘₐₓ)
- Growth resumes using the cubic function
When you think about it – this makes sense for today’s faster network environment, albeit quite complicated.
Key Advantages of TCP CUBIC
1. Scales to High-Speed Networks
CUBIC is designed for modern Internet conditions where large BDP paths are common. It can efficiently utilize high-capacity links that legacy TCP cannot.
A BDP path refers to a network path characterized by its Bandwidth-Delay Product (BDP)—a key metric that defines how much data can be “in flight” on the network at any given time.
2. RTT Fairness
Unlike older TCP algorithms, CUBIC’s growth function is based on time, not ACK arrival rate or Round Trip Time. This means: flows with longer RTTs are not unfairly penalized and more equitable bandwidth sharing across global networks.
3. Stable Around Previous Capacity
The cubic function intentionally slows growth near the previous maximum window, which: reduces oscillation, prevents aggressive over-shooting, and improves stability of the TCP connection.
4. Backward Compatibility
CUBIC behaves similarly to TCP Reno in low-bandwidth environments, ensuring compatibility with legacy systems and mixed traffic.
5. Predictable and Stable Behavior for Carriers/Operators
Compared to earlier high-speed TCP variants, CUBIC offers:
- Stable congestion window growth
- Well-understood loss response
- Consistent performance under mixed traffic
For carriers/operators, this means:
- Easier capacity planning
- Fewer pathological edge cases
- Reliable coexistence with other traffic
6. Works Well Enough Across Diverse Conditions
CUBIC is not perfect, but it is robust across a wide range of networks such as:
- Data center fabrics
- Broadband access networks
- Mobile networks
- Wi-Fi environments
Even though it misinterprets some non-congestive loss (e.g., Wi-Fi interference), it still performs acceptably in most cases. That “good enough everywhere” property is critical for widespread adoption.
7. Why It Hasn’t CUBIC Been Fully Replaced
Newer algorithms like TCP BBR offer clear advantages:
- Better latency control
- Less reliance on packet loss
- More stable throughput
However, BBR has faced:
- Fairness concerns vs loss-based flows
- Deployment caution from operators
- Tuning and version evolution challenges (BBR v1 vs v2 vs v3)
As a result, CUBIC remains the conservative, widely trusted default.
TCP CUBIC vs Traditional TCP (Reno/NewReno)
| Feature | Reno/NewReno | TCP CUBIC |
|---|---|---|
| Growth Model | Linear | Cubic (non-linear) |
| RTT Sensitivity | High | Low |
| High-Speed Performance | Poor | Excellent |
| Stability | Moderate | Improved |
| Deployment | Legacy | Default in Linux |
There are Limitations of TCP CUBIC
While highly effective, TCP CUBIC has some known drawbacks:
- Loss-based signaling: Cannot distinguish between congestion and wireless interference
- Queue buildup: Can increase latency under heavy load (bufferbloat)
- Not optimal for modern low-latency goals compared to newer algorithms
These limitations have led to the development of newer approaches such as model-based congestion control (e.g., BBR). That is whole different topic.
This is why TCP CUBIC became the dominant congestion control algorithm, largely because it strikes a practical balance between scalability, fairness, and deployability across modern high-speed Internet paths—especially in Linux-based infrastructure that underpins most servers and CDNs.
How to Identify TCP CUBIC in Wireshark
Short answer: you cannot directly “see” TCP CUBIC as a field or flag in Wireshark. TCP does not signal its congestion control algorithm on the wire. What you can do is infer CUBIC behavior from traffic patterns and graphs—especially the evolution of the congestion window and throughput over time.
When analyzing traffic in Wireshark or similar tools, TCP CUBIC exhibits hopefully recognizable patterns:
- A smooth, curved increase in throughput rather than linear growth
- Periodic drops in throughput when packet loss occurs
- Fewer abrupt oscillations compared to older TCP variants
- Retransmissions and duplicate ACKs signaling congestion events
These patterns reflect the cubic growth model in action.
1) What You’re Really Looking For
TCP CUBIC is a sender-side algorithm, so Wireshark only exposes its effects:
- Congestion window growth pattern (cwnd)
- Throughput evolution
- Loss response behavior
- RTT interaction
The goal is to recognize the signature shape of CUBIC vs other algorithms.
2) The Most Reliable Method: TCP Stream Graphs
Go to:
- Statistics → TCP Stream Graphs → Time-Sequence (tcptrace)
- Statistics → TCP Stream Graphs → Throughput
- Statistics → TCP Stream Graphs → Round Trip Time
3) Key Visual Signature of TCP CUBIC
A. Cubic Growth Shape (Not Linear)
Unlike Reno/NewReno:
- Reno → linear increase (straight line)
- CUBIC → curved (cubic) increase
What you’ll observe:
- Slow increase near previous peak
- Faster growth after passing prior max
- Smooth curvature (not straight ramp)
B. Plateau Near Previous Maximum
CUBIC intentionally slows down near the last congestion point.
In graphs: You’ll see a flattening region before growth accelerates again. This is a strong indicator of CUBIC behavior
C. Less RTT Bias
Compare multiple flows:
- Reno: shorter RTT flows dominate
- CUBIC: flows are more balanced
In practice: Similar throughput across flows with different RTTs suggests CUBIC
D. Loss Events and Recovery
Look for:
- Packet loss (retransmissions / duplicate ACKs)
- Followed by:
- Drop in throughput
- Then curved recovery, not linear
This recovery curve is a key differentiator.
4) Compare Against Other Algorithms
TCP Reno / NewReno Signature
- Linear cwnd growth
- Classic “sawtooth” pattern
- Sharp drop → linear ramp
TCP CUBIC Signature
- Smooth, curved growth
- Plateau near previous max
- Faster scaling after recovery
TCP BBR Signature (for contrast)
- Very stable throughput
- Minimal retransmissions
- No classic sawtooth or cubic curve
- Pacing behavior instead of burst growth
5) Packet-Level Indicators (Supporting Evidence)
While not definitive alone, these help reinforce your conclusion:
- Retransmissions present → likely loss-based (CUBIC or Reno)
- Burst/idle download patterns (e.g., streaming)
- Throughput variability tied to loss events
Display filters that can be helpful:
tcp.analysis.retransmission
tcp.analysis.fast_retransmission
tcp.analysis.duplicate_ack
6) Advanced Method: Estimate Congestion Window Behavior
If you want to go deeper:
- Use Wireshark’s Time-Sequence Graph (Stevens)
- Track:
- Bytes in flight
- ACK spacing
- Approximate cwnd growth over time
You’re effectively reverse-engineering sender behavior from observed ACK dynamics.
7) Practical Reality (Important)
In production troubleshooting the truth is you will rarely “prove” CUBIC definitively. It is certainly possible, however, and you build confidence based on behavior patterns. Keep in mind the following strong indicators:
- Linux-based sender (very common)
- Loss-driven rate changes
- Cubic-shaped throughput growth
Final Perspective
TCP CUBIC represents a critical evolution of TCP congestion control, enabling the Internet to scale to modern bandwidth demands without requiring fundamental protocol changes.
It achieves this by:
- Using a time-based cubic growth function
- Improving fairness across diverse network conditions
- Delivering stable and efficient performance at scale
While newer algorithms are emerging, TCP CUBIC remains the backbone of Internet transport behavior today—quietly powering everything from web browsing to large-scale video streaming. TCP CUBIC is the most common congestion control algorithm today because it delivers:
- Scalability for modern high-speed networks
- Fairness across diverse RTT conditions
- Compatibility with the existing Internet
- Massive deployment via Linux defaults
- Operational stability across real-world conditions
It is not the most advanced algorithm—but it is the most practically successful one, which is why it still underpins a significant portion of Internet traffic today.
Comments are welcomed below from registered users. You can also leave comments at our Discord server.
If you would like to see more content and articles like this, please support us by clicking the patron link where you will receive free bonus access to courses and more, or simply buying us a cup of coffee!