On the Performance of TCP implementations of Linux and Windows

Question

As I understand the implementation of TCP stack in windows and Linux are different. Windows uses a congestion control algorithm known as the TCP Reno while Linux uses Cubic.

How do the 2 protocols compare when they coexist on the same network? Is it true to say that Cubic(Linux) is more aggressive and might end up getting higher share of bandwidth?

Answer 1

Note that the congestion control algorithm only affects upstream traffic and thus only upstream bandwidth.

That being said, Cubic actually is more aggressive, especially for networks with a high bandwidth delay product. There is even a rule built into the Linux implementation so as to never use a smaller sending rate than reno would in the same situation:

The Linux Cubic algorithm also includes code which ensures that the cubic algorithm is at least as aggressive as standard TCP

-- Leith, Shorten, McCullagh, Experimental evaluation of Cubic-TCP

So, when downloading your Windows updates while watching Youtube Videos, your Youtube traffic might starve your microsoft traffic, and there is nothing you can do about it.

Answer 2

First, what you say is not factually correct:

• Linux up to kernel version 2.6.18 uses BIC by default.
• Linux kernel 2.6.19 and later uses CUBIC by default.
• Linux's TCP congestion control mechanisms are pluggable, e.g. you can change them on the fily.
• Windows XP and earlier uses TCP Reno (or New Reno)
• Windows Vista and later also has Compound TCP, which is enabled by default in Server 2008 and can be enabled in Vista and Windows 7 if needed.

All of these algorithms are self-tuning according to available network bandwidth, latency, available memory, etc. They also have many configuration parameters that let you hand-tune them.

So, you cannot really compare one with the other, without looking at the exact specific network topology, used hardware and software, etc. It's not like one is better than the other, or will use bigger share of the available bandwidth. It is true that CUBIC is less aggressive than BIC, but in practice other considerations are often more important than which flavor of TCP congestion algorithm used.

Unless you're trying to tune to a very narrow-scope and unusual networking scenario, these algorithms all work sufficiently well and fair out of the box.