Coded TCP

Wed Oct 24 13:37:22 UTC 2012

On Oct 24, 2012 12:40 AM, "Daniël W. Crompton" <daniel.crompton at gmail.com>
wrote:
>
> On 24 October 2012 08:35, Masataka Ohta <mohta at 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 at 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>