It seems like your browser didn't download the required fonts. Please revise your security settings and try again.
Barracuda CloudGen Firewall

Forward Error Correction (FEC) in TINA Tunnels

  • Last updated on

Forward error correction (FEC) is a special technique for detecting and correcting errors during data transmission between two peers. The term "Forward" indicates that erroneous or lost packets can be reconstructed at the receiver's side without the need of retransmitting the missing information by the sender.

Unlike TCP, which has its own error detection and correction mechanism, UDP is a connectionless protocol that does not include additional information for error detection and correction. This is where FEC comes into play by adding redundant information for repairing damaged or even lost packets during UDP transmissions with the benefit of being much faster than TCP with its protocol-based feature of retransmission.


Forward error correction requires CPUs that support SSSE3 instructions.
Situations and Scenarios when (not) to Use FEC
  • FEC is best suited for use cases that rely on UDP-based interactive traffic, e.g., VoIP.
  • FEC is not useful for TCP-based traffic because TCP uses its own generic error correction mechanism, and, therefore, the combination of TCP and FEC may be too slow to avoid glitches.
  • FEC is not well suited for higher-level bulk data transfers (e.g., HTTP/FTP) that use TCP as the base protocol, for example, backup systems, large file transfers, etc.

For this reason, FEC is available only for TINA/UDP tunnels on the CloudGen Firewall.

Considerations when Using FEC

Because FEC uses additional packets for repairing damaged or lost traffic, additional bandwidth is required. Certain aspects must be considered when using FEC:

  • The FEC level is configurable per transport and direction (asymmetric FEC is also possible).
  • The FEC level configured on a box determines the amount of outgoing FEC, that is, the number of repair packets being sent.
  • The actual amount of FEC packets depends on the current link loss. As a consequence, FEC is only available if Dynamic Bandwidth Detection is enabled.
  • FEC cannot repair sustained periods of loss.
  • If data loss is caused by congestion, FEC will make matters even worse.
  • In case FEC has recovered UDP-based interactive traffic, the affected packets will effectively arrive with some delay, which is still less than the time for TCP retransmissions.
FEC-Level Properties for CGFs

When FEC is activated, the amount of error detection and correction can be configured for one of three levels. Each level stands for a certain number of repair packets sent:

On a CGW, the FEC level cannot be adjusted and is set to Medium.

Each of these three levels is associated with certain marginal values that determine the specific behavior of the respective FEC level:

  • Maximum Link Loss - This is the maximum amount of packet loss on the link, so that the average packet loss after FEC remains under 0.1%.
  • Maximum Overhead - This is the maximum amount of FEC repair packets that are added to the stream of UDP packets. Depending on the measured link loss level, the actual overhead is usually much lower.
  • Maximum Burst - This is the maximum amount of consecutively lost packets that can be repaired.

The following table displays these three parameters depending on the three possible FEC levels:

LevelMax. Link LossMax. OverheadMax. Burst
Feedback and Monitoring

The limiting loss level of the sender's side can be inspected in the VPN tab -> Site-to-Site -> right click your TINA transport -> Show Transport Details..., window Transport Details.


For more information on using FEC, see How to Activate Forward Error Correction.