The article even contains an explanation why TCP does not, and NEVER should, include forward error correction :
> Our simple re-sending mechanism just didn’t perform well enough under these conditions. It was quite common for a re-sent packet to be dropped, and we saw several cases where the original packet and 4 or 5 re-sends of that packet would all be dropped. We were re-sending so many packets, we were starting to exceed the bandwidth of the modem, and then the latency would start to climb, and all hell would break loose.
(then they implemented a -very bad- form of forward error correction in their packets to almost never need retransmissions)
This effectively ignores available bandwidth, and it worked because they were only using tiny amounts of bandwidth, so cheating helped them in this case, without ill effects. It is a dangerous game however. The problem is one of unfairness. If you implement your connections with forward error correction you will have an advantage over others, as you will not follow congestion signals while others do.
I am not suggesting Forward Error correction is a good idea on TCP. They put UDP and forward error correction together which is a good idea (see video/audio streaming over internet). The parent seemed to think they had reimplemented TCP badly, which they didn't, they implemented quite a different protocol which utilised forward error correction which was a good idea and something they would not have been able to do by building on vanilla TCP.
So their prototcol probably ended up messier than it should of been but they were pioneers fixing problems as they cropped up so that's understandable.
