More-static throttling parameters
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
[Forwarding on Rob's behalf, since apparently he's not on the list. -RD] ----- Forwarded message from Rob Jansen <rob.g.jansen@nrl.navy.mil> -----
From: Rob Jansen <rob.g.jansen@nrl.navy.mil> Subject: Re: More-static throttling parameters Date: April 10, 2013 9:36:22 AM EDT To: Roger Dingledine <arma@mit.edu> Cc: tor-dev@lists.torproject.org
Roger,
I remember our discussion well. The design we discussed and you've outlined below is reminiscent of a multi-level rate-limiter. This has been discussed in the diffserv model where it is called a "Multi-Stage Token Bucket Meter". See the discussion in section 5.1.4 of RFC 3290 [1], and examples of meters in RFCs 2697 [2] and 2698 [3].
We will be exploring these mechanisms and related issues soon, and will let you know when we have progress worth sharing.
Regards, Rob
[1] https://tools.ietf.org/html/rfc3290#section-5.1.4 [2] https://tools.ietf.org/html/rfc2697 [3] https://tools.ietf.org/html/rfc2698
On Apr 10, 2013, at 5:08 AM, Roger Dingledine wrote:
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
----- End forwarded message -----
participants (1)
-
Roger Dingledine