On the Performance of TCP implementations of Linux and Windows

Question

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?

Solution 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.

Solution 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.

Comments

[AIB]

The network scenario is congested 100Mbps LAN with 1000 Odd computers.Internet connectivity via proxy server.Some of the PCs are linux, while most are windows based. It appears that browsing through Linux is faster. I was trying to rationalize this observation

[haimg]

Without measuring, and without seeing what's really going on on your network, it's hard to say. But I think the chance that it's the difference in the TCP congestion algorithms is pretty low, especially if your network is not 100% congested all the time. There are many other factors that can affect browsing speed.

[Cees Timmerman]

Remy should be at least 20% faster than patent-encumbered Compound TCP.