Opened 7 years ago

Closed 7 years ago

#9176 closed enhancement (implemented)

Make the predicted circuits timeout after a configurable amount of time

Reported by: sysrqb Owned by:
Priority: Medium Milestone: Tor: 0.2.5.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: easy tor-client
Cc: unixninja92@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


This was brought up by a user in #tor who expected that tor became dormant after a short amount of time (20 min). It may be a good idea to make the PREDICTED_CIRCS_RELEVANCE_TIME value configurable, currently it is hard coded at 1 hour.

I think one hour is still a good default.

Child Tickets

Change History (9)

comment:1 Changed 7 years ago by nickm

Keywords: easy tor-client added

comment:2 Changed 7 years ago by unixninja92

Cc: unixninja92@… added
Status: newneeds_review

comment:3 Changed 7 years ago by nickm

Looks okay to me. The documentation is a little wrong. It should be something like, "controls how long, after we have requested a connection to a given port, we will try to choose exits that support that port."

I wonder if we should have a maximum value here.

comment:4 Changed 7 years ago by unixninja92

I believe I have fixed the documentation.

I'm not sure if I see the benefits of having a maximum, but it might be good to add a minimum. Because if you set it to a small enough number, then the likelihood of those exits being found is quite low to impossible I'd think. I'm not sure what a good minimum would be though. Maybe somewhere between 1 and 5 minutes?

comment:5 Changed 7 years ago by nickm

Well, if the maximum is ridiculously high, it will influence your exit choices for a while. Suppose that you ask for port 7777 on Monday, and you don't ask for it on Tuesday, Wednesday, Thursday, or Friday. In that case, should Tor really be making sure that it always has a circuit open to an exit that supports port 7777, even on Saturday? I think a 24 hour maximum here is probably reasonable.

A minimum, on the other hand, isn't necessary as far as I can tell: If you have a 0 second minimum, that just means that if you ask for port 7777 again, Tor is not likely to have a pre-built circuit ready for you to use.

comment:6 Changed 7 years ago by unixninja92

I set the maximum for PredictedCircsRelevanceTime at 24 hours.

comment:7 Changed 7 years ago by arma

I'm afraid I'm a bit late to the party here, but: we should consider that the CircuitIdleTimeout config option was chosen with this 1 hour period in mind. If you set your PredictedCircsRelevanceTime to 24 hours but leave CircuitIdleTimeout at 1 hour, you're going to build and throw away 24 circuits (give or take a fencepost). That's not very nice to the network.

Whereas if you raise CircuitIdleTimeout to go along with it, then a) you soak up more resources on relays even when you haven't used your Tor lately, and b) you stand out more to the relays as somebody who fiddled with her parameters here.

I'm not sure what to recommend. My first thought is to not let PredictedCircsRelevanceTime get anywhere near 24 hours.

What was the original use case again?

Last edited 7 years ago by arma (previous) (diff)

comment:8 Changed 7 years ago by unixninja92

The original use-case was to actually shorten PredictedCircsRelevanceTime. So we would probably be fine setting the maximum much closer to 1 hour I would think.

comment:9 Changed 7 years ago by nickm

Resolution: implemented
Status: needs_reviewclosed

Dropped the maximum to one hour, changed the name to refer to predicted ports, merged. Thanks!

Note: See TracTickets for help on using tickets.