WAN Forward Error Correction for Real Time Data Streams – Tutorial

Home   >   Tutorials   >   WAN Forward Error Correction for Real Time Data Streams – Tutorial
WAN Forward Error Correction for Real Time Data Streams – Tutorial

Introduction to WAN Forward Error Correction for Real Time Data Streams

dataQualityRunning a forward error correction algorithm over a wide area network with long path delays can improve packet throughput and reduce latency by eliminating the need to retransmit lost packets.

The network protocol between two devices operating over a WAN must maintain a balance between latency and error recovery from packet loss while fitting within the available bandwidth and still achieve high data quality. It’s the classic “Iron Triangle.”

Error recovery from packet loss can be improved, but at some point this results in too much latency and/or consumes too much bandwidth.

Real Time Data Streams

Transporting real time data streams over a WAN differs from “normal” network traffic where packet flow is of the request-response form. Continuous data streams, such as telemetry data, flow continuously in one direction. The data is sequentially generated in time. There’s no ability to “get ahead” on the transmitting side. On the receiving side, the data must remain ordered, requiring buffering to account for out of order and the delay associated with retransmitted packets.

This buffering directly increases the end-to-end latency. In many systems, particularly those with a long round-trip time on the WAN, running TCP protocols may not be feasible.

WAN Forward Error Correction (WAN FEC)

UDP is a viable alternative to TCP, provided the system implements a WAN FEC to recover from lost packets. To handle lost packets, data streams are aggregated, encoded, and interleaved for WAN transmission. Performing error detection and recovery on the aggregated set of data streams reduces latency for each individual data stream. The aggregation also improves the error recovery.

Encoding the data streams adds check bits to the data, and interleaving “spreads out” the source data bits and their check bits so that when packets are lost, the impact on any one data stream is less concentrated. The ratio of check bits to source data bits and the spread of the interleave determines whether or not the content of the lost packet(s) can be recovered.

The optimal FEC technique to manage system performance in a constrained environment (i.e. do the best that can be done) depends on the channel data rate, available bandwidth, latency requirements, and network Quality of Service. Regarding QoS, burst losses are the most dif cult to handle, particularly when there are requirements for low latency and the network’s bandwidth is limited.

Data Quality Constraints

DataQualityCurveWith AMERGINT’s WAN FEC, there are three primary tuning parameters. The Collection Interval (how much data is accumulated before being packetized and sent) is one component of the network latency. This also affects packet overhead on the network. The Spread of these packets is the primary tuning parameter associated with correction of burst errors. Finally, the FEC Algorithm and the resulting ratio of check bits to data bits impacts bandwidth.

Data quality with a WAN FEC can be managed (obtained) in the region above the curve in the notional diagram to the right.

The coded/packetized data rate determines the bandwidth asymptote. The available bandwidth must exceed this rate. Low latency requirements drive higher coding/packet overhead and this increases the necessary bandwidth.

In addition, the allowable latency must exceed the recoverable burst error period plus the processing latency. Otherwise, data quality degrades during periods of burst packet loss.

The graph shows that small changes in the required maximum latency can quickly require high bandwidth to achieve a specific data quality over the network.

Can we help? AMERGINT’s expertise is available to assist in your systems engineering and design

Randy Culver