Re: [tor-dev] Implications of switching to a single guard node: some conclusions
Nicholas Hopper:
On Thu, Mar 13, 2014 at 5:21 PM, George Kadianakis <desnacked@riseup.net> wrote:
tl;dr: analysis seems to indicate that switching to one guard node might not be catastrophic to the performance of Tor. To improve performance some increased guard bandwidth thresholds are proposed that seem to help without completely destroying the anonymity of the network. Enjoy the therapeutic qualities of the graphs and please read the whole post.
This took way longer than I expected it to, but here we go. In order to examine the assumption that "higher guard bandwidth == better client performance", I modified Aaron Johnson's TorPS simulator to simulate 50K clients in several different cases: - "3guards": choose 3 guards according to the current algorithm - "T=250": choose 1 guard, guard flag assigned as current - "T=1000": choose 1 guard, filtering guards with measured bandwidth < 1000 KB/s [Note: these former guards then have an increased probability of being selected as middle and/or exit nodes] - "T=2000": 1 guard, filter guards with measured bandwidth < T - "T=3000": ibid - "T=4000": ibid For each client, the simulator created 600 circuits, and computed the maximum bandwidth each circuit could handle (the minimum bandwidth of the guard, middle and exit relays). This gives us an empirical distribution on circuit performance for each client. Then we can ask questions about the "typical" bandwidth for a client, e.g. the median circuit performance. How many clients typically have low-bandwidth circuits in each case? Looking at the 5000 (10%) unluckiest clients, we see the following behavior:
https://www-users.cs.umn.edu/~hopper/guard_threshold_median_bandwidth.png
Essentially, while the current guard threshold does make the unluckiest clients pretty sad on average, even a 1MB/s threshold means that on average things are a little bit brighter than the current situation, and a 2MB/s threshold for the guard flag makes everyone happier in the typical case. (And increasing the threshold beyond 2MB/s doesn't really help much)
Cool. This is exactly the type of experiment I was hoping someone would do before we switched. Thanks for doing it! However, one thing strikes me though: We see clearly that 1 guard is worse than 3 guards with the current cutoff. I wonder if this is a coincidence, or if it is a property of the low cutoff, or something else**. For control, it would be nice to know what we would be giving up if we used that same T=2000 cutoff with three guards and compare that to T=2000 with just one guard. Is it easy for you to rerun just that comparison (since you seem to be suggesting that T=2000 is a good cutoff anyway)? ** The reason I ask is because I suspect there is actually an interplay between the current circuit build timeout code and the pool of 3 guards. The CBT cutoff will tend to cause you to avoid whichever of your guards may be temporarily overloaded at a given time. -- Mike Perry
On Tue, Mar 25, 2014 at 01:41:43PM -0700, Mike Perry wrote:
Nicholas Hopper:
I modified Aaron Johnson's TorPS simulator to simulate 50K clients
** The reason I ask is because I suspect there is actually an interplay between the current circuit build timeout code and the pool of 3 guards. The CBT cutoff will tend to cause you to avoid whichever of your guards may be temporarily overloaded at a given time.
Does Aaron's TorPS implement the circuit-build-timeout behavior? I wouldn't be surprised if it skipped over that, since (for example) where would you get the realistic data about network latencies and relay delays to be able to simulate it? --Roger
Roger Dingledine:
On Tue, Mar 25, 2014 at 01:41:43PM -0700, Mike Perry wrote:
Nicholas Hopper:
I modified Aaron Johnson's TorPS simulator to simulate 50K clients
** The reason I ask is because I suspect there is actually an interplay between the current circuit build timeout code and the pool of 3 guards. The CBT cutoff will tend to cause you to avoid whichever of your guards may be temporarily overloaded at a given time.
Does Aaron's TorPS implement the circuit-build-timeout behavior?
I wouldn't be surprised if it skipped over that, since (for example) where would you get the realistic data about network latencies and relay delays to be able to simulate it?
Oh, hrmm.. Well, it appears TorPS is just a tor controller, so I believe that CBT should still time these circuits, but if this simulator runs on a timer for extending hops on circuits (or even experiences delays while servicing control port CIRC events), it will effectively destroy how CBT behaves (and possibly alter the results in other ways). This now makes concerned we may still not be fully evaluating the effects of this change with real Tor client behavior. I suppose we need to find out more about exactly how it builds circuits and what torrc options it uses. But in either case, we still need a controlled experiment between 3 guards vs 1 guard at the same cutoff, otherwise we're sort of just sweeping any performance problems caused by the change under the rug. -- Mike Perry
participants (2)
-
Mike Perry -
Roger Dingledine