From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw0-f43.google.com (mail-yw0-f43.google.com [209.85.213.43]) (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 352F22020B8 for ; Thu, 12 Jul 2012 09:54:54 -0700 (PDT) Received: by yhl10 with SMTP id 10so3992110yhl.16 for ; Thu, 12 Jul 2012 09:54:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=tTdP/BU134kkPiUQA7LNd0QpNYaZtc2vlFxRLt4hRfs=; b=BMnHkmouKwnUTmFAefYGHWpi0K6vg2ki0O8LOdOwvzY+rMH47JzW4xkEXlPL5T4u0p g+ZGVSN1nfNU0Ihn9KUqsfHcqsOUIHnab0tN/fnCdfE4uwMSLeGUs2JtWKz/dgd24/t/ DAe+K+rcoSLPPUIGse3x3qPdqBJGkPvkRPn/KM+mKQs7B4jKrgqyVFfK4l26LjxUO/IN G7dudHMYz54DzgB+fAEX9l9PCN4mC7ua34g4GAw34x/UnIkP+8tbkQXq0jomqqUPf7pv APTa6ROPANQTqEknoUpM/iRUQC6UWYd+w+c0oXzPXDErnu97Cj6XANgMzjSOZda2PK02 hV/g== Received: by 10.101.13.9 with SMTP id q9mr18923008ani.43.1342112093366; Thu, 12 Jul 2012 09:54:53 -0700 (PDT) Received: from [172.30.42.112] (c-24-218-176-94.hsd1.ma.comcast.net. [24.218.176.94]) by mx.google.com with ESMTPS id c13sm4915582anm.13.2012.07.12.09.54.51 (version=SSLv3 cipher=OTHER); Thu, 12 Jul 2012 09:54:52 -0700 (PDT) Sender: Jim Gettys Message-ID: <4FFF015A.5010809@freedesktop.org> Date: Thu, 12 Jul 2012 12:54:50 -0400 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: John Heffner References: <1340945457.29822.7.camel@edumazet-glaptop> <1341396687.2583.1757.camel@edumazet-glaptop> <20120709.000834.1182150057463599677.davem@davemloft.net> <1341845722.3265.3065.camel@edumazet-glaptop> <1341933215.3265.5476.camel@edumazet-glaptop> <1342100812.3265.8260.camel@edumazet-glaptop> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: nanditad@google.com, netdev@vger.kernel.org, codel@lists.bufferbloat.net, mattmathis@google.com, ncardwell@google.com, David Miller Subject: Re: [Codel] [RFC PATCH v2] tcp: TCP Small Queues X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 16:54:54 -0000 On 07/12/2012 12:44 PM, John Heffner wrote: > On Thu, Jul 12, 2012 at 9:46 AM, Eric Dumazet wrote: >> On Thu, 2012-07-12 at 09:33 -0400, John Heffner wrote: >>> One general question: why a per-connection limit? I haven't been >>> following the bufferbloat conversation closely so I may have missed >>> some of the conversation. But it seems that multiple connections will >>> still cause longer queue times. >> We already have a per-device limit, in qdisc. >> >> If you want to monitor several tcp sessions, I urge you use a controller >> for that. Like codel or fq_codel. >> >> Experiments show that limiting to two TSO packets in qdisc per tcp flow >> is enough to stop insane qdisc queueing, without impact on throughput >> for people wanting fast tcp sessions. >> >> Thats not solving the more general problem of having 1000 competing >> flows. > Right, AQM (and probably some modifications to the congestion control) > is the more general solution. > > I guess I'm just trying to justify in my mind that the case of a small > number of local connections is worth handling in this special way. It > seems like a generally reasonable thing, but it's definitely not a > general solution to minimizing latency. One thing worth noting: on a > system routing traffic, local connections may be at a disadvantage > relative to connections being forwarded, sharing the same interface > queue, if that queue is the bottleneck. Kathy simulated CoDel across a pretty wide range of RTT's seen at the edge of the network, and things behave pretty well. She did say she needed to think more and simulate the data center cases; haven't had a chance to chat with her about that. Of course, you can do some experiments pretty easily yourself, and we'd love to see whatever results you get. - Jim > > Architecturally, the inconsistency between a local queue and a queue > one hop away bothers me a bit, but it's something I can learn to live > with if it really does improve a common case significantly. ;-) > > Thanks, > -John > _______________________________________________ > Codel mailing list > Codel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/codel