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

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.