From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) (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 D2F2C208ADC for ; Wed, 25 Sep 2013 08:15:55 -0700 (PDT) Received: by mail-pb0-f48.google.com with SMTP id ma3so6086787pbc.7 for ; Wed, 25 Sep 2013 08:15:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:cc:date:in-reply-to:references :content-type:content-transfer-encoding:mime-version; bh=9nI9dWTtZOQty/4j+z9gsWzML+7TEl3uepvArHYnynw=; b=askt1gtAce2joY3qtPT2I1FJZob6IEAw73GSwjw/ABc1k5NCIlJo2GGqyEq54TlH1i blnolVAfLvxgLiryzBEkWSmNdYWKehWoyMH7kqBfgwz7uncHZzjdG9/fld304GI95uCv wg/xqGSpWrR3UwS/BFo43uB6dlh+mLihYBAB4JTkpyMQHe20Wt53A0QQFPNEhNq7k3Br r4ZS3sSgrY+h4NW7SCtLl/xph78p0QU4hebXYVuPd8MLQ3sxy4B2o0o+Ol2Kt9RsQ5/v Q+w+rPsZ2nZWaMer9JonLe9a2m7Xpi+IRuVwz4emZGfdAiKbHh/dKGUTly24SpS+inq8 f2LQ== X-Received: by 10.68.189.229 with SMTP id gl5mr3923041pbc.195.1380122154065; Wed, 25 Sep 2013 08:15:54 -0700 (PDT) Received: from [172.19.254.196] ([172.19.254.196]) by mx.google.com with ESMTPSA id l8sm48307596pbl.22.1969.12.31.16.00.00 (version=SSLv3 cipher=RC4-SHA bits=128/128); Wed, 25 Sep 2013 08:15:53 -0700 (PDT) Message-ID: <1380122152.3165.156.camel@edumazet-glaptop> From: Eric Dumazet To: James Roberts Date: Wed, 25 Sep 2013 08:15:52 -0700 In-Reply-To: <2719938E-E24A-4A06-898F-CE90CBED005C@inria.fr> References: <2719938E-E24A-4A06-898F-CE90CBED005C@inria.fr> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 Cc: bloat , "aqm@ietf.org" Subject: Re: [Bloat] [aqm] TSO sizing fixes and the new paced "fq" scheduler in Linux 3.12 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: Wed, 25 Sep 2013 15:15:56 -0000 On Tue, 2013-09-24 at 14:25 +0200, James Roberts wrote: > No one responded to Luca's Sept 1 comment (on the bloat list) that the > new code seems to do tail drop rather than longest queue drop. > > > If this is so, bandwidth sharing will not be fair since FQ alone is > not enough. This was shown in the previously cited Bell Labs > paper : http://ect.bell-labs.com/who/stiliadi/papers/jsac99.pdf. The > following table is copied from the paper. This paper assumes TCP stack can push cwin packets in the queue. We no longer have this behavior with linux. If you have drops on FQ, then you have a serious problem with your settings. FQ is meant to be used on hosts, not on routers. For routers, fq_codel is fine. TCP Small Queues limits the number of packets in Qdisc for any tcp flow (2 packets). Default FQ setting allows 10000 packets. You can add tail drop on FQ if you really want, but I never had a single drop in my FQ settings, on 20Gbps links and thousands of flows. Therefore I did not add complexity to solve a non problem.