[codex]

Isn't the downside of FEC encoded packets increased latency? Instead of sending each packet immediately, don't you need to accumulate n packets to encode as a group? Or does the math allow incremental encoding? Simple parity is incremental, but the FEC on DSL lines always added 40ms of latency.

[AnthonyMouse]

>Instead of sending each packet immediately, don't you need to accumulate n packets to encode as a group?

The way coding works is that you divide data in to n data packets and then calculate c coding packets, and then you can lose any c out of (n+c) packets and still reconstruct the data. You need to see all the data packets in a group before you can finish calculating any of the coding packets, but nothing stops you from sending the data packets immediately.

On the other hand, non-hardware-based error correction that allows for recovery from a large amount of data loss is relatively processor intensive, and the processors in a lot of network equipment are very slow. So you can easily see an increase in latency, not because the packets take longer to send, but because the processor in the network equipment is too busy calculating error correction to timely forward your packets.

[spydum]

Yes, I distinctly recall enabling FEC on poorly performing ADSL links when packet loss was an issue for some ISP customers. It would almost always bump the end point rtt from 8ms to about 30-40ms.

[loeg]

40ms extra latency on wifi is nothing compared to packet loss.

[codex]

Really? My wifi RTT to the metropolitan core is 15 ms, and over LTE it is 47 ms. Not a worthwhile tradeoff at 40 ms unconditional additional RTT delay.

I imagine the higher latency was used to offset lower bandwidth due to FEC encoding loss, by amortizing it over more bits.