TCP Algorithms

TCP algorithms (Updated: 29/10/15)

Recommended apps for manipulating kernel values:
1. Kernel Adiutor (Free to change TCP algorithm)
2. Kernel Adiutor-Mod (Free to change TCP algorithm)
3. Compatible kernel managers (e.g Stweaks, Synapse, UKM, etc.)

This page includes:

- Introduction
- Descriptions
- Benchmarking
- Comparison
- Conclusion


Congestion control strategies (or algorithms) are used by TCP, the data transmission protocol used by many Internet applications. The main goal of a TCP algorithm is to avoid sending more data than the network is capable of transmitting, that is, to avoid causing network congestion. Different algorithms respond differently to network loads, but they are all based on the same principle of avoiding network congestion. 

Things to look out for in TCP algorithms include (but not exclusively):
- Download/Upload speeds - The higher the number, the better
- Latency - The lower the number, the better



Limits unknown packets being received. Limits the congestion window, and reset itself to a slow-start state.


Basically the same as Tahoe, but if 3 of the same packets are received, it will halve the window, instead of reducing it to one. It changes the slow start threshold equal to that of the congestion window.


One of the smoothest TCP algorithms(next to cubic), it increases the timeout delay for packets, which allows more to be received, but at a higher rate. It also has set timeouts, which helps with speed because it's constantly being refreshed.


Penalizes connections that use satellite radio. Not usually used with phones.


One of the best, most recommended TCP options available. Less aggressive, Inflects the windows prior to the event. Used in Linux.


A newer version of Reno, and another commonly used one. It controls parameters better, helping out streaming and overall quality of browsing the internet. One of the most 'fair' algorithms out there, and is one of the most efficient algorithms to date. 

Low Priority (LP):

A distributed algorithm whose goal is to utilize only the excess network bandwidth as compared to the "fair share" of bandwidth as targeted by TCP. The key mechanisms unique to TCP-LP congestion control are the use of one-way packet delays for early congestion indications and a TCP-transparent congestion avoidance policy.

Binary Increase Congestion control (BIC):

BIC is optimized for high speed networks with high latency: so-called "long fat networks". It has a unique congestion window (cwnd) algorithm. This algorithm tries to find the maximum where to keep the window at for a long period of time, by using a binary search algorithm.


Scalable calls for congestion window to be halved for each packet lost. Effectively, this process keeps halving the throughput until packet loss stops. Once the packet loss subsides, slow start kicks in to ramp the speed back up. 

Hamilton TCP (HTCP):

HTCP is designed for high-speed, long distance networks that increases aggressiveness as the time since the previous loss increases. It is thought to be a more efficient TCP algorithm than BIC and HSTCP. 


Veno is closely related to Vegas, it is a combination of Vegas and Reno in order to enhance TCP performance over Wireless networks. 


Illinois is designed for high-speed, long-distance networks. A sender side modification to the standard TCP congestion control algorithm, it achieves a higher average throughput than the standard TCP and allocates the network resource fairly as the standard TCP.

High speed (HSTCP):

High Speed TCP (HSTCP) is a new congestion control algorithm protocol for TCP. Standard TCP performs poorly in networks with a large bandwidth delay product. It is unable to fully utilize available bandwidth. HSTCP makes minor modifications to standard TCP's congestion control mechanism to overcome this limitation.


A high speed TCP congestion control algorithm which uses a mixed loss/delay approach to calculate congestion windows. Its purpose is to target high efficiency, fairness, and minimizing link loss while keeping network elements load as low as possible.


CAIA-Delay Gradient (CDG) is a new hybrid congestion control algorithm which reacts to both packet loss and queuing delay. It attempts to operate as a delay-based algorithm where possible, but detects loss-based TCP traffic and will switch if required. CDG performs similarly to NewReno and Cubic, but is better at latency. 



Latency - Download - Upload

1st run: 15ms - 10,75Mbps - 7,82Mbps
2nd run: 14ms - 10,84Mbps - 8,06Mbps

1st run: 13ms - 15,51Mbps - 6,73Mbps
2nd run: 13ms - 14,73Mbps - 8,51Mbps

