Exit Balancing Patch

[Mike Perry]

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

> 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
> seeing? 5MB/s?

I think we should put it well above the current fastest node, which is
blutmaggie at 5.6MB/sec. From what I can tell, this node actually does
have that much capacity. It has 0 failures over 18 fetches averaging
120KB/sec. Kudos to them!

I see no reason not to put the limit at 10MB/sec. All we really want
to do is prevent someone from claiming their bandwidth is infinity. It
should never actually clip a legitimate node's bandwidth if we can
help it. Even though there is no automated scanning yet, I can quickly
verify performance from random IPs that are difficult to anticipate,
and we can raise the limit accordingly. But we should set it high
enough that we do not have to raise it for a good while.

Also, I think the exit weighting formula is wrong. If that portion of
my patch is not to be applied, I would like some sort of justification
as to why what is currently there is better than what I proposed (or
is even correct), but that is the least of my concerns, since exit
bandwidth is usually scarce.
 
> 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?)

Oh, yeah. Definitely should change this.

How does this manifest itself? The first element in the bandwidth line
of the descriptor is 3MB and the second is 6MB? or is it even possible
to tell? the 3rd number is cut at the lower of the observed vs limit..
Should I just check to see who has exactly 3MB as their reported
capacity? Will that work? Is it exactly 3MB, or is it 3000000
bytes?

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

So the median probably was a fine choice, given that the other
restrictions on uptime and such are what we want. Perhaps those
threshholds are what should actually be revisited for the MTBF patch,
but they seem OK.

-- 
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/af9a1974/attachment.pgp>