General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: d@taht.net (Dave Täht)
To: Juliusz Chroboczek <Juliusz.Chroboczek@pps.jussieu.fr>
Cc: bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] The wireless problem in a nutshell
Date: Tue, 08 Feb 2011 14:54:58 -0700	[thread overview]
Message-ID: <87ei7i9op9.fsf@cruithne.co.teklibre.org> (raw)
In-Reply-To: <7ihbcecnbo.fsf@lanthane.pps.jussieu.fr> (Juliusz Chroboczek's message of "Tue, 08 Feb 2011 20:56:27 +0100")

Juliusz Chroboczek <Juliusz.Chroboczek@pps.jussieu.fr> writes:

>> what you are also doing is dividing the TCP streams into two pieces -
>> the wireless piece is VERY short - and congestion control then works
>> correctly using existing techniques on the wired and unwired portions
>> of the connection.
>
> You've reinvented a useful technique, called "split-TCP".  It's commonly
> used by the "WAN accelerators" that you can buy in order to get Microsoft
> protocols working across the Internet.

I'd been using this technique since 1996 or so, when I was working on a
hybrid wireless broadcast system (on channel) 13, with modem uplinks. At
the time I was like, "oh, proxies are useful to smooth and shorten the
path" than thought it any great revelation - and have used it everywhere
since. 

I'm pretty sure it existed before then, but it has special applicability
to wireless. Hmm... The only wikipedia article on it is in German... I
remember it coming up during the mosquitonet project...

At the time I was more relieved by the discovery that there was indeed a
lower bound on asymmetric TCP/ip based connections - the size of TCP/ip
acks meant that despite the cable companies' intention (at the time) to
build a network that only had enough backchannel bandwidth for a "buy"
button, they were going to be forced to have some ratio between
downloads/uploads that was better than 20/1 in order to function at all.

A quick google for "split tcp" shows a chain of papers on it in the 00s
that are quite fascinating, extensive, and have some delightful math[1]
that describes the (desirable) behavior(s). There's even a proposed
generic implementation for the Linux kernel[2] and an ns2 simulation [3]

Great pointer, thanks.

> The downside of split-TCP, of course, is that it breaks e2e, and hence
> fate sharing, i.e. it introduces a new point of failure and makes your
> network more brittle.  The challenge is to make TCP efficient without
> the need for split-TCP, which requires differentiating between
> congestion-induced loss and wireless loss.

e2e has already gone the way of the dodo with nat. With the exhaustion
of the ipv4 address space, we are heading towards a world of ALGs[4]
everywhere whether we like it or not.

So above I'd change either 

A) the word "challenge" for "impossibility"

Or 

B) The challenge is to make some replacement protocol for TCP efficient
that differentiates between congestion-induced loss and wireless loss.



-- 
Dave Taht
http://nex-6.taht.net

1: https://www1.ethz.ch/csg/people/karaliom/papers/ieeewcnc05.pdf

2: http://www.docstoc.com/docs/11900341/Implementing-Split-TCP-in-Linux-Kernel
3: http://www.cs.northwestern.edu/~ais/split_tcp.html
4: Application layer gateways

  reply	other threads:[~2011-02-08 21:55 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-06 17:41 Dave Täht
2011-02-07  8:56 ` Luca Dionisi
2011-02-07 11:31   ` Dave Täht
2011-02-08 15:54     ` Justin McCann
2011-02-08 19:56 ` Juliusz Chroboczek
2011-02-08 21:54   ` Dave Täht [this message]
2011-02-10 18:39     ` Juliusz Chroboczek
2011-02-11 14:50     ` Dave Täht
2011-02-11 20:12       ` Stuart Cheshire

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=87ei7i9op9.fsf@cruithne.co.teklibre.org \
    --to=d@taht.net \
    --cc=Juliusz.Chroboczek@pps.jussieu.fr \
    --cc=bloat@lists.bufferbloat.net \
    /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