[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-dev] Guard node security: ways forward (An update from the dev meeting)
On 05-Mar-14 5:19 PM, George Kadianakis wrote:
OK, let's get back to this. This subthread is blocking us from writing
a proposal for this project, so we should resolve it soon.
There is one very important performance factor that I can't figure out
how to measure well, and that's the impact on the "individual user
performance" if we switch to one guard.
That is, how the performance of the average user would change if we
switch to one guard. But also how the performance of an unlucky user
(one who picked the slowest/overloaded guard) or a lucky user would be
altered if we switch to one guard.
This is a very important factor to consider since the unlucky user
scenario is what forced us to think about imposing more strict
bandwidth cutoffs for guards. This factor is also relevant in the case
where we increase the guard bandwidth thresholds, so we should find a
way to evaluate it.
Nick, do you have any smart ideas on how to measure this?
Tariq's paper does this in 'Figure 10': it has a CDF with the
"expected circuit performance", where you can clearly see that the
number of clients having a super slow circuit (< 100kB/s) with three
guards is extremely low (~0%), but when you switch to one guard they
are not so few anymore (5% of clients). I'm curious to learn how that
CDF was created, for example I guess they only considered the
performance impact of the guard on the circuit, and not of the rest of
the nodes.
We picked one guard each for a large number of clients and then made the
CDF (Fig. 10) of all the clients' guard list BW. In our paper, we then
assume the guard will be the bottleneck and the client will see at most
this amount of bandwidth.
We could do a similar study and get CDFs for the middle node BW and exit
BW. Comparing the curves we would see where the bottleneck actually is,
i.e. the fattest left side of the curve. It may very well be that the
middle nodes are slower on average.
For example, should we assume that a guard of 100kB/s is equally
performant to users in a network where one guard is used and in a
network where three guards are used?
Too bad we don't know what people use Tor for or in what distribution of
use cases. :)
Then we could try to ensure all nodes could handle that or have a mix of
nodes that on average gave adequate performance across most use cases.
And if Tariq's 'Figure 10' approach is indeed good enough for us, how
should we proceed? Are we satisfied by the performance of the one
guard approach in 'Figure 10'? If not, we will probably need to
increase the guard bandwidth cutoffs. Should we make more 'Figure 10'
graphs with different bandwidth cutoffs for the case of 1 guard, and
try to find the bandwidth cutoff that will resemble the current Tor
network most?
Squinting at the Fig. 10 a bit I think that 1500 (consensus BW units)
might be a good place to start.
Cheers,
Tariq
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev