[Bloat] "a bandwidth breakthrough"

[Bloat] "a bandwidth breakthrough"

[Dave Taht]

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?

-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Bloat] "a bandwidth breakthrough"

[Jonathan Morton]

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

Re: [Bloat] "a bandwidth breakthrough"

[Albert Rafetseder]

Am 24.10.2012 um 02:39 schrieb Jonathan Morton:

> 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?
> 
> [...]
> 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.

In the case of the four Austrian 3.99G mobile operators we tested,
the fun answer is that they completely conceal loss on layer 2. As
a side effect, they delay packets by sometimes huge amounts: Waiting
for an ICMP echo reply can take a few hundred seconds (!), think
trains in tunnels, but packets do arrive eventually.

And what's true for ICMP is true for those protocols that produce
the significant data volumes as well. I pity the poor TCP RTT
estimator...

-- 
Albert Rafetseder BSc. MSc.
Member of Scientific Staff

University of Vienna
Faculty of Computer Science
Research Group Future Communication
(Endowed by A1 Telekom Austria AG)

Waehringer Strasse 29/5.46, A-1090 Vienna, Austria

T +43-1-42777-8620
albert.rafetseder@univie.ac.at
http://www.cs.univie.ac.at/fc



-- 
Albert Rafetseder BSc. MSc.
Member of Scientific Staff

University of Vienna
Faculty of Computer Science
Research Group Future Communication
(Endowed by A1 Telekom Austria AG)
Waehringer Strasse 29/5.46, A-1090 Vienna, Austria

T +43-1-42777-8620
albert.rafetseder@univie.ac.at
http://www.cs.univie.ac.at/fc

Re: [Bloat] "a bandwidth breakthrough"

[Jonathan Morton]

>> 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.
> 
> In the case of the four Austrian 3.99G mobile operators we tested,
> the fun answer is that they completely conceal loss on layer 2. As
> a side effect, they delay packets by sometimes huge amounts: Waiting
> for an ICMP echo reply can take a few hundred seconds (!), think
> trains in tunnels, but packets do arrive eventually.

But that's not FEC, it's ARQ.  And that's precisely why FEC can be better than ARQ.

 - Jonathan Morton

Re: [Bloat] "a bandwidth breakthrough"

[Richard Scheffenegger]

Aparently, Google is also looking into some form of FEC - transparant to 
legacy TCP though, and potentially adaptive...

Don't have any details other an overheard conversation at some place...

Regards,
   Richard

----- Original Message ----- 
From: "Dave Taht" <dave.taht@gmail.com>
To: "bloat" <bloat@lists.bufferbloat.net>
Sent: Tuesday, October 23, 2012 10:24 PM
Subject: [Bloat] "a bandwidth breakthrough"


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?

-- 
Dave Täht

Fixing bufferbloat with cerowrt: 
http://www.teklibre.com/cerowrt/subscribe.html
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat