From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yx0-f171.google.com (mail-yx0-f171.google.com [209.85.213.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 E77472020B8 for ; Thu, 12 Jul 2012 09:44:56 -0700 (PDT) Received: by yenq11 with SMTP id q11so4777848yen.16 for ; Thu, 12 Jul 2012 09:44:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wo2EnEd1ME5gcWpM8OETZpgXJ0vmS2qanM7vDmMQptg=; b=DMG7pRN80wFnKVZPJH0A7/UX8glZ+EbxSubc4fFrYC39+2g8VVo5l2+InvFjlCN17n fBCAdTaninZneQYmn7MEAd5xO4vprBJ9/FoDaohHAQOVQF0VS/Z+laZnblQ5kIpwZHMA KyWxnauSE0uW5s53ijMf6oXFtwK6D2b7A8mQQymtwNAgJ2ah7hSwOBZPwvVwuSzzPh7O upGN/uCKs6x7e7WQ23NwjOwe2WICSGSOmLNvmKIRxutzXqs++/o9z+paSM8wrxyQoAeI I6ZKH67rNvDO5Hwl+QSjGmObGOUlcNsvM0LAUZmSnS8RVnZOhLRdRHMMwTV7vkzk+rwd HLXA== MIME-Version: 1.0 Received: by 10.43.104.202 with SMTP id dn10mr28199819icc.29.1342111495641; Thu, 12 Jul 2012 09:44:55 -0700 (PDT) Received: by 10.64.70.100 with HTTP; Thu, 12 Jul 2012 09:44:55 -0700 (PDT) In-Reply-To: <1342100812.3265.8260.camel@edumazet-glaptop> 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> Date: Thu, 12 Jul 2012 12:44:55 -0400 Message-ID: From: John Heffner To: Eric Dumazet Content-Type: text/plain; charset=ISO-8859-1 Cc: nanditad@google.com, netdev@vger.kernel.org, mattmathis@google.com, codel@lists.bufferbloat.net, 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:44:57 -0000 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. 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