Background information and OpenFEC
TLDR;
Apply Reed–Solomon and low-density parity-check error correction codes to the Real-time Transport Protocol (RTP).
Introduction
The new transport seems to be based on Application-Level Forward Erasure Correction codes (AL-FEC, also called UL-FEC, for Upper-Layers FEC).
The following information is from the OpenFEC project, which obviously is aiming towards applying reasonable things from the Error correction code - Wikipedia domain to improve media transport over flaky networks. Besides researching it, they are trying to get their codes, associated protocols and applications standardized to enable interoperability.
Remark
The main activity of this WG related to research, standardization and reference implementations seems to have happened between 2000 and 2013.
FECs?
In a nutshell
The idea, in one line, is to add redundancy in order to be able to recover from erasures. Because of their position in the communication stack, these codes are implemented as software codecs, and they find many applications in robust transmission and distributed storage systems.
– http://openfec.org/
AL-FEC in short
AL-FEC (A.K.A. UL-FEC) codes are critical to many applications. Their goal is to recover from symbol erasures (rather than errors): a symbol either arrives without any error or is altogether lost. This is why we say they work on a symbol erasure channel. Depending on the target use-case, a symbol can either be:
- a bit (as with physical layer codes)
- a byte (e.g. in the DVB MPE-FEC/MPE-IFEC MAC layer),
- a packet payload that is several hundreds of byte long (e.g. a UDP datagram payload),
- or a file chunk (e.g. with distributed storage applications).
The coding principles remain the same, even if codes are not used exactly in the same way.
Being implemented in higher layers (compared to physical layer codes), they benefit from many simplifications:
- they are usually implemented in software codecs, using the host memory for symbol storage;
- they often integrate the application constraints and the codes can often be produced dynamically, just on time, with the exact encoding block size and redundancy amount needed. Adding a large amount of redundant data is even meaningful with some use-cases.
– OpenFEC.org – AL-FEC documents
Outlook in retrospect
Standardization activities
The people from OpenFEC are actively participating to IETF standardization activities for the codes as well as the associated protocols and applications.
Currently, there are two tracks where the efforts of this WG have been folded into:
- Reliable Multicast Transport (RMT)
- FEC Framework (FECFRAME) ¹
¹ This is a major asset since it warrants a high level of maturity to some code specifications, it enables interoperable implementations, and it specifies all the details for their use in actual use-cases (currently with both file distribution and real-time streaming applications).
