From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (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 AB74A21F095 for ; Wed, 11 Jul 2012 17:00:39 -0700 (PDT) Received: by wibhm2 with SMTP id hm2so1287750wib.10 for ; Wed, 11 Jul 2012 17:00:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; bh=jtVY0VDJV9KoRnMonY/kziuwn9XlNy44cK4D7LqqMgo=; b=de0aYSnCpllsJ9RrUtS+Tpl2lBkAf94HrZINwR7YbOGC2tn51GRt2gDRHJniO9t74j WoD9WHjolZahMnxWJf3VcVwhCxNnC3bK1H22Dw0T2KEAO0+CtwKmKfQeLRlyCejbs3/2 GMRtvdK+M/S2+uD/2WjTCNilhdVsnJHEBOGXcGma7OrUyPc6fQmDLfs6N4kZw8fuqnwa MH7W4ly0+1dVnP4kE0z2CB7TL8k3y1VEdusDwUdZto1NZnnS5s84iEaH93C9ZmT9EBa5 QVkFx2JiU66TKT28xg/DmuN2o3pdEMVvIwh58nJXOlPOe7UcDTgbd9NTkOmEmMO4MbtX hwpQ== Received: by 10.216.136.95 with SMTP id v73mr14086443wei.2.1342051237761; Wed, 11 Jul 2012 17:00:37 -0700 (PDT) Received: from [172.28.88.151] ([74.125.122.49]) by mx.google.com with ESMTPS id eu4sm36999754wib.2.2012.07.11.17.00.35 (version=SSLv3 cipher=OTHER); Wed, 11 Jul 2012 17:00:36 -0700 (PDT) From: Eric Dumazet To: Nandita Dukkipati In-Reply-To: References: <1342021831.3265.8174.camel@edumazet-glaptop> Content-Type: text/plain; charset="UTF-8" Date: Thu, 12 Jul 2012 02:00:33 +0200 Message-ID: <1342051233.3265.8206.camel@edumazet-glaptop> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org, codel@lists.bufferbloat.net, ncardwell@google.com, David Miller , mattmathis@google.com Subject: Re: [Codel] [PATCH v3 net-next] 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 00:00:40 -0000 Note : netdev mailing list doesnt accept HTML ;) On Wed, 2012-07-11 at 12:29 -0700, Nandita Dukkipati wrote: > I have a couple of high level questions on the two solutions for > maintain small queues at qdisc: 1) using codel's feedback versus 2) > the approach in TSQ to explicitly limit bytes per-flow > to tcp_limit_output_bytes. > > > 1. multiple flows case: codel feedback (be it drop/ECN or direct > feedback like in your patch with fq_codel: report congestion > notification at enqueue time) seems to work in maintaining small > queues regardless of the number of connections. TSQ probably won't > achieve this goal when number of flows is large. Is this correct? Problem with codel/fq_codel is that the congestion is delayed. And my patch (signaling congestion to local tcp senders) raised several issues. I had then TSQ idea to have a more general mechanism (not depending on a particular qdisc setup) TCP Small Queue is effective even with a large number of flows because with standard pfifo_fast, we can without TCP Small Queue store 1000 packets in Qdisc, each being 64KB. Thats 64 MBytes... With TCP Small Queue, you can reach this level of occupancy using 500 flows (2 packets per flow) Without TCP Small Queue, you can reach this level using 16 flows. (This of course assumes TSO is on, but modern NIC are TSO enabled) > 2. cwnd adjustment: codel feedback directly and explicitly controls > snd_cwnd which in turn will also adjust the send buffer size to > appropriate value. That's a nice property, which TSQ probably won't > have because it doesn't explicitly adjust snd_cwnd. > > Considering these two points, why TSQ over the Codel feedback > approach? I dont think they compete. They are in fact complementary. If you use codel/fq_codel + TSQ, you have both per flow limitation in qdisc (TSQ) + sojourn time aware and multi flow aware feedback.