When is forward error correction a good idea for packets?

Question

Systems could use UDP and employ forward error correction to transmit the whole message, without retransmits, even if a few packets are lost. Does this ever work well in practice or is the extra overhead too much of a waste?

Answer 1

Depends on the application.

For applications such as games, error corrections are always necessary as it wont make a big difference if you lose a bit of data.

However, if the application requires specific, in-order data, then some sort of error correction is necessary.

It's not a question of "overhead", it's more about "application".

Answer 2

I think it's useful for some applications like Voice (VoIP), where you want to avoid errors, and where you never want stop (to retransmit a NAKed packet) and wait (until it's retransmitted).

So it might be implemented on top of the Real-time Transport Protocol flavour of UDP.

Wouldn't it be terrible for latency?

Are you asking whether forward error correction increases end-to-end delay? If so, I think the answer is "no", but it does increase the needed bandwidth.

I believe you always already need some latency, to avoid jitter; so for example, you might say "let's delay the whole voice channel by 200 msec, so any/every packet can take from 0 to 200 msec to cross the internet, and be reassembled and sent through the D-to-A converter at the other end."

Given those numbers, then having no forward error correction might mean that, in each 200 msec period, you send 10 packets each containing 20 msec of data ... and if one is lost, then that's a gap (a glitch) at the other end.

Whereas, having some forward error correction might mean that, in each 200 msec period, you still send 10 packets ... each packet contains 20 msec of data, plus 10 msec of data that's already been transmitted in another packet (or, maybe you send 30 packets instead of 20). Then, if any single packet is lost, the data which it carried was delivered redundently (half in each of two other packets), which avoids any glitch in the decoded output.

Answer 3

The simple answer is if you're sending over a high-bandwidth high-delay (meaning "long distance") link, forward error correction makes sense. Otherwise, it probably doesn't.

Answer 4

It also makes sense for storage medium, such as hard drives and optical disks, where you can't just go back to the source to get the uncorrupted data. In fact, both hard drives and optical disks use forward error correction quite extensively.

Forward error correction is also used extensively in wireless communications, where errors tend to knock out just a few bits at a time. Rather than lose the whole packet to a single bit error, forward error correction is used to fix the corrupted bits.