From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-12-ewr.dyndns.com (mxout-034-ewr.mailhop.org [216.146.33.34]) by lists.bufferbloat.net (Postfix) with ESMTP id 479D32E011F for ; Fri, 11 Mar 2011 14:21:17 -0800 (PST) Received: from scan-11-ewr.mailhop.org (scan-11-ewr.local [10.0.141.229]) by mail-12-ewr.dyndns.com (Postfix) with ESMTP id 8209093172E for ; Fri, 11 Mar 2011 22:21:16 +0000 (UTC) X-Spam-Score: -1.0 (-) X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 209.85.215.171 Received: from mail-ey0-f171.google.com (mail-ey0-f171.google.com [209.85.215.171]) by mail-12-ewr.dyndns.com (Postfix) with ESMTP id 2B2C99316C3 for ; Fri, 11 Mar 2011 22:21:16 +0000 (UTC) Received: by eydd26 with SMTP id d26so1256429eyd.16 for ; Fri, 11 Mar 2011 14:21:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=vUzIss+8/gQxggEtFXxzASkdCKGPCEH1xiTMZq9Rk5I=; b=ZGUoYNqliShyzURcNG2+veMDkntsxP98XDJOF8j30CK0kiePoBgWvO/LAYmvqzDo0D XeCI0HeiNrCtdgsxm/PW1nlcvw98JJQ2JVh8j7OSKnowueOeo/BDgZXYz2BPd6PBggyJ N+pckc5lrq3AsQJ8wvgZYHGIvUlerv9FCZIps= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=AhCJHloGV51LLO1AAn3LfI9UobHe/Ab0GFjNmxu3C5bvRBsgicLFHBm7b9m/PryUgj HY/I8CloLlxfojikTR5E6QG1lwQ1qrfBfazK+1iG1oXs97yybkIIAHUZyPkcfUzhpvV+ gY4rVihtnBX1w5UJ6LDzFdwvFlqqCTMs4vl+w= Received: by 10.14.123.141 with SMTP id v13mr2007262eeh.23.1299882075446; Fri, 11 Mar 2011 14:21:15 -0800 (PST) Received: from [192.168.239.42] (xdsl-83-150-84-172.nebulazone.fi [83.150.84.172]) by mx.google.com with ESMTPS id t50sm3852047eeh.18.2011.03.11.14.21.14 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 Mar 2011 14:21:15 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=iso-8859-1 From: Jonathan Morton In-Reply-To: <1464EA88-F053-4EFE-8148-8B44585B9999@gmail.com> Date: Sat, 12 Mar 2011 00:21:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1661FA92-9C87-42B6-B02F-E847FE88794E@gmail.com> References: <1464EA88-F053-4EFE-8148-8B44585B9999@gmail.com> To: Jonathan Morton X-Mailer: Apple Mail (2.1082) Cc: bloat@lists.bufferbloat.net Subject: Re: [Bloat] A hard ceiling for the size of a drop-tail queue 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 Mar 2011 22:21:17 -0000 On 11 Mar, 2011, at 3:15 am, Jonathan Morton wrote: > So how many bytes is a 2-second queue on a wireless network? It can = be no more than the *minimum* link speed (in bytes/sec) divided by the = *maximum* number of nodes. This allows a 100% overhead for framing and = congestion avoidance. For 802.11 the minimum link speed is 1Mbps =3D = 100KB/s, so with 100 nodes (not a very large conference) the buffer = should be no more than 1KB - which is less than one full packet. And = since there are only about 3 non-overlapping channels in the 2.4GHz = band, then even if you spread those 100 nodes over 3 base stations, you = only get 3KB =3D 2 packets of buffer space. (And this includes the base = station!) >=20 > So I'm surprised that these conference networks ever function at all. Coming back to this topic for a moment, I have a radical solution to the = "wifi congestion collapse" problem: If a packet has been in the send queue for more than 1 second, drop it - = regardless of whether it has been sent or not. Why? Because if the application and the user are still interested in = getting the traffic through, they will retry. If not, dropping stale = packets will stop thee retries (which will happen anyway) from clogging = up the network. The first TCP-SYN retry will be after 3 seconds, so = dropping the first try after 1 second gives back 2/3rds of the airtime = and prevents the queue growing. Dave T=E4ht gave me something to listen to, and one of the things that = was mentioned was that the aggregation aims for 4ms of airtime at once. = This means that there is time for about 250 aggregate-frames per second. = This, to me, puts the sustainable number of nodes at about 100 as I = suspected. But remember that at the minimum rate of 1Mbps, 4ms is only = 500 bytes - enough for TCP SYN or DNS to work, but only one-third of a = full Ethernet frame. - Jonathan