From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-33-ewr.dyndns.com (mxout-228-ewr.mailhop.org [216.146.33.228]) by lists.bufferbloat.net (Postfix) with ESMTP id 2EB812E04C5 for ; Tue, 8 Feb 2011 13:55:06 -0800 (PST) Received: from scan-32-ewr.mailhop.org (scan-32-ewr.local [10.0.141.238]) by mail-33-ewr.dyndns.com (Postfix) with ESMTP id 522126FC976 for ; Tue, 8 Feb 2011 21:55:04 +0000 (UTC) X-Spam-Score: 0.1 () X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 75.145.127.229 Received: from gw.co.teklibre.org (75-145-127-229-Colorado.hfc.comcastbusiness.net [75.145.127.229]) by mail-33-ewr.dyndns.com (Postfix) with ESMTP id CDC6C6FBE9E for ; Tue, 8 Feb 2011 21:55:00 +0000 (UTC) Received: from cruithne.co.teklibre.org (unknown [IPv6:2002:4b91:7fe5:2:21c:25ff:fe80:46f9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cruithne.co.teklibre.org", Issuer "CA Cert Signing Authority" (verified OK)) by gw.co.teklibre.org (Postfix) with ESMTPS id 4AAE95EC35 for ; Tue, 8 Feb 2011 14:55:00 -0700 (MST) Received: by cruithne.co.teklibre.org (Postfix, from userid 1000) id 8D0EE121F9F; Tue, 8 Feb 2011 14:54:58 -0700 (MST) From: d@taht.net (Dave =?utf-8?Q?T=C3=A4ht?=) To: Juliusz Chroboczek Organization: Teklibre - http://www.teklibre.com References: <87oc6pf4bc.fsf@cruithne.co.teklibre.org> <7ihbcecnbo.fsf@lanthane.pps.jussieu.fr> Date: Tue, 08 Feb 2011 14:54:58 -0700 In-Reply-To: <7ihbcecnbo.fsf@lanthane.pps.jussieu.fr> (Juliusz Chroboczek's message of "Tue, 08 Feb 2011 20:56:27 +0100") Message-ID: <87ei7i9op9.fsf@cruithne.co.teklibre.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: bloat Subject: Re: [Bloat] The wireless problem in a nutshell X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 21:55:06 -0000 Juliusz Chroboczek 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