TCP Optimization & Acceleration

BTA - Bequant TCP Acceleration

The BTA product accelerates TCP traffic flowing through it, resulting in faster downloads and uploads. TCP is the transport protocol most widely used by Internet services and applications. The good design of TCP is one of the reasons behind the success of the Internet, but TCP can still be the throughput bottleneck when there are packet losses, delay jitter or large network latencies, as well as in wireless links. Bequant has a patented TCP implementation (see our granted patent EP3135009) that can increase TCP traffic speeds to over 100% in real applications (not just in lab tests), while avoiding buffer-bloat and packet loss problems.

The Bequant TCP adapts itself to different network conditions thanks to its self-tuning learning algorithm, but is especially suited whenever wireless links are present (WiFi, LTE, 3G, WiMax...), where it performs better than other TCP implementations, including Linux Cubic, Akamai’s FastTCP and Google’s BBR.

Transparent TCP Proxy

As an in-line transparent TCP proxy (as an RFC 3135 Local ACK PEP), the BTA manages to make data appear closer to TCP clients, and closer, with TCP, means faster delivery. Unlike non-transparent HTTP proxies, the BTA does not change IP addresses, TCP ports or TCP sequences, so TCP connections can survive even if data traffic is suddenly routed through a direct path, bypassing the BTA.

Faster TCP Stack

The Bequant TCP stack detects congestion based on the measured delivery rate, as described in our recently granted patent. The most widely used TCP implementation, CUBIC, the current default in Linux, detects congestion with packet losses, but also with measured delay at the connection start. Other widely-used TCP variants in Internet are Google's BBR TCP, which also detects congestion based on delivery rate measurements, and Akamai's FastTCP, mainly based on network delay measurements. Our improved congestion detection algorithm allows our TCP to be more aggressive when there is no congestion and to back off in real congestion, being able to carry out this discrimination in challenging environments: with wireless links, packet losses or large network delays.

Deployment

The BTA runs on the Bequant BQN platform, which can be deployed on off-the-shelf Intel-based servers, virtual machines (KVM or VMware vSphere hypervisors) or integrated into other network equipment blades. Please, see real use cases, results, and implementation details to understand how our BTA product can help.

Acceleration Results in Wireless Networks with no Losses

The Bequant TCP optimization and acceleration solution has been benchmarked against two of the most widely used TCP variants: CUBIC, which is the default TCP in Linux, and the BBR TCP implementation for Linux developed by Google.

The test setup consists of:

Client: Google Chrome browser running on an Android 7.1.2 based mobile phone.

Server: nginx on Linux with a 4.10.3 kernel, with both Cubic and BBR TCP stacks.

Access networks: 4G LTE from Vodafone Spain, and 802.11ac WiFi (Mikrotik hAP ac router) through a 300 Mbps symmetric fiber access from Telefonica.

Router to create Internet-side delay: Linux-based, with netem.

The following chart shows a clear advantage of the Bequant TCP over Cubic and BBR in 4G LTE networks. The Bequant TCP showed no significant increase in retransmissions and only a slight increase in bufferbloat: the average RTT measured from the BQN node to the client went up to around 45ms, while it was around 35ms for BBR and Cubic (the minimum connection RTT was 25ms).

Download speed (in Mbps) with a 4G LTE access network with minimal packet losses, for different download sizes (100 KB in the first row, 1 MB in the second row and 5 MB in the bottom row), and for different Internet-size delays (with no delay in the left column, with 30ms delay in the middle column, and with 100ms delay in the right column).

The Bequant TCP is also superior to the Cubic and BBR variants with 802.11ac WiFi access, via a 300 Mbps symmetric fiber access, as shown in the next chart. In this case, the Bequant TCP also showed no significant increase in retransmissions and only a slight increase in bufferbloat: the average RTT measured from the BQN node to the client went up to around 16ms, while it was around 11ms for BBR and 13ms for Cubic (the minimum connection RTT was 9ms).

Download speed (in Mbps) with an FTTH access network with 802.11ac WiFi and minimal packet losses, for different download sizes (100 KB in the first row, 1 MB in the second row and 5 MB in the bottom row), and for different Internet-size delays (with no delay in the left column, with 30ms delay in the middle column, and with 100ms delay in the right column).

The 0ms Internet-delay results show the behavior of the Bequant TCP as a server stack, while the 30ms and 100ms delay results show the improvements obtained when downloading content from far-away servers through a transparent TCP proxy.

Acceleration Results in Lossy Wireless Networks

The two access networks used in the testing showed minimal packet losses, so 0.5% random packet losses were introduced with a random packet loss generator (netem in a Linux-based router), to study the effects of packet losses on performance.

The test setup consists of:

Client: Google Chrome browser running on an Android 7.1.2 based mobile phone.

Server: nginx on Linux with a 4.10.3 kernel, with both Cubic and BBR TCP stacks.

Access networks: 4G LTE from Vodafone Spain, and 802.11ac WiFi (Mikrotik hAP ac router) through a 300 Mbps symmetric fiber access from Telefonica.

Routers to create Internet-side delay and to inject random packet losses: Linux-based, with netem.

The following chart shows that the advantage of the Bequant TCP over Cubic and BBR remains in 4G LTE networks with losses. The Bequant TCP showed no significant increase in retransmissions over the other variants and the average RTT measured from the BQN node to the client was very similar to that measured without losses.

Download speed (in Mbps) with a 4G LTE access network with 0.5% random packet losses, for different download sizes (100 KB in the first row, 1 MB in the second row and 5 MB in the bottom row), and for different Internet-size delays (with no delay in the left column, with 30ms delay in the middle column, and with 100ms delay in the right column).

With random packet losses, the Bequant TCP is also superior to the Cubic and BBR variants with 802.11ac WiFi access via FTTH, as shown in the next chart. It can be seen that Cubic is especially slow with random losses and large downloads The Bequant TCP also showed no significant increase in retransmissions over the other variants and the average RTT measured from the BQN node to the client was very similar to that measured without losses.

Download speed (in Mbps) with an FTTH access network with 802.11ac WiFi and 0.5% random packet losses, for different download sizes (100 KB in the first row, 1 MB in the second row and 5 MB in the bottom row), and for different Internet-size delays (with no delay in the left column, with 30ms delay in the middle column, and with 100ms delay in the right column).