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