Exit Balancing Patch
mikeperry at fscked.org
Fri Jul 27 07:04:52 UTC 2007
Thus spake Mike Perry (mikeperry at fscked.org):
> > Regarding the guard node weighting problem, it occurs to me that I pulled
> > the "at least the median bandwidth" thing out of nowhere. My reasoning
> > was that if Alice is going to pick a few nodes that she'll use in every
> > single circuit, it would be a shame if they're 20KB/s nodes, since then
> > she would never ever see more throughput than that. Another hack I picked,
> > for the same reason, was for Alice to pick out of the first two or three
> > guards in her list that are up, rather than always the first.
> > Are there better numbers than the 50% mark for bandwidth? And are there
> > better hacks we should be considering, or hey, actual solutions?
> Well, I don't have solid suggestions other than to point out that the
> current average capacity for the rest of the network is only
> 10KB/sec.. Also, note that if you take the pure median of the network,
> it carries 94% of the network bandwidth. In fact, 93% of the network
> bandwidth is also above the slowest guard (54KB/sec).
> It is actually the uptime limit that is what cuts the guard bandwidth
> down to be only 40% of total network bandwidth, which I guess is
> fine.. It is still greater than 1/3, and excludes exits properly
> (according to the same total/3 ratio I propose in my patch).
Actually, what might be a good idea is to do a "conserve_guards"
weight in smartlist_choose_by_bandwidth() to properly weight guards
using the formula from patch when choosing them as middle nodes.
This way we avoid doubly-overloading guards, since thier bandwidth can
get scarce as well (if for example the tor network bandwidth becomes
more egalitarian and less power-law).
Mad Computer Scientist
fscked.org evil labs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the tor-dev