Opened 6 months ago

Last modified 5 weeks ago

#27491 needs_information enhancement

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: teor 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

Change History (8)

comment:1 Changed 6 months ago by neel

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

comment:2 Changed 5 months 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 4 months ago by teor

Milestone: Tor: unspecified

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

comment:4 Changed 3 months ago by neel

Status: assignedneeds_review

comment:5 Changed 2 months ago by dgoulet

Reviewer: mikeperry

comment:6 Changed 5 weeks 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:
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.

comment:7 Changed 5 weeks 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 5 weeks ago by teor

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

Note: See TracTickets for help on using tickets.