Forward Error Correction (FEC) and SOHO SDWAN

We often get asked why the RabbitRun SOHO SDWAN solution does not utilize  Forward Error Correction (FEC).   This post will explain our viewpoint on the subject.

In IP networking, Forward Error Correction (FEC) is a digital signal processing technique used to enhance data reliability. It does this by introducing redundant data, called error correcting code, prior to data transmission. FEC provides the receiving side with the ability to correct errors without a reverse channel to request the retransmission of data.  This enables the WAN to recover from packet loss due to a variety of network conditions.

Because FEC consumes bandwidth in direct proportion to the concentration of packet loss over time, it tends to work best in WAN scenarios where packet loss is sporadic and random, or where bandwidth is overly abundant.   To put it another way, when packet loss is random and sporadic, FEC can be tuned to minimize the redundant data transmitted.  But when packet loss occurs in clusters, FEC requires significantly more bandwidth.  For example, in order to guarantee that every packet is successfully transported across the WAN, some FEC solutions send multiple copies of packets on redundant second and/or third links, resulting in up to 300% the bandwidth consumption.

When viewed in this context, FEC is not ideal in the typical small business or home office scenario.   Unlike larger offices where significant resources are devoted to network planning, and it is not uncommon to find gigabit fiber and/or multiple load-balanced broadband connections, small business and home offices must often settle for a single primary connection and consumer grade equipment.  This makes the small office/home office environment  far more likely to encounter clusters of congestion caused by queue overflows and constrained bandwidth links.  Further, the last mile  networks that typically serve as primary links for these types of users are notorious for oversubscription (resulting in buffer bloat on the last mile).   In this situation, the increased overhead introduced by FEC can produce more harm than good.

For an SD-WAN that has a consumer or cable internet as the primary path with LTE for backup, should FEC be used?  In most cases, the answer is no.   When packets are dropped in congested last mile networks, it is usually many packets in a row, regardless of priority.  In this situation, FEC increases the amount of traffic on a network that is already limited in capacity and it just makes the situation worse.

In place of FEC, RabbitRun improves QoS with session-aware congestion control.  Instead of sending more packets, we prioritize only the sessions that are important and send them over the link with the best performance profile.  The result is that we can get the best possible outcome from the sub-optimal  WAN environments that are often found in small business and home office networks.