TCP Congestion Control or Why speed jumps
Hello!
Have you ever had such a thing that you put a file on a download, and the speed slowly but surely increases, then, at some point, decreases sharply, then increases again? Downloading a file in one stream does not provide the full speed of the channel? Start a torrent client, and ping in the game jumps heavily? Do you use a 3G modem (or another line with relatively large packet loss) and can not tolerate it?
Surely you blamed your router or blamed your provider for the shaper setting curve? This affects, but they are not to blame.
So, meet:
In short, the algorithms that are trying to do everything possible to ensure the fastest data transfer rate between two nodes that transmit data via TCP. They control the size of TCP windows and can be guided by RTT (Round Trip Time - the time from sending a request to receiving a response), the loss of packets, the waiting time for sending a packet from a queue, etc. Each algorithm behaves differently in this or that situation and there is no universal one.
')
For a long time, Reno algorithms, developed in 1990, and BIC were in use. The first was used in all Windows operating systems before XP, and the second in Linux up to 2.6.18. Then, in Windows Vista, the new Compound TCP algorithm appeared, and in Linux they changed BIC to Cubic.
There are a lot of them. In the Linux 3.7 kernel there are:
BIC, CUBIC, Highspeed, H-TCP, NewReno, Illinois - these algorithms are designed for the so-called long fat networks - long (and therefore high RTT) and fast networks. TCP Hybla behaves well on satellite links, and Veno is designed for high packet loss wireless networks. TCP Low Priority is generally difficult to call the congestion algorithm, since it does little, but simply tries to send a packet without a queue, TCP Vegas is sometimes used on servers with a large number of connections, because it provides almost constant speed, although far from ideal. Westwood + is a combined algorithm, YeAH-TCP is the youngest of them, but the most interesting, because behaves more or less in all cases.
More details about the algorithms themselves can be found in the post casperrr
Unfortunately, CUBIC, which is used by default in all distributions, is completely inappropriate, for example, for 3G connections. Below is a graph comparing 4 congestion avoidance algorithms for HSDPA networks for the end of 2012 from TCP Congestion Control over HSDPA: an Experimental Evaluation :
As you can see, CUBIC is lagging behind. It has significantly increased RTT on the full utilization of the 3G channel, while Westwood + and NewReno are more or less coping with this problem.
Let's take a look at the number of retransmissions:
As you can see from the graph, CUBIC has a relatively large number of retransmissions.
At the same time, it leads the data transfer rate per unit of time.
What does it mean? This means that using Westwood + or NewReno you can more comfortably surf the Internet while you are downloading a large file.
The test is taken from the Comparative Performance Evaluation of the VMAs in WiMAX (and WLANs) Network Configurations - another interesting comparison of algorithms for wireless networks.
In test # 1, a computer-wimax.rother-wimax.client connection is used with a bandwidth between a computer and a 100 Mbps router and a RTT of 45 ms and a DL: UL ratio of 1: 1 between the wimax router and client.
Dependence of effective data transfer on packet loss:
Slightly change the test. In test number 2, the computer-router1-router2-wimax.router-wimax.client scheme is used, where the RTT is 10 ms. between the computer and the first router, then a 10 Mbps channel with 25 ms is used. RTT, between the second and wimax router, the channel is again 100 Mb / s with RTT at 10 ms.
As can be seen from the graphs, Westwood holds the lead.
The picture for WiFi is similar to WiMAX:
This test is taken from the technical report of the YeAH-TCP algorithm for 2006. Theoretically, YeAH is the most advanced algorithm and aims to work as best as possible on high-speed lines, on lines with high latency or high packet loss.
Tests were done using a channel bandwidth of 500 mbit / s
YeAH leads in efficient data transfer based on RTT
Dependence of effective data transfer and packet loss, again YeAH ranks first
Unfortunately, there are some problems with YeAH on the kernel 3.7, after a while it weighs the software interrupt system. This behavior is not observed at 3.6.
Changing the Congestion Algorithm is quite simple, just one line:
Where instead of westwood you can insert titles from /lib/modules/.../kernel/net/ipv4/tcp_....ko without the tcp_ prefix.
On channels like home wifi, I recommend using Westwood or H-TCP. For wired channels, YeAH can be a good choice (if you are not experiencing problems with it), H-TCP or Illinois.
Some tips. If you already have a 3.6+ kernel, be sure to enable net.ipv4.tcp_fastopen. This will not add any problems with incompatible servers, and handshake for supported ones will speed up.
I also recommend setting net.ipv4.tcp_slow_start_after_idle to 0, this will add speed for SPDY and other keep-alive connections.
Have you ever had such a thing that you put a file on a download, and the speed slowly but surely increases, then, at some point, decreases sharply, then increases again? Downloading a file in one stream does not provide the full speed of the channel? Start a torrent client, and ping in the game jumps heavily? Do you use a 3G modem (or another line with relatively large packet loss) and can not tolerate it?
Surely you blamed your router or blamed your provider for the shaper setting curve? This affects, but they are not to blame.
So, meet:
TCP Congestion Control, or TCP Congestion Avoidance Algorithm.
What it is?
In short, the algorithms that are trying to do everything possible to ensure the fastest data transfer rate between two nodes that transmit data via TCP. They control the size of TCP windows and can be guided by RTT (Round Trip Time - the time from sending a request to receiving a response), the loss of packets, the waiting time for sending a packet from a queue, etc. Each algorithm behaves differently in this or that situation and there is no universal one.
')
For a long time, Reno algorithms, developed in 1990, and BIC were in use. The first was used in all Windows operating systems before XP, and the second in Linux up to 2.6.18. Then, in Windows Vista, the new Compound TCP algorithm appeared, and in Linux they changed BIC to Cubic.
What are the algorithms?
There are a lot of them. In the Linux 3.7 kernel there are:
- BIC TCP
- CUBIC TCP
- Highspeed tcp
- H-TCP
- TCP Hybla
- TCP Illinois
- TCP Low Priority
- TCP Vegas
- TCP NewReno
- TCP Veno
- TCP Westwood +
- YeAH-TCP
BIC, CUBIC, Highspeed, H-TCP, NewReno, Illinois - these algorithms are designed for the so-called long fat networks - long (and therefore high RTT) and fast networks. TCP Hybla behaves well on satellite links, and Veno is designed for high packet loss wireless networks. TCP Low Priority is generally difficult to call the congestion algorithm, since it does little, but simply tries to send a packet without a queue, TCP Vegas is sometimes used on servers with a large number of connections, because it provides almost constant speed, although far from ideal. Westwood + is a combined algorithm, YeAH-TCP is the youngest of them, but the most interesting, because behaves more or less in all cases.
More details about the algorithms themselves can be found in the post casperrr
3G test
Unfortunately, CUBIC, which is used by default in all distributions, is completely inappropriate, for example, for 3G connections. Below is a graph comparing 4 congestion avoidance algorithms for HSDPA networks for the end of 2012 from TCP Congestion Control over HSDPA: an Experimental Evaluation :
As you can see, CUBIC is lagging behind. It has significantly increased RTT on the full utilization of the 3G channel, while Westwood + and NewReno are more or less coping with this problem.
Let's take a look at the number of retransmissions:
As you can see from the graph, CUBIC has a relatively large number of retransmissions.
At the same time, it leads the data transfer rate per unit of time.
What does it mean? This means that using Westwood + or NewReno you can more comfortably surf the Internet while you are downloading a large file.
WiMAX and WiFi channels test
The test is taken from the Comparative Performance Evaluation of the VMAs in WiMAX (and WLANs) Network Configurations - another interesting comparison of algorithms for wireless networks.
In test # 1, a computer-wimax.rother-wimax.client connection is used with a bandwidth between a computer and a 100 Mbps router and a RTT of 45 ms and a DL: UL ratio of 1: 1 between the wimax router and client.
Dependence of effective data transfer on packet loss:
Slightly change the test. In test number 2, the computer-router1-router2-wimax.router-wimax.client scheme is used, where the RTT is 10 ms. between the computer and the first router, then a 10 Mbps channel with 25 ms is used. RTT, between the second and wimax router, the channel is again 100 Mb / s with RTT at 10 ms.
As can be seen from the graphs, Westwood holds the lead.
The picture for WiFi is similar to WiMAX:
High Speed Channel Test
This test is taken from the technical report of the YeAH-TCP algorithm for 2006. Theoretically, YeAH is the most advanced algorithm and aims to work as best as possible on high-speed lines, on lines with high latency or high packet loss.
Tests were done using a channel bandwidth of 500 mbit / s
YeAH leads in efficient data transfer based on RTT
Dependence of effective data transfer and packet loss, again YeAH ranks first
Unfortunately, there are some problems with YeAH on the kernel 3.7, after a while it weighs the software interrupt system. This behavior is not observed at 3.6.
How to change?
Changing the Congestion Algorithm is quite simple, just one line:
sysctl -w net.ipv4.tcp_congestion_control=westwood
Where instead of westwood you can insert titles from /lib/modules/.../kernel/net/ipv4/tcp_....ko without the tcp_ prefix.
Instead of conclusion
On channels like home wifi, I recommend using Westwood or H-TCP. For wired channels, YeAH can be a good choice (if you are not experiencing problems with it), H-TCP or Illinois.
Some tips. If you already have a 3.6+ kernel, be sure to enable net.ipv4.tcp_fastopen. This will not add any problems with incompatible servers, and handshake for supported ones will speed up.
I also recommend setting net.ipv4.tcp_slow_start_after_idle to 0, this will add speed for SPDY and other keep-alive connections.
Source: https://habr.com/ru/post/168407/
All Articles