On the Performance of TCP implementations of Linux and Windows

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.

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.