Using FEC to Reduce Jitter in TCP

Latency is a measure of how much time it takes for a packet to be received after it has been sent. Jitter, is the measure of how much the latency of a packet transmission varies over a network. For example, say we have a steady link latency from a server to a client, if most of the transmissions go through at the link latency, the jitter would be low, but if half the transmissions take double the link-latency, the jitter would be high. 

Jitter is therefore a measure of the stability of a network connection in terms of latency.


We ran some tests of a TCP connection with the following setup:

  • Two network namespaces set up for a server and a client and veth-links (virtual ethernet) set up between these.

  • 1% packet loss and a link-latency of 20 ms is added to the link.

  • The server sends packets with timestamps to the client and the elapsed time is recorded.

  • Jitter is then calculated using the same technique as in RTP (https://datatracker.ietf.org/doc/html/rfc3550#appendix-A.8).

We ran this setup in two ways:

  1. With standalone TCP, and

  2. Using TCP with a Rely tunnel underneath (our low latency FEC solution).

The code for the test can be found here: https://github.com/steinwurf/tcp-test (run the test yourself and let us know your jitter results).

Here are some of our results:

[Per packet Jitter over standalone TCP @ 1% packet loss]

[Per packet Jitter over standalone TCP @ 1% packet loss]

The jitter seems to vary a lot for each packet over the standalone TCP connection. This is likely due to the retransmissions of TCP going out of hand. If a packet is lost, the first retransmission adds 200% latency to the packets, resulting in a large variance in latency. Subsequent packets are also blocked until the lost packet is acknowledged.

Also, if a packet is lost, TCP utilizes congestion control, effectively lowering the throughput of the transmission, resulting in further latency. Packet loss is therefore a big factor in terms of the jitter of TCP. With such a variance in jitter, users would often notice quality issues with their applications, especially those requiring real time interaction like video conference, SD-WAN connections or gaming.

Now lets look at the distribution when TCP is backup up by Rely FEC.

[Per packet Jitter over TCP with Rely tunnel @ 1% packet loss]

[Per packet Jitter over TCP with Rely tunnel @ 1% packet loss]

With the Rely tunnel underneath, most of the packet loss that TCP would experience is fixed with FEC before TCP can experience it. The jitter seems very steady for each packet. The retransmissions of TCP are not going out of hand as seen before, and the connection is much more stable. Users likely don’t notice any issues with their applications running over such a network.

Learn More

The results speak for themselves really, and this disparity in the quality of the connection will be even more pronounced if the packet loss levels increase to higher levels which are common in wireless networks.

To make sure you are delivering the best possible connectivity to your customers, whatever your application, reach out to us to get Jitter under control.

Our low latency FEC solution RELY can help you deliver a more seamless and robust service to all your customers.

Contact Us to learn more and try out Rely, today.

Previous
Previous

How to deal with Packet Loss in TCP?

Next
Next

Steinwurf’s OTAcast