Opened 5 years ago

Last modified 2 years ago

#13234 new defect

Consensus Algorithm Causes Flip-Flopping

Reported by: pipeep Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: unspecified
Severity: Normal Keywords: tor-dirauth sybil voting needs-spec
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

I had a relay running on 94.23.214.156. It's an unmetered VPS that is NATed with other VPSes, so everyone ends up with the same IPv4 address, but on different ports with port forwarding. Everyone gets their own IPv6 address, but AFAIK, you can't run a relay without IPv4.

This was fine initially, as my relay just ran on a high-numbered port. Currently, there are two other relays using the same IP. This apparently causes the consensus algorithm to flip-flop, keeping any of the relays from becoming stable.

To mitigate this, I've disabled my relay, but this is a less than ideal situation, especially if someone else starts running a relay.

Relevant IRC discussion:

<Sebastian> well, this situation totally sucks.
<Sebastian> I think it is a Tor bug, too.
<Sebastian> because the dirauths disagree on who they think should go in the consensus
<Sebastian> so there's flopping
<pipeep> Ouch.
<Sebastian> so of the three relays doing potentially useful things, zero are useful atm
<pipeep> Sebastian, well, I can shut down my relay for now, so at least there won't be any flip-flopping.
<pipeep> And I can contact one of the two other relay operators, and we can decide based on who has the beefier box
* galex-713 has quit (Ping timeout: 480 seconds)
<pipeep> The other one didn't appear to put valid contact information
<Sebastian> that would be nice. You can also file a Tor bug with the information so other people can see that this is an issue

...

<pipeep> Sebastian, what's the issue exactly? That the consensus algorithm is unstable?
<Sebastian> that's one of the issues, the other issue is imo the restriction to two relays/IP itself

Child Tickets

Change History (8)

comment:1 Changed 5 years ago by nickm

Keywords: tor-auth added
Milestone: Tor: 0.2.6.x-final

We should at least try to figure out a sensible solution here during the 0.2.6 timeframe.

comment:2 Changed 5 years ago by teor

Logged #13414 Increase Authorities' AuthDirMaxServersPerAddr to 4 or 8 to use more processors in response to this issue, and recent discussions on the tor-dev mailing list.

comment:3 Changed 5 years ago by nickm

Milestone: Tor: 0.2.6.x-finalTor: 0.2.???

comment:4 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:5 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:6 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:7 Changed 2 years ago by dgoulet

Keywords: tor-dirauth added; tor-auth removed

Turns out that tor-auth is for directory authority so make it clearer with tor-dirauth

comment:8 Changed 2 years ago by nickm

Keywords: sybil voting needs-spec added
Severity: Normal

Related to #8163 , I think.

Note: See TracTickets for help on using tickets.