Proposal: minimum advertised bandwidth guarantees fast/guard

Mike Perry mikeperry at
Mon Jul 23 00:14:49 UTC 2007

Thus spake Roger Dingledine (arma at

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

Sounds good.

Mike Perry
Mad Computer Scientist evil labs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <>

More information about the tor-dev mailing list