[157491] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Coded TCP

daemon@ATHENA.MIT.EDU (=?ISO-8859-1?Q?Dani=EBl_W=2E_Cromp)
Wed Oct 24 03:40:01 2012

In-Reply-To: <50878C3D.7060506@necom830.hpcl.titech.ac.jp>
From: =?ISO-8859-1?Q?Dani=EBl_W=2E_Crompton?= <daniel.crompton@gmail.com>
Date: Wed, 24 Oct 2012 09:39:17 +0200
To: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org

On 24 October 2012 08:35, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>w=
rote:

> (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

--=20
blaze your trail

--=20
Dani=EBl 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.lin=
kedin.com/in/redhat>

home help back first fref pref prev next nref lref last post