[Bloat] "a bandwidth breakthrough"
Jonathan Morton
chromatix99 at gmail.com
Tue Oct 23 20:39:38 EDT 2012
On 24 Oct, 2012, at 12:24 am, Dave Taht wrote:
> I've had 3 separate people send me this today.
>
> http://www.technologyreview.com/news/429722/a-bandwidth-breakthrough/
>
> Sure wish we had a PR dept here that was this good vs a vs fq_codel.
>
> I *think* I've read the relevant paper "Modeling network coded TCP
> throughput"? But perhaps there is something newer driving this
> announcement?
That looks like a form of Forward Error Correction - you basically stick a Reed-Solomon code or a trellis code across sections of data packets, and unconditionally send extra packets containing the correction code. This allows missing packets to be reconstructed at the receiver instead of retransmitted. Most TCPs back off very heavily when subjected to random loss, because they interpret it as congestion loss, and that is what results in poor throughput.
With Reed-Solomon, each extra packet sent allows one arbitrary dropped packet from the group to be reconstructed, *provided* the total number of dropped packets from the group doesn't exceed the number of extra packets. Latency is however increased by the group size, which can be over 250 packets in an extremely naive example.
With a trellis code, the reconstruction would be more continuous, with latency depending on the properties of the code rather than on the group size. This might therefore be the better option. High speed hardware trellis decoders are already in common use.
The more common form of FEC operates within a packet, ensuring that low levels of bitwise corruption don't invalidate the whole packet. A heavy burst error can still squash the whole packet though.
I'm actually sort of surprised that the inter-packet version isn't already built into wireless technologies by default, especially the ones that do packet aggregation. In any case it is not totally new - a very similar idea is used in CDs.
These people seem to be implementing it using a tunnelling protocol to a proxy server. That makes it easy to test in public as they describe, although I would be wary of their results until they can be replicated.
- Jonathan Morton
More information about the Bloat
mailing list