Opened 7 years ago

Closed 5 years ago

#4241 closed defect (fixed)

MAX_REND_FAILURES should not be 30

Reported by: rransom Owned by: rransom
Priority: High Milestone: Tor: 0.2.5.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: needs-research, tor-hs, 025-triaged
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

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.

Child Tickets

Change History (13)

comment:1 Changed 7 years ago by 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.

comment:2 Changed 6 years ago by nickm

Keywords: needs-research added
Milestone: Tor: 0.2.2.x-finalTor: 0.2.4.x-final

comment:3 Changed 6 years ago by nickm

Keywords: tor-hs added

comment:4 Changed 6 years ago by nickm

Component: Tor Hidden ServicesTor

comment:5 Changed 6 years ago by 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?

comment:6 Changed 6 years ago by 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?

comment:7 Changed 6 years ago by nickm

Milestone: Tor: 0.2.4.x-finalTor: 0.2.5.x-final

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.

comment:8 Changed 5 years ago by nickm

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

comment:9 Changed 5 years ago by nickm

(Any objections to making it 10 in 0.2.5?)

comment:10 Changed 5 years ago by nickm

Keywords: 025-triaged added

comment:11 Changed 5 years ago by andrea

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

comment:12 Changed 5 years ago by nickm

Status: newneeds_review

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?

comment:13 Changed 5 years ago by nickm

Resolution: fixed
Status: needs_reviewclosed

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

Note: See TracTickets for help on using tickets.