Proposal: minimum advertised bandwidth guarantees fast/guard

[Mike Perry]

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

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.

Sounds good.

-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20070722/50541feb/attachment.pgp>