They haven't improved the underlying link rate at all. In fact, the FEC overhead is going to reduce the effective link rate. However, in some edge-case high packet loss scenarios, the reduced packet loss will more than make up for the reduced effective link rate.
I remember doing research on FEC codes back in 2003-2004 for developing a protocol for sending large files over satellite links to multicast recipients when I was working for SmartJog.
Interestingly, this tool looks like it is useful for the problem you describe:
udpcast (http://www.udpcast.linux.lu/satellite.html) -> Sends/receives files over UDP. Supports FEC.
netcat -> Join file I/O (from udpcast) to local TCP/UDP sockets
openvpn / iptables userspace -> Provide connection routing.
Seems like an evenings work.
Edit: udpcast might not be suitable for this. I am surprised noone has already built a simple UDP FEC tunnel program...
Edit: Not RFPs, duh
Universities desperately need to commercialise their research in order to survive.
Basically, you split your data into blocks, XOR random blocks together and the client can recreate the data by solving the equation of which blocks where XORed with which.
A good tutorial is here: http://blog.notdot.net/2012/01/Damn-Cool-Algorithms-Fountain...
And a fast implementation: http://en.wikipedia.org/wiki/Raptor_code
This problem is very common but it wants fixing on the L2 and not TCP. Turning up the FEC on the L2 would reduce its capacity even further though since more of the bandwidth is taken up by the FEC (and so does this TCP level FEC).
3G gets it wrong on the other extreme, it pretends to always have 0% packet loss, your packets just sometimes show up 30-100 seconds late and in order.
Let's suppose you have a mathematical process that outputs a stream of [useful] data. The description of the process is much, much smaller than the output. You can "compress" the data by sending the process (or equation) instead. Think π. Do you transmit a million digits of π or do you transmit the instruction "π to a million digits"? The latter is shorter.
Now, reverse the process: given an arbitrary set of data, find an equation (or process) that represents it. Not easy for sure. Perhaps not possible. I recall as a teenager reading an article about fractals and compression that called on the reader to imagine a fractal equation that could re-output your specific arbitrary data.
If I've totally missed the article's point, please correct me, but explain why it also talks about algebra.
EDIT: I re-read and noticed this: "If part of the message is lost, the receiver can solve the equation to derive the missing data." I can see the FEC nod here.
Guh. I guess I'm blind tonight. "Wireless networks are in desperate need for forward error correction (FEC), and that’s exactly what coded TCP provides." I cannot for the life of me understand why they'd need to keep this a secret.
They have a patent on this: http://www.google.com/patents/US20120201147
(Disclosure: I was an intern there in 2009, when it was IPeak Networks.)
Obviously this is a much weaker and less efficient solution that what is proposed in the paper, but this would be trivial to implement. I believe netem allows you to simulate this.
It also means less power consumption on mobile phones. There will be no need to increase signal power to get better speed or voice quality.
Also, how were we not doing this already?
Also, I need a writer. Whoever wrote this up made it sound WAY cooler than when I explain error correcting codes.
TCP is old and reliable and there are massive costs associated with switching to anything else. I think that's why we weren't doing this yet, and I think that's why this initiative will fail too.
I wonder if something along the lines of old-school Parity files would work in the packet world? Basically just blast out the packets and any that were lost, you just reconstruct using the meta-data sent with the other packets.
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.
I imagine the higher latency was used to offset lower bandwidth due to FEC encoding loss, by amortizing it over more bits.
Now if they can compute a series of code blocks over a rolling set of data blocks, that would be new. It would be like singing a round of "Row Row Row your Boat" but in data packets, just waiting and you'll be able to figure out the packets that were dropped. Anyone know if this is what they did?
Now you could code up a packet, break it up and then add code blocks, that works great for the packet, but if you don't get enough blocks from that set of blocks you have to resend the packet which is something you don't want to do.
So if instead you send say 3 data blocks and 2 code blocks and then start sending two data blocks and 1 code block and set it up (this is the part that would be impressive) so that the previous two code blocks and the current one could reconstruct the two datablocks you just sent. (re-using previously sent code blocks) My brain is wincing trying to imagine the kind of ECC code that would be, sort of like solving the ECC polynomials in two dimensions or something.
Any way, if you could do that, the outcome would be that you could continually send data and dropped packets would always be correctable by later packets received. I drew out a picture of what relationship the code blocks would need and its complicated. Say you did an 8x3 (8 data segments, 3 code segments, you send
D01 D02 C01 D03 D04 C02 D05 D06 C03 D07 D08
C04 D09 D10 C05 D11 D12 C06 D13 D14 C07 D15
D05 D06 C03 D07 D08 C04 D09 D10 C05 D11 D12
Anyway, that would be some nice math if its doable. And really game changing, it would mean you would get less bandwidth in a situation where there was no packet loss (you're injecting ECC data). But it also makes me wonder if you don't just fix the underlying wireless protocol to do this with the frames sent, why does it have to be at the TCP level?