[tor-dev] More-static throttling parameters

[Roger Dingledine]

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