Proposal: minimum advertised bandwidth guarantees fast/guard

[Roger Dingledine]

I've committed the proposed patch, with a few more comments and slightly
different numbers than originally proposed:
http://archives.seul.org/or/cvs/Jul-2007/msg00181.html

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.

Thanks!
--Roger