From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-iw0-f171.google.com (mail-iw0-f171.google.com [209.85.214.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 649BB20016F for ; Fri, 24 Jun 2011 02:35:34 -0700 (PDT) Received: by iwn34 with SMTP id 34so3530721iwn.16 for ; Fri, 24 Jun 2011 03:03:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=HZq809hJpxSwfqAJuof4PKOC0Qcg4NvAANHUTZqbw8g=; b=EZ6UfDgJQwYISG/Ai3vfe/NdIZwIy+LfuGimXjvi6ancaw/RD7ohJ4hsft4pHSvPsW 3QylVEhwQQEeqeeIJw7I0zjVgOTyPUMgY6PrVf/SsnszAOlO+rnmgBuy6QSi+ML1Z1Az B5DS9CiyTWACr9kzghxdrCMoaiuw75FsQnzMU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=LazG9/QHgSlbWJVSsMWlwFI3EOsfh/syv0iN9oYQrLhVLBJYNubv5BFI42Zm4e818n k8dupUUI+K7JUhC9JgotyCFbVcTPBPBEeF0nl3mIkW+8Wsd15jbFZXubKD097lvA4SOZ /NWpL4vS+9eJIOaKFI8mDiblO3UTKnvQBEYAA= MIME-Version: 1.0 Received: by 10.231.117.24 with SMTP id o24mr1492552ibq.69.1308909810034; Fri, 24 Jun 2011 03:03:30 -0700 (PDT) Received: by 10.231.32.137 with HTTP; Fri, 24 Jun 2011 03:03:29 -0700 (PDT) In-Reply-To: References: <7ir56kupy8.fsf@lanthane.pps.jussieu.fr> <1308891660.3000.7.camel@edumazet-laptop> Date: Fri, 24 Jun 2011 04:03:29 -0600 Message-ID: From: Dave Taht To: Eric Dumazet Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: bloat Subject: Re: [Bloat] Some updates on hacking on AQMS 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, 24 Jun 2011 09:35:34 -0000 On Fri, Jun 24, 2011 at 3:10 AM, Dave Taht wrote: > On Thu, Jun 23, 2011 at 11:01 PM, Eric Dumazet w= rote: >> Once qdisc queue is _full_, its too late, you have to drop packets >> anyway. And its not because at least one flow is not responsive : >> It might be because one thousand flows began their life at the very same >> moment :( Oh, and while I'm touching upon this subject, by default openwt enables 'syn flood support', which (by default) rate limits syn attempts to 25/second, bursting to 50, dropping new attempts long before they can introduce the TCP mice problem, and introducing long retries for the re-attempted connections. That's not bandwidth or workload relative, or related to the number of users, but a flat limit. While the syn flood rate is configurable (and I've either disabled it entirely or bumped it up a lot in my own testing - it's easy to see if you try to, say, access the top 100 web sites all at once - try 100, see 50 fail..... retry 50, see 25 fail...) ... Arbitrarily dropping syn attempts at a level well below what a single browser can introduce today has a dramatic effect on perceived performance and latency. This again points to the need for in depth knowledge of what packets are being dropped, where, why, and when, when evaluating the behavior of todays networking subsystems. I'm looking forward to being able to analyze packet drops extensively in the future with the packet drop analysis tool recently discussed here. No doubt other routers, gateways and firewalls are making similarly desparate attempts to smooth the flow of traffic above and beyond the basic effects of the qdiscs. by default Openwrt also clamps MSS... blocks icmpv6 'etoobig' messages to internal networks... and limits 6in4 ipv6 mtu to 1280. In addition to all the other heroic measures being done elsewhere in the networking subsystems (forget about wireless for a bit... cable modems often do synack optimization as one example, and a recent paper by cablelabs pointed to overbuffering in most modems incorrect by an order of magnitude) it would be good to have a clearer picture of what is REALLY going on before making any clear determinations as to the real effacy of any qos subsystem. --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 http://the-edge.blogspot.com