MAX_REND_FAILURES should not be 30

[rransom]

From src/or/rendservice.c:

/** How many times will a hidden service operator attempt to connect to
 * a requested rendezvous point before giving up? */
#define MAX_REND_FAILURES 30
/** How many seconds should we spend trying to connect to a requested
 * rendezvous point before giving up? */
#define MAX_REND_TIMEOUT 30

MAX_REND_FAILURES is way too high. To find out how lower it should be, we will need to persuade the operators of popular hidden services to collect some statistics for us.

[nickm]

Without some means to collect stats, I don't see how they're going to do it -- maybe a stats-collecting patch would be good for 0.2.3.

[nickm]

Alternatively, we could just look at regular circuit success rates, calculate how many circuits we need to make to make the overall rendezvous success rate high, and then use that as a guesstimate. Any takers?

[mikeperry]

FWIW, our current network is extremely variable with respect to circuit failure. During my testing for path bias, I've noticed failure rates as low as 10% and as high as 55% for full 3 hop constructions, with conditions changing hourly. Cannibalized and other longer circuits also experience more failure, because the current primary source of failure is CPU overload, which is a per-hop statistical property.

I also expect these figures to get drastically lower as ntor and #7291 get deployed. It might be worth waiting on changing this for that reason, as we'll just have to change it again? Of course, if the plan is to lower it, I do expect the failure rates to go down, so perhaps worst case we just lower it twice?

[nickm]

Unless somebody tells me a better number or how to find one, I can't do this in 0.2.4.

Like, if 30 is "way too high", is there a known smaller number that's "almost certainly good enough"? We could do that in 0.2.4.

[nickm]

We could pick a random number here in 0.2.5. Like, 10?

[nickm]

(Any objections to making it 10 in 0.2.5?)

[andrea]

Let's just suck it up and change this to 10.

[nickm]

I picked 8 because it was a power of 2. Branch "bug4241" in my public repository.

When we merge this, we should open another ticket for finding an even better value?

[nickm]

Merged; opened #11447 to cover "look for a better value."