Opened 12 months ago

Last modified 5 months ago

#27491 assigned 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: 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

TicketTypeStatusOwnerSummary
#29687enhancementclosedUpdate prop#299 in torspec

Change History (14)

comment:1 Changed 12 months ago by neel

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

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

Milestone: Tor: unspecified

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

comment:4 Changed 9 months ago by neel

Status: assignedneeds_review

comment:5 Changed 9 months ago by dgoulet

Reviewer: mikeperry

comment:6 Changed 7 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:
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 7 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 7 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 6 months ago by teor

Status: needs_informationneeds_review

comment:10 Changed 6 months ago by teor

Reviewer: teor

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.

comment:11 Changed 6 months ago by teor

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

comment:12 Changed 5 months ago by neel

Status: needs_reviewneeds_revision

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

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

Status: needs_revisionnew

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

comment:14 Changed 5 months ago by neel

Status: newassigned
Note: See TracTickets for help on using tickets.