"With coded TCP, blocks of packets are clumped together and then
transformed into algebraic equations that describe the packets. If
part of the message is lost, the receiver can solve the equation to
derive the missing data. The process of solving the equations is
simple and linear, meaning it doesn't require much processing on
behalf of the router/smartphone/laptop. In testing, the coded TCP
resulted in some dramatic improvements. MIT found that campus WiFi (2%
packet loss) jumped from 1Mbps to 16Mbps. On a fast-moving train (5%
packet loss), the connection speed jumped from 0.5Mbps to 13.5Mbps."
Ugh: they admitted to having MIT backbone packet traces to analyze, and then used that simple of a simulator...
The practical benefits of the technology, known as coded TCP, were seen on a recent test run on a New York-to-Boston Acela train, notorious for poor connectivity. By increasing their available bandwidth-the amount of data that can be relayed in a given period of time-Medard and students were able to watch blip-free YouTube videos while some other passengers struggled to get online. "They were asking us 'How did you do that?' and we said 'We're engineers!' " she jokes.
I understand and believe in the value of erasure coding, though I want to see the latency effects here. But that model was very detailed view into an overly simple (to the point of operationally unrealistic) model. Bad example, for a research paper.
"With coded TCP, blocks of packets are clumped together and then
transformed into algebraic equations that describe the packets. If
part of the message is lost, the receiver can solve the equation to
derive the missing data.
Don't do that.
MIT found that campus WiFi (2%
packet loss) jumped from 1Mbps to 16Mbps. On a fast-moving train (5%
packet loss), the connection speed jumped from 0.5Mbps to 13.5Mbps."
If everyone start using TCP with FEC to tolerate 20% of packet
loss with 30% FEC overhead, it will make congestion more severe
that more than 20% of packets will be dropped and effective speed
share of each TCP will be decreased by 30%.
The proper approach against lossy liks is to have link local
retransmissions or FEC.
This reads much like Reed-Solomon Error Correction[1], although it is a
good way to reconstruct lost data it introduces a network overhead and a
performance impact due to the reconstruction. The analysis states: "*the
receiver will receive at least 10 linear combinations to decode the
original 10 packets.*" Which reads to me as we need 10 packets of error
correction data to reconstruct 10 packets.
The only advantage I can see here, is that it would outperform UDP.
> (2012/10/24 12:29), Rodrick Brown wrote:
> > "With coded TCP, blocks of packets are clumped together and then
> > transformed into algebraic equations that describe the packets. If
> > part of the message is lost, the receiver can solve the equation to
> > derive the missing data.
>
> Don't do that.
>
This reads much like Reed-Solomon Error Correction[1], although it is a
good way to reconstruct lost data it introduces a network overhead and a
performance impact due to the reconstruction. The analysis states: "*the
receiver will receive at least 10 linear combinations to decode the
original 10 packets.*" Which reads to me as we need 10 packets of error
correction data to reconstruct 10 packets.
The only advantage I can see here, is that it would outperform UDP.
D.
Further, FEC and HARQ are already part of many L1 and L2 networks....
Including UMTS and LTE. ... So this is yet another cross layer optimization
issue... Not solving the "spectrum crunch" .... But that makes good copy.
Folks are much better off spending their time looking into SCTP IMHO.
