TCP Acceleration

In this article, we will discuss some limitations of TCP and why it can be beneficial to optimise TCP to improve network performance (sometimes referred to as TCP Acceleration).  For those that wish to deeply understand TCP itself, there is a wealth of technical information available.

TCP is a layer 4 connection based protocol whereby an initial handshake establishes a connection between a client and server, before data is exchanged.  TCP employs different techniques, such as retransmission, in order to mitigate packetloss and ensure data delivery.  TCP doesn’t care what the underlying network is, it is focused on delivering error-free data, end to end.

TCP is by far the most widely used protocol on the internet, typically in use for 85% of a fixed network and as high as 95%+ on mobile networks.

TCP employs four main techniques to help manage its usage of network, to not overload them by requesting too much bandwidth and how it reacts to congestion, packet loss and latency.

1. Slow start is a way to deliberately slowly start a connection, so that it does not take too much bandwidth and cause congestion itself.
2. Congestion avoidance covers many different RFCs covering various topics, such as loss, or delay and themselves focus on improving loss or bandwidth throughput.
3. Fast retransmit reduces the time to wait when a retransmit is required.
4. Fast recovery works with fast retransmit to help ensure the connection stabilises quickly.

All are defined in detail in RFC-5681. There are a couple of key considerations:

1. For the various algorithms to work, they should be supported by all vendors in the whole end to end connection.
2. Since connections are client, server based, any error and subsequent recovery impacts a large part of the network and is not isolated to only an area experiencing specific problems. For example: last mile packetloss effects the whole flow, since a retransmit must come from the server.

Now let’s consider where a network operator typically has control over their network in the 7-layer OSI model. From the physical building blocks, to routing. Control above these few layers is traditionally very difficult.

In summary, network operators have a situation where 80%+ of traffic is using a protocol they cannot easily control, let alone optimise. Network operators have to hope that the end to end TCP performance is optimised, so their network can deliver efficiently. 

There are two fundamental situations that can occur, either TCP is too slow or it is too fast.

TCP too slow

To avoid TCP being the cause of congestion itself, it is conservative in general. This means that if there is actually spare capacity in a network, TCP may take longer than necessary to reach its maximum possible speed.  Coupled with TCP’s behaviour to back-off in the presence of increases in loss or delay (which it believes is caused by congestion), this can cause the classic TCP bandwidth sawtooth graph of slowly rising up and then almost instantly dropping down. 

TCP too fast

Even though so far, we have discussed TCP being conservative and slow, there are times when it can be too fast. These typically occur before TCP thinks it needs to react and slow down. In this case, TCP can overwhelm network resources and cause what is called “bufferbloat”, when buffers in networks elements become overloaded.  This can have very bad effects on the overloaded elements, particularly causing latency rises.

Another cause of bufferbloat (especially true in mobile networks) are micro-bursts. Whichever way the bufferbloat is caused, it usually causes a congestion event at the TCP layer, backing off bandwidth, before starting the recovery cycle. The overall effect being a slowed down connection and reduced user experience.

TCP will adjust the whole end to end connection according to the weakest link in the chain. 

TCP optimisation (often referred to as TCP Acceleration) enables a network operator to isolate their own part of a TCP connection and optimise it for their own particular network conditions. This means network operators can take control of layer 4, at least for their own network.

TCP Acceleration logically deployed as above can offer the following key benefits:

Accelerate TCP Slow Start to reach maximum speed faster.  The TCP Slow Start virtually guarantees that a Radio Access Network is initially under-utilised. By optimising each network separately, access and internet, the end to end performance is improved. The maximum speed that the Access network can achieve is reached faster and is sustained for longer.

Managing Packetloss in the Access network.  As described above, TCP Congestion Control assumes packetloss equals congestion, but this is not always true in the access network. For example, packetloss may be due to:

• Genuine coverage / interference issues / wi-fi dropping
• Microbursts causing bufferbloat
• Cell handover events

These are NOT TCP congestion events and TCP does not necessarily need to back off. By buffering these events in the TCP Accelerator, the TCP flow can be maintained.

A TCP Accelerator cannot increase the top-line bandwidth speed achievable. Rather, it will improve the efficiency, making better use of network time to transfer more data. This increase in bandwidth efficiency is often referred to as TCP Goodput – the amount of “good throughput” that can be achieved. For lossy networks, Goodput improvements can be truly dramatic.

Managing Congestion in the Access Network. Of course, congestion can sometimes occur in an access network. This usually means that buffers in access equipment are full and packets are being queued.  Packetloss will occur if the buffers cannot store enough packets and drop them instead.

The consequences of the above are seen by an increase in Round Trip Time. This is often an early indicator of congestion. By configuring a TCP Accelerator to prevent buffers filling up, latency can be controlled, packetloss avoided and a more consistent user experience is achieved.

The key of course is to have the ability to control TCP behaviour.

QUIC is a Google designed protocol based on UDP and used by YouTube and some other services on the internet. Since QUIC is not TCP based, it is not coordinated with TCP’s usage and in many cases competes for the same resources, eg buffers and so on.

In the first instance it is wise to analyse QUIC usage on a network, to establish if it could be impacting TCP performance.  If high QUIC usage is observed on a network,  it could be useful to have the ability to control QUIC as well as Accelerate TCP.

 The impact of TCP Acceleration on a network depends mainly on the two network KPIs:

• Packetloss
• Latency

If your network is experiencing packetloss or poor latency, either in the last mile, or wireless access, then TCP Acceleration could have a dramatic impact on the end user experience and greatly improve overall network efficiency. The only sure way is to try.