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