From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-33-ewr.dyndns.com (mxout-093-ewr.mailhop.org [216.146.33.93]) by lists.bufferbloat.net (Postfix) with ESMTP id 6D9462E0077 for ; Fri, 11 Feb 2011 06:50:47 -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 7643C6FA426 for ; Fri, 11 Feb 2011 14:50:45 +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 DE2C76F9A98 for ; Fri, 11 Feb 2011 14:50:40 +0000 (UTC) Received: from cruithne.co.teklibre.org (unknown [IPv6:2002:4b91:7fe5:1::20]) (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 1D4735EC38 for ; Fri, 11 Feb 2011 07:50:40 -0700 (MST) Received: by cruithne.co.teklibre.org (Postfix, from userid 1000) id 449BE121FAB; Fri, 11 Feb 2011 07:50:38 -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> <87ei7i9op9.fsf@cruithne.co.teklibre.org> Date: Fri, 11 Feb 2011 07:50:38 -0700 In-Reply-To: <87ei7i9op9.fsf@cruithne.co.teklibre.org> ("Dave =?utf-8?Q?T?= =?utf-8?Q?=C3=A4ht=22's?= message of "Tue, 08 Feb 2011 14:54:58 -0700") Message-ID: <87aai2y69t.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=utf-8 Content-Transfer-Encoding: quoted-printable 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: Fri, 11 Feb 2011 14:50:48 -0000 d@taht.net (Dave T=C3=A4ht) writes: > 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.=20 > > I'm pretty sure it existed before then, but it has special applicability > to wireless.=20 "Socks" - which appeared sometime before 1992 [1] - counts as "before then". I've put some thought into the history of my use of proxies over wireless - re-analyzing something that I'd incorporated into my gut back in 1996. The "split TCP" smoothing effect on the last mile I'd noticed *then* was minor; the time savings were dominated by the latencies in the modem of 100ms or so. [2] The mosquitonet research[3] had clearly shown the disastrous effects on un-error-corrected wireless on TCP. When we did the wireless router thing in 98, 12km latencies were in the 2-12ms range, and I specifically chose a newer technology - the first almost-standardized version of 802.11 - because it did a low level of link layer error detection/correction. Even then, we regarded 1-3% packet loss as acceptable. Today, with 802.11n, we're trying to shove 6x as much data over the air in the same timeslot. Bursty packet loss is a disaster to a device that is advertised to have 300Mbit speeds across the internet. Thus: seconds of buffering and attempts at QoS to channel the more timely packets, and a net result of moving users past the moon and back again on a regular basi= s. AND - in the case of using a proxy, instead -=20 Now that 802.11 wireless problem is in the last 30 meters, RTT is less than one 1ms and the smoothing effect FAR more noticeable. - Or, it would be, if the wireless device makers hadn't already added absurd amounts of buffering. And we had decent AQM. It's amazing how the changes in certain constants make certain formulas more compelling. Let's divide C by 100, shall we? What happens? I ran across Stuart Cheshire's work 4 times while time traveling. Ruckus wireless has got bloat[4] - in 2007 he experiences 2.3 second wireless latencies. There's also a more formal version of his wonderful "it's the latency, stupid" rant, with some good analogies[5]. To quote from his conclusion: =E2=80=9CAs long as customers think that what they want is more throughput,= and they don't care about latency, modem makers will continue to make design decisions that trade off worse latency for better throughput.=20 Modems are not the only problem here. In the near future we can expect to see big growth in areas such as ISDN, cable tv modems, ADSL modems and even wireless 'modems', all offering increases in bandwidth. If we don't also concentrate on improved bandwidth, we're not going to get it. [Elided] If we don't start caring about latency, we're going to find ourselves in a marketplace offering nothing but appallingly useless hardware.=E2=80=9D Written in 1996. Ah, irony, before my first cup of coffee. Things that concern me: 1) Wireless Packet aggregation is now becoming more common, leading to bursty behavior for short packets. What sorts of packets are being aggregated? How much buffering is in place? I worry. 2) I think I can theorize that starting 8 TCP connections in a browser, rather than 2, also "smooths" out bursty packet loss on the wireless last hop. 3) Wild speculation - what packet loss the in home wireless network has been experiencing - has been a significant factor in keeping the internet operational. 4) I am very encouraged by the various standards for enabling web proxies by default: dnsmasq will supply one via dhcp, browsers still look for wpad.=20 In combination with reduced buffer sizes, proxies, and AQM on the gateway side - I am thinking it would be possible to reduce pressure on the wireless client and AP makers for bloating buffers in the first place. What remains is to shift the market. [6] I imagine, if, for example, apple would use these techniques on their tightly integrated wireless gateways and apple tv - that it would provide a competitive advantage.=20 The same goes for other manufacturers. --=20 Dave Taht http://nex-6.taht.net 1 http://en.wikipedia.org/wiki/SOCKS 2 Stuart Cheshire, Mary Baker "Metricom wireless experiences"=20 http://www.stuartcheshire.org/papers/wireless.ps 3 Mosquito net project has vanished from the net. 4 2007 http://www.stuartcheshire.org/papers/Ruckus-WiFi-Evaluation.pdf 5 1996 http://www.stuartcheshire.org/papers/LatencyQuest.ps 6 there is no rule 6 --=20 Dave Taht http://nex-6.taht.net