Make clients avoid retrying slow exits when they time out

In #21394 (moved), we discovered that Tor clients sometimes retry the same exit, even when it is timing out. Can we retry fewer times, but still have an acceptable risk of clients encountering a bad exit? experience a lot of exit timeouts when trying to connect to a website via DNS.

changed milestone to %Tor: 0.3.3.x-final

added component::core tor/tor milestone::Tor: 0.3.3.x-final parent::21394 performance priority::medium resolution::wontfix severity::normal status::closed tbb-needs tbb-performance tbb-usability type::defect labels

Replying to teor:

In #21394 (moved), we discovered that Tor clients sometimes retry the same exit, even when it is timing out. Can we retry fewer times, but still have an acceptable risk of clients encountering a bad exit?

Is that true? I hadn't concluded that from the data, but I'm not familiar with the code. Does it return to the same exit more than would be expected by a random exit selection?

Oh, I see. Those were attempts to random exits that timed out before completing. Maybe we could fix that at the client level by keeping an exit failure cache? But the client would still need to experience some timeouts before it could skip failed exits.

Trac:
Summary: Make clients avoid retrying the same exit when it times out to Make clients avoid retrying slow exits when they time out
Description: In #21394 (moved), we discovered that Tor clients sometimes retry the same exit, even when it is timing out. Can we retry fewer times, but still have an acceptable risk of clients encountering a bad exit?

to

In #21394 (moved), we discovered that Tor clients sometimes retry the same exit, even when it is timing out. Can we retry fewer times, but still have an acceptable risk of clients encountering a bad exit? experience a lot of exit timeouts when trying to connect to a website via DNS.

Replying to teor:

Oh, I see. Those were attempts to random exits that timed out before completing. Maybe we could fix that at the client level by keeping an exit failure cache? But the client would still need to experience some timeouts before it could skip failed exits.

Given that there are hundreds of exits and, at least in my naive measurement, ~20% timeout, it sounds not super useful. So I think for solving #21394 (moved) I would be more inclined to rely on self-reporting by relays (#24014 (moved)) or external testing by bandwidth authorities (#24010 (moved)).

Trac:
Cc: gk, brade, mcs to gk, brade, mcs, arthuredelstein

Replying to teor:

Maybe we could fix that at the client level by keeping an exit failure cache?

Be very careful of a destination dns server that chooses which requests to time out on, with the goal of shifting users away from certain exits towards others.

Some amount of that attack is inevitably possible, since if you can't reach the site from one exit then you'll end up reaching it from another.

But any design where the destination dns server can set cross-circuit state on the client makes me itch.

I don't think we can do this on clients, as arma said, it leads to linkability issues. We'll have to do it at the exits themselves.

Trac:
Resolution: N/A to wontfix
Status: new to closed

closed

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