Jump to content

CUBIC TCP

From Wikipedia, the free encyclopedia
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

CUBIC is a network congestion avoidance algorithm for TCP which can achieve high bandwidth connections over networks more quickly and reliably in the face of high latency than earlier algorithms. It helps optimize long fat networks.[1][2]

In 2006, the first CUBIC implementation was released in Linux kernel 2.6.13.[3] Since kernel version 2.6.19,[4] CUBIC replaces BIC-TCP as the default TCP congestion control algorithm in the Linux kernel.[3]

MacOS adopted TCP CUBIC with the OS X Yosemite release in 2014,[5][6] while the previous release OS X Mavericks still used TCP New Reno.[7][8]

Microsoft adopted it by default in Windows 10.1709 Fall Creators Update (2017), and Windows Server 2016 1709 update.[9]

Characteristics

CUBIC is a less aggressive and more systematic derivative of BIC TCP, in which the window size is a cubic function of time since the last congestion event, with the inflection point set to the window size prior to the event. Because it is a cubic function, there are two components to window growth. The first is a concave portion where the window size quickly ramps up to the size before the last congestion event. Next is the convex growth where CUBIC probes for more bandwidth, slowly at first then very rapidly. CUBIC spends a lot of time at a plateau between the concave and convex growth region which allows the network to stabilize before CUBIC begins looking for more bandwidth.

Another major difference between CUBIC and many earlier TCP algorithms is that it does not rely on the cadence of RTTs to increase the window size.[10] CUBIC's window size is dependent only on the last congestion event. With earlier algorithms like TCP New Reno, flows with very short round-trip delay times (RTTs) will receive ACKs faster and therefore have their congestion windows grow faster than other flows with longer RTTs. CUBIC allows for more fairness between flows since the window growth is independent of RTT.

This RTT-independence is particularly important in modern data centers and cloud environments where flows may traverse paths with vastly different round-trip times. Studies[11][12] have shown that in networks with mixed RTT flows, CUBIC achieves up to 3-5 times better fairness compared to traditional loss-based algorithms like Reno. The RTT-fairness property makes CUBIC especially suitable for Content Delivery Networks (CDNs) and distributed systems where servers at different geographical locations communicate with clients simultaneously.

Algorithm

CUBIC increases its window to be real-time dependent, not RTT dependent like BIC. The calculation for cwnd (congestion window) is simpler than BIC, too.

Define the following variables:

  • β: Multiplicative decrease factor
  • wmax: Window size just before the last reduction
  • T: Time elapsed since the last window reduction
  • C: A scaling constant
  • cwnd: The congestion window at the current time

RFC 8312 indicates the following:

  • The unit of all window sizes in this document is segments of the maximum segment size (MSS), and the unit of all times is seconds. (Section 4)
  • β SHOULD be set to 0.7 (Section 4.5)
  • C SHOULD be set to 0.4 (Section 5)

Then cwnd can be modeled by:

Alternatives

Apart from window based algorithms like Cubic, there are rate based algorithms (including TCP BBR from Google) that works differently using "sending rate" instead of the window.[13] Unlike CUBIC, which relies primarily on packet loss as a congestion signal, BBR uses a model-based approach that estimates the available bandwidth and minimum RTT of the network path.[14] BBR operates by cycling through four states: STARTUP, DRAIN, PROBE_BW, and PROBE_RTT, continuously measuring and adapting to network conditions. The fundamental difference in approach means that BBR can achieve higher throughput in networks with shallow buffers or where random packet loss occurs (such as wireless networks), as it doesn't interpret all losses as congestion signals.[15] However, studies have shown that when BBR flows compete with CUBIC flows, BBR can be more aggressive and may dominate bandwidth allocation.

See also

