Exit Balancing Patch
arma at mit.edu
Fri Jul 27 04:55:15 UTC 2007
On Thu, Jul 26, 2007 at 11:51:00AM -0700, Mike Perry wrote:
> > * Tor needs to be careful (and clip at some sane bw of X mb/s) because
> > otherwise too much traffic will concentrate on a small group of nodes,
> > harming anonymity.
> Not to offend you, but I believe this argument is nonsense. A high
> capacity node should be fully utilized to the full extent of its
> capacity. Artifically clipping capacity does not properly solve *any*
> problems related to nodes lying about capacity, nor does it "improve
> anonymity". If you try to "protect" anonymity this way, people with
> high capacity links will just start mounting sybil attacks instead.
Well, I think we want *some* clipping -- otherwise people can advertise
a bandwidth of 1GB/s and suddenly attract 50% of the network's traffic,
whether or not they can handle it. But I am certainly willing to believe
that we should raise the current number. I used to raise it incrementally
as we got faster nodes and as Tor began to work acceptably on fast
servers, and it's been too long since I raised it.
What new number would capture most of the current nodes we're
Also, should we raise the default rate limit from 3MB/6MB too? It's
been a while since we raised it, and I imagine it's clipping a few
servers. (Does somebody want to count how many?)
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?
More information about the tor-dev