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
TCP CONGESTION ALGORITHMS:
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
Descriptions:
Tahoe:
Limits unknown packets being received. Limits the congestion window, and reset itself to a slow-start state.
Reno:
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.
Vegas:
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.
Hybla:
Penalizes connections that use satellite radio. Not usually used with phones.
Cubic:
One of the best, most recommended TCP options available. Less aggressive, Inflects the windows prior to the event. Used in Linux.
Westwood/Westwood+:
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:
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.
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:
Veno is closely related to Vegas, it is a combination of Vegas and Reno in order to enhance TCP performance over Wireless networks.
Illinois:
Veno is closely related to Vegas, it is a combination of Vegas and Reno in order to enhance TCP performance over Wireless networks.
Illinois:
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):
Yeah-TCP:
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.
CDG
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
cubic:
1st run: 15ms - 10,75Mbps - 7,82Mbps
2nd run: 14ms - 10,84Mbps - 8,06Mbps
reno:
1st run: 13ms - 15,51Mbps - 6,73Mbps
2nd run: 13ms - 14,73Mbps - 8,51Mbps
bic:
1st run: 12ms - 10,38Mbps - 8,61Mbps
2nd run: 13ms - 10,78Mbps - 8,62Mbps
westwood:
1st run: 11ms - 17,65Mbps - 8,30Mbps
2nd run: 13ms - 13,28Mbps - 8,29Mbps
highspeed:
1st run: 13ms - 10,76Mbps - 7,94Mbps
2nd run: 16ms - 14,42Mbps - 8,52Mbps
hybla:
1st run: 14ms - 11,19Mbps - 7,44Mbps
2nd run: 14ms - 13,47Mbps - 7,56Mbps
htcp:
1st run: 14ms - 13,24Mbps - 7,03Mbps
2nd run: 15ms - 10,85Mbps - 8,00Mbps
vegas:
1st run: 14ms - 8,49Mbps - 6,62Mbps
2nd run: 14ms - 12,00Mbps - 7,07Mbps
veno:
1st run: 13ms - 9,58Mbps - 8,13Mbps
2nd run: 13ms - 8,50Mbps - 7,64Mbps
scalable:
1st run: 18ms - 12,01Mbps - 8,73Mbps
2nd run: 14ms - 13,96Mbps - 8,23Mbps
lp:
1st run: 14ms - 14,90Mbps - 8,68Mbps
2nd run: 14ms - 13,44Mbps - 8,72Mbps
yeah:
1st run: 14ms - 13,37Mbps - 8,28Mbps
2nd run: 17ms - 13,89Mbps - 8,14Mbps
illinois:
1st run: 13ms - 12,93Mbps - 8,24Mbps
2nd run: 16ms - 13,97Mbps - 6,46Mbps
Latency
Best<=======================================================>Worst
Aggressiveness (This is still a WIP)
Least<======================================================>Most
Cubic < Yeah < LP < Hybla < Veno < Vegas < Illinois < Bic < Reno < Westwood < HTCP < Highspeed < Scalable
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: http://forum.xda-developers.com/showpost.php?p=48088128&postcount=1884 , MBQ_ Source: http://forum.xda-developers.com/nexus-4/general/info-mbqs-cpu-guide-thread-tips-io-t2429096, and Franciscofranco http://forum.xda-developers.com/showpost.php?p=28152737&postcount=2, richteralan: http://forum.xda-developers.com/showpost.php?p=36663293&postcount=27, and of course, wikipedia
CDG
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.
Benchmark
Results:Latency - Download - Upload
cubic:
1st run: 15ms - 10,75Mbps - 7,82Mbps
2nd run: 14ms - 10,84Mbps - 8,06Mbps
reno:
1st run: 13ms - 15,51Mbps - 6,73Mbps
2nd run: 13ms - 14,73Mbps - 8,51Mbps
bic:
1st run: 12ms - 10,38Mbps - 8,61Mbps
2nd run: 13ms - 10,78Mbps - 8,62Mbps
westwood:
1st run: 11ms - 17,65Mbps - 8,30Mbps
2nd run: 13ms - 13,28Mbps - 8,29Mbps
highspeed:
1st run: 13ms - 10,76Mbps - 7,94Mbps
2nd run: 16ms - 14,42Mbps - 8,52Mbps
hybla:
1st run: 14ms - 11,19Mbps - 7,44Mbps
2nd run: 14ms - 13,47Mbps - 7,56Mbps
htcp:
1st run: 14ms - 13,24Mbps - 7,03Mbps
2nd run: 15ms - 10,85Mbps - 8,00Mbps
vegas:
1st run: 14ms - 8,49Mbps - 6,62Mbps
2nd run: 14ms - 12,00Mbps - 7,07Mbps
veno:
1st run: 13ms - 9,58Mbps - 8,13Mbps
2nd run: 13ms - 8,50Mbps - 7,64Mbps
scalable:
1st run: 18ms - 12,01Mbps - 8,73Mbps
2nd run: 14ms - 13,96Mbps - 8,23Mbps
lp:
1st run: 14ms - 14,90Mbps - 8,68Mbps
2nd run: 14ms - 13,44Mbps - 8,72Mbps
yeah:
1st run: 14ms - 13,37Mbps - 8,28Mbps
2nd run: 17ms - 13,89Mbps - 8,14Mbps
illinois:
1st run: 13ms - 12,93Mbps - 8,24Mbps
2nd run: 16ms - 13,97Mbps - 6,46Mbps
Recommendations:
For speed:
- Westwood - Best
- Highspeed
- LP
- Westwood - Best
- Highspeed
- LP
For stability:
- Cubic - Best
- Cubic - Best
- Reno
For high latency networks:
- Westwood - Best
- BIC
For general usage:
- Cubic - Best
- Westwood - Best
- Reno
- Reno
Comparison:
Download/Upload performance:
Best<=======================================================>Worst
Westwood > Reno > LP > Yeah > Illinois > Scalable > Hybla > Highspeed > HTCP > Cubic > Bic > Vegas > Veno
Latency
Best<=======================================================>Worst
Westwood > Bic > Reno > Veno > LP > Hybla > Vegas > HTCP > Cubic > Yeah > Highspeed > Illinois > Scalable
Aggressiveness (This is still a WIP)
Least<======================================================>Most
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.
Conclusion:
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: http://forum.xda-developers.com/showpost.php?p=48088128&postcount=1884 , MBQ_ Source: http://forum.xda-developers.com/nexus-4/general/info-mbqs-cpu-guide-thread-tips-io-t2429096, and Franciscofranco http://forum.xda-developers.com/showpost.php?p=28152737&postcount=2, richteralan: http://forum.xda-developers.com/showpost.php?p=36663293&postcount=27, and of course, wikipedia
Good to know that i'm using westwood. Great article!
ReplyDeletethanx 4 info
ReplyDeleteThank 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.
ReplyDeleteReally nice article, it helps to underestand how it works and what's the better option!
ReplyDeleteThanks for the efforts
Thank you for the post
ReplyDelete�� great article, less reading more learning, compare to wiki
ReplyDeletethank you
Thanks for providing all this amazing information.
ReplyDeleteNice... I like it. Professional..
ReplyDeleteGreat article thanks so muchos forma this mate
ReplyDeleteWaw very cool article hope you will do articles which deal with TCP Optimisation !!!
ReplyDeleteThanks for helping me make an informed choice when it comes to TCP congestion algorithms
ReplyDeleteThanks!
ReplyDeleteThank you very much for making all of this actually make sense. That's a unique and specific skill-set. Well done and thank you.
ReplyDeleteNice :D
ReplyDeleteThanks for the efforts xD
Really nice....helped me to decide which one to use..
ReplyDeleteThank 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 .
ReplyDeletenice article, it sheds more information on TCP congestion with just little words
ReplyDeletenagle algorithm? This is not part of the list, why?
ReplyDeleteI like how you get right to the point with the relevant details. Thanks!
ReplyDeleteI'm not surprised.
ReplyDeletegood work
ReplyDelete