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
_______________________________________________
Cerowrt-devel mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cerowrt-devel
