From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "e37.co.us.ibm.com", Issuer "GeoTrust SSL CA" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id BD81321F11D for ; Tue, 27 Nov 2012 14:54:30 -0800 (PST) Received: from /spool/local by e37.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 27 Nov 2012 15:54:28 -0700 Received: from d03dlp02.boulder.ibm.com (9.17.202.178) by e37.co.us.ibm.com (192.168.1.137) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 27 Nov 2012 15:54:11 -0700 Received: from d03relay01.boulder.ibm.com (d03relay01.boulder.ibm.com [9.17.195.226]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id 11D503E4004C; Tue, 27 Nov 2012 15:54:08 -0700 (MST) Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay01.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id qARMs8AJ260384; Tue, 27 Nov 2012 15:54:08 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id qARMs7Ho024392; Tue, 27 Nov 2012 15:54:08 -0700 Received: from paulmck-ThinkPad-W500 ([9.47.24.61]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id qARMs6nm024299; Tue, 27 Nov 2012 15:54:06 -0700 Received: by paulmck-ThinkPad-W500 (Postfix, from userid 1000) id 23D3AEBF25; Tue, 27 Nov 2012 14:54:06 -0800 (PST) Date: Tue, 27 Nov 2012 14:54:06 -0800 From: "Paul E. McKenney" To: David Lang Message-ID: <20121127225406.GN2474@linux.vnet.ibm.com> References: <20121123221842.GD2829@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12112722-7408-0000-0000-00000A953FE4 Cc: Paolo Valente , Toke =?iso-8859-1?Q?H=F8iland-J=F8rgensen?= , "codel@lists.bufferbloat.net" , "cerowrt-devel@lists.bufferbloat.net" , bloat , John Crispin Subject: Re: [Codel] [Bloat] [Cerowrt-devel] FQ_Codel lwn draft article review X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list Reply-To: paulmck@linux.vnet.ibm.com List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 22:54:31 -0000 On Tue, Nov 27, 2012 at 02:31:53PM -0800, David Lang wrote: > On Tue, 27 Nov 2012, Jim Gettys wrote: > > >2) "fairness" is not necessarily what we ultimately want at all; you'd > >really like to penalize those who induce congestion the most. But we don't > >currently have a solution (though Bob Briscoe at BT thinks he does, and is > >seeing if he can get it out from under a BT patent), so the current > >fq_codel round robins ultimately until/unless we can do something like > >Bob's idea. This is a local information only subset of the ideas he's been > >working on in the congestion exposure (conex) group at the IETF. > > Even more than this, we _know_ that we don't want to be fair in > terms of the raw packet priority. > > For example, we know that we want to prioritize DNS traffic over TCP > streams (due to the fact that the TCP traffic usually can't even > start until DNS resolution finishes) > > We strongly suspect that we want to prioritize short-lived > connections over long lived connections. We don't know a good way to > do this, but one good starting point would be to prioritize syn > packets so that the initialization of the connection happens as fast > as possible. > > Ideally we'd probably like to prioritize the first couple of packets > of a connection so that very short lived connections finish quickly > > it may make sense to prioritize fin packets so that connection > teardown (and the resulting release of resources and connection > tracking) happens as fast as possible > > all of these are horribly unfair when you are looking at the raw > packet flow, but they significantly help the user's percieved > response time without making much difference on the large download > cases. In all cases, to Jim's point, as long as we avoid starvation. And there will likely be more corner cases that show up under extreme overload. Thanx, Paul