From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-01-ewr.dyndns.com (mxout-069-ewr.mailhop.org [216.146.33.69]) by lists.bufferbloat.net (Postfix) with ESMTP id 5DA012E0182 for ; Mon, 7 Feb 2011 03:31:50 -0800 (PST) Received: from scan-01-ewr.mailhop.org (scanner [10.0.141.223]) by mail-01-ewr.dyndns.com (Postfix) with ESMTP id 8B8371F8778 for ; Mon, 7 Feb 2011 11:31:48 +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-01-ewr.dyndns.com (Postfix) with ESMTP id BFC601F86E4 for ; Mon, 7 Feb 2011 11:31:46 +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 1B0A95E899 for ; Mon, 7 Feb 2011 04:31:46 -0700 (MST) Received: by cruithne.co.teklibre.org (Postfix, from userid 1000) id 47277121B7E; Mon, 7 Feb 2011 04:31:45 -0700 (MST) From: d@taht.net (Dave =?utf-8?Q?T=C3=A4ht?=) To: Luca Dionisi Organization: Teklibre - http://www.teklibre.com References: <87oc6pf4bc.fsf@cruithne.co.teklibre.org> Date: Mon, 07 Feb 2011 04:31:45 -0700 In-Reply-To: (Luca Dionisi's message of "Mon, 7 Feb 2011 09:56:43 +0100") Message-ID: <8739o0f5cu.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: bufferbloat list 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: Mon, 07 Feb 2011 11:31:51 -0000 Luca Dionisi writes: > On Sun, Feb 6, 2011 at 6:41 PM, Dave T=C3=A4ht wrote: >> I personally regard the wireless packet loss burst problem as completely >> intractable for long TCP links without using proxies - or insane amounts >> of buffering. > > Is this particular aspect going to be different once that nRED is complet= e? I would love for nRED to compensate for both variable bandwidth and bursty packet loss.=20 I also would like the Easter bunny to visit this year, world peace be achieved, and all four Beatles get back together. I would love it if someone could pull this bunny out of the hat.I'd settle for acceptable buffering at acceptable latencies with acceptable packet loss under worst case conditions with good queue management - the last nRED can solve, the rest requires hacking a lot of over-optimistically designed device drivers. > I mean, if you were in a mesh network, primarily made of wireless > links, where the RTT becomes easily high, how could you make TCP links > to behave right? What I wrote about in the previous email was an in-home or final hop wireless 802.11 network, and I tried to avoid the thorny issues of a mesh network. I'll try, but I don't want my original point about "a short RTT helps wireless TCP" to be lost. It's not well known. You can apply all kinds of AQM (RED, etc) to either side of a one hop wireless connection with a proxy to good effect. You can also apply (some) level of buffering and/or remote acknowledgments to good effect. (You have to anyway, I just tried to simplify out that part - the various 802.11 standards about how/when/why 802.11 does retransmits cover dozens of pages) Moving on to mesh networks.... An encouraging thing about those is that you are carrying not one, but dozens or hundreds of TCP streams. Assuming you are using some form of weighted fair queuing, this means that a burst of lost packets translates into a statistically small, random amount of packet loss across many streams - which TCP can actually compensate for. How long can the RTT get before TCP throughput drops?=20 Good question. That depends on your tolerance for latency and packet loss. You can increase your RTT, and reduce packet drops, by using buffering at the expense of latency. You can reduce your perceived latency for things like DNS by locating caches throughout the network. You can/should put proxies at certain average distances in the mesh (at one point I was using BGP anycast, and later on I switched to DNS - I kind of regret doing that - I wish babel did anycast) A really negative thing about mesh networks is each hop is lossy.=20 Anyway the discussion of bufferbloat has given me an idea regarding using SACK more often that I'm dying to try out. > --Luca --=20 Dave Taht http://nex-6.taht.net