Prefer IPv4 or IPv6 based on the number of failures

changed milestone to %Tor: unspecified

added component::core tor/tor ipv6 milestone::Tor: unspecified needs-proposal owner::neel parent::17835 priority::medium resolution::wontfix severity::normal status::closed type::enhancement labels

Trac:
Parent: N/A to #17835 (moved)
Description: Suggested by teor at #17385 (moved):

If the machine instantly fails IPv4 or IPv6 connections, stop those connections for a while

When there are a lot more IPv4 than IPv6 failures, don't try IPv4 as much

When there are a lot more IPv6 than IPv4 failures, don't try IPv6 as much

After a while, forget old failures

to

Suggested by teor at #17835 (moved):

If the machine instantly fails IPv4 or IPv6 connections, stop those connections for a while

When there are a lot more IPv4 than IPv6 failures, don't try IPv4 as much

When there are a lot more IPv6 than IPv4 failures, don't try IPv6 as much

After a while, forget old failures
Reviewer: #17385 (moved) to N/A

I have a few questions:

I believe I should modify connection_or_connect_failed(). Is this correct?
In the above function, is an instant connection failure determined by the OR error END_OR_CONN_REASON_NO_ROUTE?

I know that #27490 (moved) is not committed yet, but I am already planning this patch while I wait.

Trac:
Type: defect to enhancement

These tickets can be moved to 0.3.6 if they get code.

Trac:
Milestone: N/A to Tor: unspecified

PR is here: https://github.com/torproject/tor/pull/566

Trac:
Status: assigned to needs_review

Trac:
Reviewer: N/A to mikeperry

Thanks for this code. It looks like you put a lot of work into it. Your work is valuable, because it helps us see what kind of questions we need to answer.

We need to think carefully about the design and implementation of this feature. Otherwise, users could rely on this feature, and that makes it hard for us to change it later.

When we design a complex feature, we do the design in a proposal, so we can work through the design issues without changing the code all the time. Here's our proposals process: https://gitweb.torproject.org/torspec.git/tree/proposals/001-process.txt

If you're having trouble writing a whole proposal, just write an email to tor-dev explaining how this new feature works. We can help you from there.

Once we have a proposal, we can work out how to implement this feature. For example, tor already tracks connection history in rephist.c. At the moment, this code forgets all its IP history once a week. But maybe it should just forget the oldest IP failures, not all the IP failures.

Trac:
Keywords: N/A deleted, needs-proposal, ipv6 added
Status: needs_review to needs_information

I did a review on the pull request, and added some questions to think about for your proposal.

Trac:
Reviewer: mikeperry to teor

After the proposal is done, we can also update the man page to describe Tor's new behaviour.

Trac:
Status: needs_information to needs_review

Here is the pull request for the latest version of the proposal: https://github.com/torproject/torspec/pull/61

I'm going to review it and make some comments. But I'd also like a second reviewer.

Trac:
Reviewer: teor to N/A

There are multiple discussion threads for this proposal on tor-dev. Here's one of them: https://lists.torproject.org/pipermail/tor-dev/2019-March/013730.html

I have added some changes with a new PR at #29801 (moved) (https://github.com/torproject/torspec/pull/63). This PR can get updated if another reviewer comes up.

Trac:
Status: needs_review to needs_revision