One of the cute things it did was improve reliability for critical messages by preemptively sending them twice, in successive datagrams. That allowed the protocol to avoid an ack-miss-retransmit cycle for those packets, as long as it was only a single datagram that was dropped.
we're seeing it come back into vogue in TCP and modern protocols. QUIC has a FEC component and TCP Tail Loss Probe (http://www.ietf.org/proceedings/84/slides/slides-84-tcpm-14....) is a subtle variation on the theme too
the million dollar question around FEC is how correlated are different loss events which has a lot to do with how well it can work.
But, yes, sending duplicates in another datagram does allow errors to be corrected without being reported to the sender, so it corrects errors in a forward direction, which i suppose makes it FEC.
That Google tail loss stuff is nice, thanks for the link. It's cool that thirty years after RFC793, we're still making significant improvements to TCP.
> Our solution was simple and surprisingly effective. Every packet would send copy of the last packet. This way if a packet were dropped, a copy of it would arrive with the next packet, and we could continue on our merry way. This would require nearly twice as much bandwidth, but fortunately our system required so little bandwidth that this was acceptable. This would only fail if two consecutive packets were dropped, and this seemed unlikely. If it did happen, then we would fall back on the re-sending code.
The protocol i remember specifically send some parts of datagrams, the most critical messages, twice.