1st run: 12ms - 10,38Mbps - 8,61Mbps
2nd run: 13ms - 10,78Mbps - 8,62Mbps

1st run: 11ms - 17,65Mbps - 8,30Mbps
2nd run: 13ms - 13,28Mbps - 8,29Mbps

1st run: 13ms - 10,76Mbps - 7,94Mbps
2nd run: 16ms - 14,42Mbps - 8,52Mbps

1st run: 14ms - 11,19Mbps - 7,44Mbps
2nd run: 14ms - 13,47Mbps - 7,56Mbps

1st run: 14ms - 13,24Mbps - 7,03Mbps
2nd run: 15ms - 10,85Mbps - 8,00Mbps

1st run: 14ms - 8,49Mbps - 6,62Mbps
2nd run: 14ms - 12,00Mbps - 7,07Mbps

1st run: 13ms - 9,58Mbps - 8,13Mbps
2nd run: 13ms - 8,50Mbps - 7,64Mbps

1st run: 18ms - 12,01Mbps - 8,73Mbps
2nd run: 14ms - 13,96Mbps - 8,23Mbps

1st run: 14ms - 14,90Mbps - 8,68Mbps
2nd run: 14ms - 13,44Mbps - 8,72Mbps

1st run: 14ms - 13,37Mbps - 8,28Mbps
2nd run: 17ms - 13,89Mbps - 8,14Mbps

1st run: 13ms - 12,93Mbps - 8,24Mbps
2nd run: 16ms - 13,97Mbps - 6,46Mbps


For speed:
- Westwood - Best
- Highspeed
- LP

For stability:
- Cubic - Best
- Reno

For high latency networks:
- Westwood - Best

For general usage:
- Cubic - Best
- Westwood - Best
- Reno


Download/Upload performance: 

Westwood > Reno > LP > Yeah > Illinois > Scalable > Hybla > Highspeed > HTCP > Cubic > Bic > Vegas > Veno



Westwood > Bic > Reno > Veno > LP > Hybla > Vegas > HTCP > Cubic > Yeah > Highspeed  > Illinois > Scalable 

Aggressiveness (This is still a WIP)

Cubic < Yeah < LP  < Hybla < Veno < Vegas < Illinois  < Bic Reno Westwood < HTCP Highspeed  < Scalable 

According to the comparison, it appears that "westwood" and "reno" are the most promising TCP congestion algorithms. 


The only TCP algorithms I would recommend are Cubic or Westwood as they are the most stable and efficient for mobile devices. Real world usage would show little difference when comparing between algorithms, so everyone's experience will vary! There are myths that changing algorithms will affect battery life, this is not true!!!!!

Also, don't be surprised if you end up using Cubic or Westwood!

All credits go to lucius.zen. Source: , MBQ_ Source:, and Franciscofranco, richteralan:, and of course, wikipedia


  1. Good to know that i'm using westwood. Great article!

  2. Thank you, truly appreciate the straightforward verbiage and time taken in comparisons, not to mention personal input concerning battery life, you saved me a lot of busy work.

  3. Really nice article, it helps to underestand how it works and what's the better option!

    Thanks for the efforts

  4. �� great article, less reading more learning, compare to wiki

    thank you

  5. Thanks for providing all this amazing information.

  6. Nice... I like it. Professional..

  7. Great article thanks so muchos forma this mate

  8. Waw very cool article hope you will do articles which deal with TCP Optimisation !!!

  9. Thanks for helping me make an informed choice when it comes to TCP congestion algorithms

  10. Thank you very much for making all of this actually make sense. That's a unique and specific skill-set. Well done and thank you.

  11. Nice :D
    Thanks for the efforts xD

  12. Really nice....helped me to decide which one to use..

  13. Thank you man. Love reading this blog with the tons of interesting and useful facts/info that one can find here. Lots of love from Hungary .

  14. nice article, it sheds more information on TCP congestion with just little words

  15. nagle algorithm? This is not part of the list, why?

  16. I like how you get right to the point with the relevant details. Thanks!


Post a Comment

Please respect the admin of the website and don't post spam! Spam will be removed through moderation so you will be wasting time if you do so! Post something meaningful that will help the developer or others :) If spam becomes a problem, I will remove the ability to create comments once again.