References

  1. ^ Sangtae Ha; Injong Rhee; Lisong Xu (July 2008). "CUBIC: A New TCP-Friendly High-Speed TCP Variant" (PDF). ACM SIGOPS Operating Systems Review. 42 (5): 64–74. doi:10.1145/1400097.1400105. S2CID 9391153. Archived from the original (PDF) on July 26, 2015. Retrieved September 29, 2015.
  2. ^ Sangtae Ha; Injong Rhee; Lisong Xu; Lars Eggert; Richard Scheffenegger (February 2018). CUBIC for Fast Long-Distance Networks. doi:10.17487/RFC8312. RFC 8312.
  3. ^ a b Ha, Sangtae; Rhee, Injong; Xu, Lisong (2008). "CUBIC: A New TCP-Friendly High-Speed TCP Variant". ACM SIGOPS Operating Systems Review. 42. ACM New York, NY, USA: 11. doi:10.1145/1400097.1400105. S2CID 9391153.
  4. ^ "[TCP]: Make cubic the default · torvalds/Linux@597811e". GitHub.
  5. ^ "apple-oss-distributions/distribution-macOS at os-x-1010". GitHub. TCP Congestion Control is implemented in the XNU Kernel, this commit references the XNU Kernel used in Mac OS X Yosemite
  6. ^ "xnu/tcp_cc.h at a3bb9fcc43a00154884a30c9080595284c26cec9 · apple-oss-distributions/xnu". GitHub. April 29, 2022.Header file of the TCP congestion control implementation of the XNU Kernel used in Mac OS X Yosemite stating CUBIC as default
  7. ^ "apple-oss-distributions/distribution-macOS at os-x-1095". GitHub.References XNU Kernel used in Mac OS X Mavericks
  8. ^ "xnu/tcp_cc.h at d2a0abf2ede8152c5a107fe51e032c1193d2015b · apple-oss-distributions/xnu". GitHub. April 29, 2022. Header file of the TCP congestion control implementation of the XNU Kernel used in Mac OS X Mavericks stating New Reno as default
  9. ^ Microsoft (November 15, 2017). "Updates on Windows TCP" (PDF).
  10. ^ La Rosa, Alexander (10 July 2019). "Why does CUBIC take us back to TCP congestion control?". Pandora FMS. Archived from the original (html) on 12 July 2019. Retrieved 12 July 2019. The intention is to have an algorithm that works with congestion windows whose incremental processes are more aggressive, but are restricted from overloading the network. In order to achieve this, it is proposed that the scheme for increasing and decreasing the transmission ratio be established according to a cubic function.
  11. ^ Ha, Sangtae; Rhee, Injong; Xu, Lisong (July 1, 2008). "CUBIC: a new TCP-friendly high-speed TCP variant". SIGOPS Oper. Syst. Rev. 42 (5): 64–74. doi:10.1145/1400097.1400105. ISSN 0163-5980.
  12. ^ Xu, Lisong; Harfoush, K.; Rhee, Injong (March 2004). "Binary increase congestion control (BIC) for fast long-distance networks". IEEE INFOCOM 2004. 4: 2514–2524 vol.4. doi:10.1109/INFCOM.2004.1354672.
  13. ^ "Congestion control, PK3C Kernel Module rate based for video streaming and data servers". GitHub. Retrieved August 1, 2021.
  14. ^ Cardwell, Neal; Cheng, Yuchung; Gunn, C. Stephen; Yeganeh, Soheil Hassas; Van Jacobson (January 23, 2017). "BBR: congestion-based congestion control". Commun. ACM. 60 (2): 58–66. doi:10.1145/3009824. ISSN 0001-0782.
  15. ^ Hock, Mario; Bless, Roland; Zitterbart, Martina (October 2017). "Experimental evaluation of BBR congestion control". 2017 IEEE 25th International Conference on Network Protocols (ICNP): 1–10. doi:10.1109/ICNP.2017.8117540.
Retrieved from "https://en.wikipedia.org/w/index.php?title=CUBIC_TCP&oldid=1321393884"