General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Jonathan Morton <chromatix99@gmail.com>
To: Dave Taht <dave.taht@gmail.com>
Cc: bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] "a bandwidth breakthrough"
Date: Wed, 24 Oct 2012 03:39:38 +0300	[thread overview]
Message-ID: <4C04E6DB-F9A4-4326-818B-17D953CA1D39@gmail.com> (raw)
In-Reply-To: <CAA93jw7VPasw6zoVzsusxe_4s+VMd313W9BuKZiPA+ALo8jLvQ@mail.gmail.com>


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


  reply	other threads:[~2012-10-24  0:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-23 21:24 Dave Taht
2012-10-24  0:39 ` Jonathan Morton [this message]
2012-10-24 14:49   ` Albert Rafetseder
2012-10-24 15:54     ` Jonathan Morton
2012-11-04 15:46 ` Richard Scheffenegger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C04E6DB-F9A4-4326-818B-17D953CA1D39@gmail.com \
    --to=chromatix99@gmail.com \
    --cc=bloat@lists.bufferbloat.net \
    --cc=dave.taht@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox