[Bloat] The wireless problem in a nutshell

[Dave Täht]

Juliusz Chroboczek <Juliusz.Chroboczek at 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