[tor-dev] Implications of switching to a single guard node: some conclusions

Nicholas Hopper hopper at cs.umn.edu
Thu Mar 27 04:23:28 UTC 2014

On Tue, Mar 25, 2014 at 3:41 PM, Mike Perry <mikeperry at torproject.org>
> 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)?

Takes a few hours to run the scripts again, but the results look like this.
 For the "unluckiest 10%" with T=1000, having 3 guards is still better than
having one, while with T=2000 the difference between 3 guards and 1 is less


Interestingly, though, for the median user with the higher thresholds,
having one guard results in a higher median circuit bandwidth (because a
user with 3 guards is more likely to have selected one guard close to the
cutoff, dragging the typical performance down):


...but I don't think these results speak to this concern:

> ** 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.

because TorPS is a python reimplementation of the circuit selection
algorithm only and doesn't have any way to simulate the CBT logic:

Nicholas Hopper
Associate Professor, Computer Science & Engineering, University of Minnesota
Visiting Research Director, The Tor Project
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20140326/7cf41c9d/attachment.html>

More information about the tor-dev mailing list