Hi,
I agree with most of Björn's post, but disagree slightly here:
I fully agree with what Ian said, except for one point. ;)
The EWMA stuff isn't _trying_ to be fair; it's explicitly trying to prioritize circuits for which users will gain utility from lower latency, and deprioritize circuits for which users don't care about latency. That said, it's still kind of fair, as circuits with similar usage patterns will get similar service.
The main difference is that if you've got a bunch of circuits that need servicing, a fair round-robin doesn't care if you service them in the order A,B,C,D,E,A,B,C,D,E or E,B,A,C,D,E,B,A,C,D, or even E,B,D,A,C,A,E,B,C,D. All are equally fair. The observation in our CCS paper is that it _does_ matter to the user, if some of the circuits are interactive, and others are not. Indeed, if A is interactive and hasn't sent packets in a while, it might get A,A,A,C,E,B,D so that it can "catch up".
I think this is also a question of the time scale. If the queues are excessively long due to non-working congestion control as in current Tor, then this is certainly an issue - because you can save significant time by scheduling in the right order. If the queues are short and scheduling is more fine-grained than now, then the minimal resulting time differences will not matter.
As I said in my previous mail, it is still conceivable to implement something along similar lines with our proposal. In the end, this would mean the introduction of (short-term) unfairness in order to give a (short-term) advantage to interactive traffic. This can be done without hurting the long-term fairness between circuits. However, it would increase the complexity, and thus significantly reduces our chances to understand what happens and why it happens.
It may well turn out that this is beneficial - this remains to be assessed at some point further down the road. For the moment, my guts tell me that the problem will not exist to the same extent. My guts might be wrong with that, and we should verify that once the ideas have become a bit more stable. If I am right, however, we should IMHO seize the opportunity to reduce the system complexity if it doesn't hurt performance.
Best regards
Björn