Exit Balancing Patch

[Mike Perry]

Thus spake Roger Dingledine (arma at mit.edu):

> For example, here's another hack we might use: choose guards, weighted
> by bandwidth, demanding that they are Fast (top 7/8s of the network)
> and Stable (currently top 1/2 of the network by uptime, but hopefully
> to be replaced by Proposal 108 [1] sometime), and then when Alice wants
> to use a guard, she selects from the first k nodes in her guard list,
> adding new ones as needed, where k is computed such that she's choosing
> from at least n bytes/s worth of advertised bandwidth.
> 
> We could choose n to be x times the yth percental of bandwidth in the
> network, e.g. 5 times the 50% mark, or 2 times the 25% mark, such that
> the probability of getting many crummy nodes in a row is extremely
> small, but we still get the "your list doesn't rotate often" property
> we want.

Hrmm, this sounds excessively complicated and runs the risk of the
double-weighting issue we discussed before. If the load balancing is
working propely otherwise, this seems overkill. All nodes should be
more or less equivalent in stream capacity..

We really should rebalance the network first and see what sort of
equilibrium it reaches before messing around with something like this.
I think it is important to do this soon. Does anyone disagree with my
suggestion to expire guards for users who have chosen them improperly
(and/or who have probably accumulated way too many by this point
anyhow due to the accumulation problem?).

Likewise, would a patch to report average node capacity (instead of
peak) be accepted, or will it also sit in a queue for a while and
ultimately be forgotten unless I make a huge nuisance of myself? :)


-- 
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/20070726/1c968c85/attachment.pgp>