Opened 2 years ago

Closed 8 months ago

#27491 closed enhancement (wontfix)

Prefer IPv4 or IPv6 based on the number of failures

Reported by: neel Owned by: neel
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: needs-proposal, ipv6
Cc: neel Actual Points:
Parent ID: #17835 Points:
Reviewer: Sponsor:

Description (last modified by neel)

Suggested by teor at #17835:

  1. If the machine instantly fails IPv4 or IPv6 connections, stop those connections for a while
  2. When there are a lot more IPv4 than IPv6 failures, don't try IPv4 as much
  3. When there are a lot more IPv6 than IPv4 failures, don't try IPv6 as much
  4. After a while, forget old failures

Child Tickets

#29687enhancementclosedUpdate prop#299 in torspec

Change History (15)

comment:1 Changed 2 years ago by neel

Description: modified (diff)
Parent ID: #17835
Reviewer: #17385

comment:2 Changed 2 years ago by neel

Type: defectenhancement

I have a few questions:

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

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

comment:3 Changed 2 years ago by teor

Milestone: Tor: unspecified

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

comment:4 Changed 23 months ago by neel

Status: assignedneeds_review

comment:5 Changed 23 months ago by dgoulet

Reviewer: mikeperry

comment:6 Changed 21 months ago by teor

Keywords: needs-proposal ipv6 added
Status: needs_reviewneeds_information

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:

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.

comment:7 Changed 21 months ago by teor

Reviewer: mikeperryteor

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

comment:8 Changed 21 months ago by teor

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

comment:9 Changed 20 months ago by teor

Status: needs_informationneeds_review

comment:10 Changed 20 months ago by teor

Reviewer: teor

Here is the pull request for the latest version of the proposal:

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

comment:11 Changed 20 months ago by teor

There are multiple discussion threads for this proposal on tor-dev.
Here's one of them:

comment:12 Changed 19 months ago by neel

Status: needs_reviewneeds_revision

I have added some changes with a new PR at #29801 ( This PR can get updated if another reviewer comes up.

comment:13 in reply to:  10 Changed 19 months ago by teor

Status: needs_revisionnew

Setting as new again.
#29801 is the ticket for the proposal changes.

comment:14 Changed 19 months ago by neel

Status: newassigned

comment:15 Changed 8 months ago by teor

Resolution: wontfix
Status: assignedclosed
Note: See TracTickets for help on using tickets.