Proposal: minimum advertised bandwidth guarantees fast/guard
mikeperry at fscked.org
Mon Jul 23 00:14:49 UTC 2007
Thus spake Roger Dingledine (arma at mit.edu):
> 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.
Isn't it the directory code that is making this decision though? That
can be changed much faster than the clients.
> > 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.
Yeah, new users are picking guards better, but all users who upgrade
keep their state file unless we explicitly expire it in
or_state_validate(). This is what I think we should do for 0.1.2.16,
unless we anticipate other major guard-related changes.
> > 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.
Mad Computer Scientist
fscked.org evil labs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the tor-dev