Which Version of TCP are you using?

So often in Wireshark videos and classes we spend a lot of time on TCP behavior. But what I am about to discuss is hardly ever brought up.

The answer to version is simple right? Version 4.

OK, kind of right, but overlooking too much. The truth is that there are multiple “versions” of TCP, and TCP does not have a version number in its header:

OK, so what are these different – let’s call them implementations – of TCP? Here they are:

Now, I highlight TCP CUBIC, New Reno, and Compound TCP as the most common, but that is not the whole and perfect truth.

Also, looking at a Wireshark capture, Wireshark has no way to identify these different TCP implementations.

Let me explain.

TCP Reno was once the default congestion control algorithm in many operating systems, but over time, most modern operating systems have shifted to newer and more efficient algorithms like TCP New Reno and CUBIC (especially for high-speed and high-latency networks). However, some operating systems and network setups may still support TCP Reno or have it as an optional setting.

Historically, the following operating systems defaulted to TCP Reno:

1. Linux (pre-2.6.8 kernel):
   • Early versions of the Linux kernel (before version 2.6.8) used TCP Reno as the default congestion control algorithm. However, after the release of Linux kernel 2.6.8, TCP Reno was replaced by TCP BIC, which was later replaced by TCP CUBIC (from Linux kernel 2.6.19 onwards), making TCP CUBIC the default in most modern Linux distributions.
2. BSD (FreeBSD, OpenBSD, NetBSD):
   • The BSD family of operating systems (such as FreeBSD, OpenBSD, and NetBSD) originally defaulted to TCP Reno in earlier releases. However, they have since adopted TCP New Reno as the default algorithm in later versions.
   • FreeBSD and OpenBSD both support TCP Reno, but newer versions typically use TCP New Reno as the default.
3. Windows (Early Versions):
   • Earlier versions of Microsoft Windows (e.g., Windows 2000 and Windows XP) used TCP Reno by default. However, with later versions like Windows Vista and beyond, Microsoft introduced Compound TCP (CTCP), which became the default congestion control algorithm for modern Windows systems.

Current State:

Most modern operating systems, including Linux, FreeBSD, macOS, and Windows, no longer default to TCP Reno. Instead, they use algorithms that perform better in modern network environments. For example:

• Linux: Defaults to TCP CUBIC in most distributions.
• Windows: Uses Compound TCP.
• macOS and iOS: Use TCP New Reno or a modified version of it.

Even though TCP Reno is no longer the default in most modern systems, it is still supported as a selectable option. For example, in Linux, you can switch to TCP Reno by running the command:

sudo sysctl -w net.ipv4.tcp_congestion_control=reno

Therefore, while TCP Reno was historically the default, most modern operating systems have moved to more advanced congestion control algorithms like TCP New Reno, TCP CUBIC, or CTCP.

This begs the question: do these implementations interoperate, and if so, how?

Yes, TCP CUBIC, TCP New Reno, and Compound TCP (CTCP) can interoperate on the same network, meaning devices using these different congestion control algorithms can communicate with each other successfully. All of these algorithms are variations of TCP, which means they adhere to the same fundamental protocol rules, allowing interoperability. However, they have different approaches to congestion control, which may affect how they share bandwidth and network resources.

How TCP CUBIC, TCP New Reno, and Compound TCP interoperate:

1. Congestion Control is Sender-Side:
   • TCP congestion control algorithms like CUBIC, New Reno, and Compound TCP operate at the sender side of a connection. They determine how fast the sender transmits data based on network conditions like packet loss or delay.
   • The receiver’s role is primarily to acknowledge data packets, and it doesn’t need to be aware of the specific congestion control algorithm the sender is using. This means that one side of a connection could be using TCP New Reno while the other side uses TCP CUBIC or Compound TCP without issues.
2. Coexistence and Fairness:
   • TCP CUBIC: The default algorithm in most modern Linux systems, TCP CUBIC is optimized for high-bandwidth, high-latency networks. It increases its congestion window more aggressively than older algorithms like TCP New Reno.
   • TCP New Reno: A widely used algorithm, TCP New Reno is more conservative and gradually increases the congestion window size based on packet loss. It has been standard for a long time and is still commonly used in various systems.
   • Compound TCP (CTCP): The default algorithm in modern Windows systems, CTCP is a hybrid algorithm that combines both loss-based and delay-based congestion control. It can scale well in high-bandwidth environments but is less aggressive than CUBIC.
   While these algorithms can coexist on the same network, fairness becomes an important consideration. Fairness refers to how these algorithms share bandwidth when competing for network resources:
   • TCP CUBIC is more aggressive than TCP New Reno and Compound TCP, especially in high-speed, long-delay environments. It may grab more bandwidth than New Reno and CTCP in such situations.
   • TCP New Reno is less aggressive in increasing its congestion window size, so in high-bandwidth networks, it may receive less bandwidth compared to CUBIC or CTCP.
   • Compound TCP balances loss-based and delay-based congestion control, making it less aggressive than CUBIC but more adaptive than New Reno. In certain networks, especially those with lower capacity or higher delay, CTCP may perform better than TCP New Reno but could still be outperformed by CUBIC in high-speed scenarios.
3. How They Interoperate in Practice:
   • No Coordination Required: TCP CUBIC, TCP New Reno, and Compound TCP do not need explicit coordination to interoperate. They all comply with the fundamental rules of TCP, such as packet acknowledgment, retransmission, and flow control. The only difference is how they handle congestion, which is independent of the receiver.
   • Bandwidth Sharing: In a congested network where flows using these different algorithms coexist, they will share bandwidth, but not necessarily equally. TCP CUBIC, being more aggressive, may take more bandwidth in certain conditions. Compound TCP’s hybrid approach may allow it to adapt better than New Reno in some situations, but New Reno’s conservative behavior may put it at a disadvantage in terms of throughput.
4. Performance Differences:
   • TCP CUBIC: Performs better in high-speed, long-distance networks (e.g., data centers or wide-area networks). It’s optimized for large-bandwidth environments and may dominate bandwidth when competing with New Reno or CTCP.
   • TCP New Reno: More conservative and slower to recover from packet loss. It may not perform as well as CUBIC or CTCP in high-capacity networks, but it works well in traditional or congested environments.
   • Compound TCP: A middle-ground approach that performs well in both low- and high-capacity networks. Its hybrid nature allows it to adapt better than New Reno, but it may not always compete evenly with CUBIC.

Summary of Interoperability:

• TCP CUBIC, TCP New Reno, and Compound TCP can interoperate without any issues because they all follow TCP protocol standards for reliable data transmission. The choice of congestion control algorithm only affects how the sender adjusts its transmission rate in response to network conditions.
• Fairness: CUBIC tends to be more aggressive than both New Reno and Compound TCP, which could result in CUBIC taking more bandwidth in high-speed networks. Compound TCP may perform better than New Reno due to its hybrid approach, but it is generally less aggressive than CUBIC.
• In Practice: They coexist well on the same network, but their differences in how they handle congestion could lead to unequal bandwidth sharing, with CUBIC often having an advantage in high-bandwidth, low-congestion environments.

Despite these performance differences, the algorithms all work together without breaking the connection or requiring special configuration, ensuring smooth interoperability.

As you can see, this is a complicated mess, especially for service providers to explain away issues like speed testing that all seem to use TCP (see my article on this issue here).

Anyway, I hope this helps.

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!