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
comment:2 Changed 6 years ago by
Keywords: | needs-research added |
---|---|
Milestone: | Tor: 0.2.2.x-final → Tor: 0.2.4.x-final |
comment:3 Changed 6 years ago by
Keywords: | tor-hs added |
---|
comment:4 Changed 6 years ago by
Component: | Tor Hidden Services → Tor |
---|
comment:5 Changed 6 years ago by
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
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
Milestone: | Tor: 0.2.4.x-final → Tor: 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:10 Changed 5 years ago by
Keywords: | 025-triaged added |
---|
comment:12 Changed 5 years ago by
Status: | new → needs_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
Resolution: | → fixed |
---|---|
Status: | needs_review → closed |
Merged; opened #11447 to cover "look for a better value."
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.