Re: [Cerowrt-devel] [Bloat] FQ_Codel lwn draft article review

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

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