• Welcome
  • News
  • Blog
  • Technology
  • Research
  • About

Comparing Rely and Reed Solomon FEC/ECC

August 11, 2020 - Steinwurf ApS

One question that we often get is how do different ECC/FEC algorithms compare? It’s a simple question with a complicated answer - the reason is that different ECC/FEC algorithms are designed with different goals in mind. To simplify the answer we need to restrict the scenario in which we compare performance.

In this post we will compare two algorithms, namely Rely and Reed-Solomon. Rely is a sliding window based RLNC algorithm, whereas Reed-Solomon is based on a classical Vandermonde matrix construction.

Comparison

The basic comparison metric for the two algorithms is:

  • How much repair traffic is required to reach a target residual packet loss rate of 0.001%?

Scenario

Setup (also used in 3GPP MBMS FEC evaluation) refer to [1] for more details:

  • LTE MBMS Bearer bitrates: 1.0656 Mbps
  • Radio Link Control - SDU size: 1332 bytes
  • Radio Link Control - SDU frequency: 10ms
  • Constant bitrate channel (100 packets per second)
  • Latency budget 240 ms (or 24 packets)

We use a random uniform loss model which is different from the one used in [1], and compare the two algorithms using the following simulation setup:

The traffic generator produces 600,000 data packets which are sent via the encoder over the lossy channel and into the decoder. The residual packet loss after decoding is then recorded. In order to find the required repair rate we sweep over multiple configurations (low to high) until we find a configuration that can meet the target residual packet loss rate.

Results

The following figure show the results:

There a few key takeaways:

  1. Notice that even with a very limited latency budget (only 24 packets). Rely based on sliding window RLNC significantly outperforms the block based Reed-Solomon code.
  2. For losses over 10% Rely reduces the required repair traffic by more than 13%.

Conclusion

These results illustrate some of the benefits of Rely with respect to other coding schemes. To learn more about Rely head over to https://rely.steinwurf.com and as always if you have questions about this article or FEC/ECC in general feel free to reach out to us on contact@steinwurf.com.

References

[1] ETSI, “Evaluation of mbms fec enhancements (final report),” Dec. 2015, 3GPP TR 26.947 version 13.0.0 Release 13.

Share this blog:

Recent Blog Posts

  • 22 Jan 2021 | Hardware Acceleration

    Erasure correcting codes (ECC/FEC) provide elegant solutions to many networking problems. Whether you want to build reliable super low latency applications or efficiently send data to 1000s of devices simultaneously, ECC/FEC can provide compelling advantages. However, one common concern when integrating an ECC/FEC algorithm is often how big is the computational overhead?

  • 07 Jan 2021 | Multicast ECC/FEC

    A typical use-case for broadcast/multicast is when we need to transmit the same data (e.g. a file) to multiple receivers simultaneously. The use of multicast/broadcast means that multiple devices may benefit from a single transmission increasing the efficiency of the system. However, a challenge in such systems is how to efficiently deal with packet loss. In the following we will show how using an erasure correcting code/Forward Erasure correction (ECC/FEC) can lead to significant bandwidth savings over a traditional retransmission based system.

  • 30 Oct 2020 | Content-Aware ECC/FEC

    In some of our previous posts we have discussed some of the challenges when implementing a reliability scheme targeting low latency applications. For example in Coding for low latency (block codes) we discuss how large block codes such as RaptorQ or LDPC can be problematic in low latency communication. Similarly in In our post What about the latency, stupid we discuss the latency penalty of using a retransmission based reliability scheme. In this post we will consider what can happen when we want to protect the traffic coming from a latency sensitive application where the structure of the content is important.

  • Twitter
  • Facebook
  • Linkedin
  • Mail
  • Github
  • Youtube
Design: TEMPLATED