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