Hi Rob,
We spoke at the dev meeting about how throttling that's a function of number of clients introduces new anonymity vulnerabilities (for those following along at home, see the upcoming PETS paper "Balancing Performance with Anonymity in Tor"). It seems to me that we want to explore more static options. For example, we watch a rolling window of Y seconds and throttle you to 50KB/s for 2Y seconds if you send or receive more than X bytes in those Y seconds. Here are plausible values of X and Y:
12MB in 30 seconds ("400KB/s") 18MB in 60 seconds ("300KB/s") 27MB in 120 seconds ("225KB/s") 40.5MB in 240 seconds ("169KB/s") 60.75MB in 480 seconds ("126KB/s") 91.125MB in 960 seconds ("95KB/s") 136.6875MB in 1920 seconds ("71KB/s")
The goal is that a client who wants to game the system could self-throttle to just under the limit, and then we don't trigger, but the user would have to self-throttle more and more over time as he continues to transfer many bytes. The smallest Y we consider is 12MB in 30 seconds, and from there when Y doubles we multiply X by 1.5. And then when X/Y reaches 50KB/s we don't throttle further.
It's possible there are simple self-contained equations to describe the above curve; it's also possible there are better curves to explore. And I also confess that I didn't pick the above design with an eye towards easy implementation (somebody's going to have to get out their algorithms magic wand and rephrase it so it looks easier to implement).
My goal was to pick parameters such that we don't impact normal users, but if we *do* trigger on a user then we sure are glad we did.
And there are of course reduced returns here because the user can have multiple entry guards (and all the other cheating questions a la the LIRA design).
--Roger