[tor-dev] (FWD) Re: More-static throttling parameters

[Roger Dingledine]

[Forwarding on Rob's behalf, since apparently he's not on the list. -RD]

----- Forwarded message from Rob Jansen <rob.g.jansen at nrl.navy.mil> -----

> From: Rob Jansen <rob.g.jansen at nrl.navy.mil>
> Subject: Re: More-static throttling parameters
> Date: April 10, 2013 9:36:22 AM EDT
> To: Roger Dingledine <arma at mit.edu>
> Cc: tor-dev at 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 -----