[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: Exit Balancing Patch

Thus spake Mike Perry (mikeperry@xxxxxxxxxx):

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

Mike Perry
Mad Computer Scientist
fscked.org evil labs

Attachment: pgp6HW2EMgzHj.pgp
Description: PGP signature