Thus spake Roger Dingledine (arma@xxxxxxx): > 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
Attachment:
pgp6ILEtOxKqe.pgp
Description: PGP signature