From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (mail.lang.hm [64.81.33.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id D5426208AB4; Tue, 27 Nov 2012 14:32:52 -0800 (PST) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id qARMWVMu016995; Tue, 27 Nov 2012 14:32:31 -0800 Date: Tue, 27 Nov 2012 14:31:53 -0800 (PST) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: Jim Gettys In-Reply-To: Message-ID: References: <20121123221842.GD2829@linux.vnet.ibm.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY="===============4065226624774525573==" X-Mailman-Approved-At: Tue, 27 Nov 2012 15:20:46 -0800 Cc: Paolo Valente , =?ISO-8859-15?Q?Toke_H=F8iland-J=F8rgensen?= , "codel@lists.bufferbloat.net" , "cerowrt-devel@lists.bufferbloat.net" , bloat , Paul McKenney , 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 List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 22:32:53 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --===============4065226624774525573== Content-Type: TEXT/Plain; format=flowed; charset=US-ASCII 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. David Lang --===============4065226624774525573== Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-ID: Content-Description: Content-Disposition: INLINE _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat --===============4065226624774525573==--