#24022 closed defect (wontfix)

Make clients avoid retrying slow exits when they time out

Reported by: teor Owned by:
Priority: Medium Milestone: Tor: 0.3.3.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tbb-performance, tbb-usability, performance, tbb-needs
Cc: gk, brade, mcs, arthuredelstein Actual Points:
Parent ID: #21394 Points:
Reviewer: Sponsor:

Description (last modified by teor)

In #21394, 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.

Child Tickets

Change History (5)

comment:1 in reply to:  description Changed 20 months ago by arthuredelstein

Replying to teor:

In #21394, 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?

comment:2 Changed 20 months ago by teor

Description: modified (diff)
Summary: Make clients avoid retrying the same exit when it times outMake clients avoid retrying slow exits when they time out

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.

comment:3 in reply to:  2 Changed 20 months ago by arthuredelstein

Cc: arthuredelstein added

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 I would be more inclined to rely on self-reporting by relays (#24014) or external testing by bandwidth authorities (#24010).

comment:4 in reply to:  2 Changed 20 months ago by arma

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.

comment:5 Changed 20 months ago by teor

Resolution: wontfix
Status: newclosed

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.

Note: See TracTickets for help on using tickets.