Proposal: minimum advertised bandwidth guarantees fast/guard
arma at mit.edu
Sun Jul 22 00:07:58 UTC 2007
I've committed the proposed patch, with a few more comments and slightly
different numbers than originally proposed:
On Fri, Jul 20, 2007 at 07:09:00PM -0700, Mike Perry wrote:
> If everyone were weighting guards by bandwidth, 300-400k would
> probably be a fine cutoff. But since we haven't yet decided to expire
> people's already uniformly chosen guards, the limit should probably be
> somewhere around 125k if you really don't want half of the existing
> tor users to continue to be vulnerable to this attack.
Ok. The goal is to pick a number sufficiently high that we would consider
this node worthwhile as a guard even if one day we have a whole lot of
even faster nodes. I picked 250KB/s as a good guess for that.
> Alternatively, we could make 0.1.2.16/0.2.0.3 expire all guards for
> all versions prior, which would also help the network balancing. That
> would be nice. :)
Right. We're not going to do that in the 0.2.0.3-alpha timeframe (which
I hope to put out in the next days), but it's still something to ponder.
As we wait, though, the problem goes away on its own -- now that 0.1.2.15
is out and new users will be picking guards better. I have to admit that
I have no intuition about user turnover though, so no intuition about
how quickly it will correct itself.
> Since Fast nodes are chosen in proportion to bandwidth, this limit can
> probably safely be set much higher proporitionally. 100k looks like it
> may even work.
I decided to stick with 100KB/s here.
More information about the tor-dev