MAX_REND_FAILURES should not be 30

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.

changed milestone to %Tor: 0.2.5.x-final

added 025-triaged component::core tor/tor milestone::Tor: 0.2.5.x-final needs-research owner::rransom priority::high resolution::fixed status::closed tor-hs type::defect labels

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.

Trac:
Milestone: Tor: 0.2.2.x-final to Tor: 0.2.4.x-final
Keywords: N/A deleted, needs-research added

Trac:
Keywords: needs-research deleted, needs-research tor-hs added

Trac:
Component: Tor Hidden Services to Tor

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?

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 (moved) 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?

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.

Trac:
Milestone: Tor: 0.2.4.x-final to Tor: 0.2.5.x-final

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

(Any objections to making it 10 in 0.2.5?)

Trac:
Keywords: needs-research tor-hs deleted, 025-triaged, needs-research, tor-hs added

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

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?

Trac:
Status: new to needs_review

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

Trac:
Status: needs_review to closed
Resolution: N/A to fixed

closed

mentioned in issue #11447 (moved)

mentioned in issue #13151 (moved)

moved to tpo/core/tor#4241 (closed)

mentioned in issue tpo/core/tor#11447 (closed)