"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." http://www.mit.edu/~medard/papers2011/Modeling%20Network%20Coded%20TCP.pdf --RB
Modeled with just simple FTP sessions? Ugh: they admitted to having MIT backbone packet traces to analyze, and then used that simple of a simulator... George William Herbert Sent from my iPhone On Oct 23, 2012, at 8:29 PM, Rodrick Brown <rodrick.brown@gmail.com> 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. 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."
http://www.mit.edu/~medard/papers2011/Modeling%20Network%20Coded%20TCP.pdf
--RB
George Herbert wrote:
Modeled with just simple FTP sessions?
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. More here: http://www.technologyreview.com/news/429722/a-bandwidth-breakthrough/?utm_campaign=newsletters&utm_source=newsletter-daily-all&utm_medium=email&utm_content=20121023
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. George William Herbert Sent from my iPhone On Oct 23, 2012, at 8:57 PM, "Michael Painter" <tvhawaii@shaka.com> wrote:
George Herbert wrote:
Modeled with just simple FTP sessions?
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.
(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.
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. Masataka Ohta
On 24 October 2012 08:35, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>wrote:
(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. 1. http://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction -- blaze your trail -- Daniël W. Crompton <daniel.crompton@gmail.com> <http://specialbrands.net/> <http://specialbrands.net/> http://specialbrands.net/ <http://twitter.com/webhat> <http://www.facebook.com/webhat><http://plancast.com/webhat><http://www.linkedin.com/in/redhat>
On Oct 24, 2012 12:40 AM, "Daniël W. Crompton" <daniel.crompton@gmail.com> wrote:
On 24 October 2012 08:35, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp wrote:
(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. CB
1. http://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction
-- blaze your trail
-- Daniël W. Crompton <daniel.crompton@gmail.com>
<http://specialbrands.net/> http://specialbrands.net/ <http://twitter.com/webhat> <http://www.facebook.com/webhat><http://plancast.com/webhat><;
participants (6)
-
Cameron Byrne -
Daniël W. Crompton -
George Herbert -
Masataka Ohta -
Michael Painter -
Rodrick Brown